At the core of Lithium is a common entity hierary model termed CEMent. The hiearchy describes a seven-level hierarchy into which customers, sites, devices, containers, objects, metrics and triggers are arranged. A model of the hierarchy and a description of each entity type is contained here-in.

Hierarchy Model

The CEMent hierarchy is arranged in a single-verticle tree of Customers, Sites, Devices, Containers, Objects, Metrics and Triggers as shown in the diagram below. Each entity has an identifier string which must be unique amongst that type of entity and a description string that can be any string of characters.

Entity Types

Customer

The Customer entity is at the top of the entity hierarchy and hence is the master object for the entity hierarchy belonging to that Customer. Typically a Customer entity in Lithium refers to a group of sites and devices that have a common administrative domain or organisation. If you are using Lithium to monitor your organisations own infrastructure then you would typically have one Customer entity defined for your organisation. Conversely, if you were using Lithium to monitor the network infrastructure of multiple organisations then a Customer entity would be defined and created for each organisation.

Each Customer in Lithium has a number of database tables and data stores that are unique to and pertain only to that customer. Some examples of these are the incident database, case database, inventory database and IP registry data. This Customer-specific data is not accessible by other Customer entities. Similarly, each Customer is treated as a self-contained source of network infrastructure monitoring data when viewed via the Lithium Web interface and the Lithium Console interface.

Site

The Site entitiy defines a single physical location at which devices that are to be monitored by Lithium are installed.  Site entities belong to the Customer under which they have been defined. For each Site, Device entities can be defined for devices that are to be monitored by Lithium.

Device

The Device entity defines a physical or logical device that is to be monitored by Lithium. Each Device is configured with the basic entity identifier and description strings as well as device-specific monitoring configuration data including IP address, SNMP community (where applicable), refresh/polling interface, etc.

Container

A Container entity is, as the name suggests, a container for Object entities of the same logical type. For example, a group of Objects that referred to Network Interfaces would belong to a Network Interfaces container entity. The container entity defines some attributes common to each object such as applicable Trigger Sets and SNMP Object Factories.

Object

Object entities are defined and created for physical and/or logical items that are to be monitored by Lithium and have a set of Metrics attached to them. An example of an Object is a single network interface or a single CPU.

Metric

Metric entities are defined for each value to be mined or calculated with regard to the state or operation of an Object. Metrics can either be polled or collected from the device being monitored or auto-calculated based on the data obtained from other Metrics. An example of a metric would be "Input Errors Per Second" which may belong to an Object defined in a Container for network interfaces.

Trigger

Trigger entities are defined for conditions which indicate an undesirable condition present within the Device being monitored. A trigger entity is user or application defined and is used to raise incidents based on the latest recorded or calculated value of the Metric to which it is defined under. After a Metric entity is refreshed, all Trigger entities are evaluated if the condition described by the Trigger entity is present an incident is raised. Trigger entities define both the condition and the severity of the incident that is raised when that condition is met. Trigger entities should be configured such that only a single Trigger within a single Metric entity can raise an incident at a time. I.e Trigger conditions should not overlap.

Incidents

An Incident is an occurrence of a condition in a network that has been deemed undesirable, indicative of a problem or otherwise worthy of note. An Incident is raised within Lithium when a condition that is described in a Trigger entity is deemed to be present in the Trigger's parent Metric entity. For example, a "Percent Used" Metric may have a Trigger entity attach to it that is configured to raise an "Impaired" condition when the value of the metric exceeds 80%.

Incidents exist in either an active or inactive state. When an Incident is in the active state, the condition that is described by the Incident (e.g the Trigger's Impaired condition being raised) is current and present. When that condition is no longer present, the Incident is termed inactive. All Incidents, active and inactive, are available in the database used by Lithium to store historical network data.

Additionally, Incidents are referred to as either handled or unhandled. The handled or unhandled term refers to whether or not the Entity that has raised the Incident, or a parent there-of, has been bound to an open Case. When an Incident is active and the Entity that has raised the Incident is not bound to a Case, the Incident is referred to as Unhandled. Conversely when the Entity that has raised the Incident is bound to a Case, the Incident is referred to as handled.

Cases

A Case is a logical container for information regarding fault investigation, remediation and/or other tasks that occur regarding the management of network infrastructure. Cases consist of Log Entries and optionally a list of Entities that are bound to the case.

Log Entries are narratives entered by the owner of the case or other users with access to Lithium. Each Log Entry is time-stamped and the author of the Log Entry is recorded. When a case is viewed, each Log Entry is displayed in chronological order.

Entities can be bound to cases to represent that they have some degree of bearing on the cases. Typically, when a case is opened for a fault or problem that relates to an Entity (or an Incident), that Entity is bound to the case. The status of that Entity is then tracked and visible through that Case. All subsequent Incidents that are raised for that entity of a child there-of are marked as being handled by that Case.