Page tree

BMC TrueSight Infrastructure Management cells are event-processing engines that store all events and data in memory as well as on disk almost in real-time. A cell runs either as a Windows service or as a UNIX daemon on supported platforms.

There are three types of cells used in Infrastructure Management:

  • BMC TrueSight Infrastructure Management Server Cell—functions as part of the BMC TrueSight Infrastructure Management Server to provide local event and service impact management. The Infrastructure Management Server Cell also associates events with service model components and calculates the components’ statuses. 
  • Administration Cell—a cell that is installed automatically as part of the BMC TrueSight Infrastructure Management Server and self-maintained. Its default cell instance name is Admin and it contains a specialized Knowledge Base. This cell accepts registration, configuration, and other events from BMC product components and applications. It then creates the component definitions based on the event information. The Administration Cell also uses these events to maintain a service model of the Infrastructure Management infrastructure that can be viewed from the administration console, complete with configuration and real-status information.
  • Remote Cell—installed separately from the BMC TrueSight Infrastructure Management Server, the Remote Cellfunctions as part of a larger distributed network of cells that propagate events to the BMC TrueSight Infrastructure Management Server Cell. If service impact management is implemented, the Remote Cellalso associates events with service model components and calculates the components’ statuses. If service impact management is not implemented, then the cell is simply an event management cell. Networks of Remote Cells can be organized to serve any business hierarchy (such as geographical, functional, or organizational) or configured to meet technical issues (such as network or system limitations). A Remote Cellcan be configured for high availability by configuring a primary cell server and a secondary cell server to be used for failover if the primary cell server fails.

The cells:

  • Receive source event data from an adapter, integration, another cell, API, the Rate processor, or the cell Command Line Interface (CLI).
  • Analyze and process events according to the event management rules and policies defined in its Knowledge Base.
  • Respond to events by executing actions, as defined in scripts or programs in its Knowledge Base.
  • Propagate selected events to specified destinations (typically, other cells) and update propagated events when those events are changed at the event source or event destination.
  • Record the event operations performed on an event.
  • Relate an event to the appropriate service model component.
  • Compute the status of service model components and propagate their status to the related components using the designated status computation models.

The behavior of a cell is governed by its Knowledge Base.

Knowledge Base

A Knowledge Base (KB) defines the behavior of a Infrastructure Management instance (also referred to as a cell). KB classes define what information is contained in each event. KB rules define how the events are processed. You can modify the KB to customize its behavior in your environment.

The KB is similar to a script and the cell is the engine that runs the script.

The KB is a compiled collection of files, such as event processing rules, class definitions, and executables, organized in a directory structure. A KB is installed with each cell. The KB files are loaded by a cell at start time. The Knowledge Base instructs the cell how to format incoming event data, process received events, and display events in the operator console. Although many KBs can exist within a distributed Remote Cellenvironment, each cell can be associated with only one KB at a time.

During installation of the cell, a KB that serves as a template for all cell KBs is created for the cell. The KB provides the cell with the data definitions, data instances, collector definitions, and rules for a fully functional environment in which to process events and service components. You must specify a KB for any new cell you create.

Components of a Knowledge Base

A KB includes the following:

  • Event classes—define the types of events to accept and classify source event data for processing.
  • Data classes—define the classes and slots of dynamic data instances and service model component instances.
  • Dynamic data—function as contextual variables that can provide data values to rules and policies during event processing.
  • Global records—persistent structured global variables that maintain data values across all phases of event processing.
  • Event management rules—event processing statements that use the data associated with an event, data instances or records to determine if, when, and how to respond to new events or event modifications.
  • Event management policies—one of several generic rule types that perform actions against events that meet selection criteria specified in an associated event selector. An event management policy selects the events that you want to process, defines the processes needed to manage those events, and schedules when the events are processed.
  • Event collectors—filters that query the event repository and display the results in a cell event list in an organized manner.
  • Action executables—executable programs or scripts that perform an automated task on a particular event.

In addition, if service impact management is enabled, the KB also includes a reference copy of:

  • The BMC Atrium CMDB (Configuration Management Database) Common Data Model (CDM) Service class definitions used in the service model of a cell.
  • The service model of the cell, published by a BMC Impact Publishing Server.

For more information about the cell Knowledge Base, see Working with the Knowledge Base.