The component identification fields in the Common Base Event are
used to indicate which component in the system is experiencing the condition
described by the event (the sourceComponentId) and which component emitted
the event (the reporterComponentId). Typically, these are the same component,
in which case only the sourceComponentId is supplied. Some notes and scenarios
on when these two elements in the Common Base Event should be used:
- the sourceComponentId is always used to identify the component experiencing
the condition described by the event.
- the reporterComponentId is used to identify the component that actually
produced and emitted the event. This element is typically only used within
events emitted by a component that is monitoring another component and providing
operational information regarding that component. The monitoring component
(for example, a Tivoli agent or hardware device driver) is identified by the
reporterComponentId and the component being monitored (for example, a monitored
server or hardware device) is identified by the sourceComponentId.
A potential
misuse of the reporterComponentId is to identify a component that provides
event conversion or management services for a component, for example, identifying
an adapter that transforms the events captured by a component into Common
Base Event format. The event conversion function is considered an extension
of the component and should NOT be identified separately.
The information used to identify a component in the system is the same,
regardless of whether it is the source component or reporter component:
location locationType |
Component Location |
Identifies the location of the component. |
component componentType |
Component Name |
Identifies the asset name of the component, as well
as the type of component. |
subcomponent |
Subcomponent Name |
Identifies a specific part (i.e. subcomponent) of a
component, e.g. a software module or hardware part. |
application |
Business Application Name |
Identifies the business application or process the component
is a part of and provides services for. |
instanceId |
Operational Instance |
Identifies the operational instance of a component,
i.e. the actual running instance of the component. |
processId threadId |
Operational Instance |
Identifies the operational instance of a component within
the context of a software operating system, i.e. the operating system process
and thread running when the event was produced. |
executionEnvironment |
Operational Instance Component Location |
Provides additional information about the operational
instance of a component or its location by identifying the name of the environment
hosting the operational instance of the component (e.g. the operating system
name for a software application, the application server name for a J2EE application,
or the hardware server type for a hardware part). |
The Common Base Event specification [CBE101] provides information
on the required format of these fields and the Common Base Event Developer’s
Guide [CBEBASE] provides general usage guidelines. This section will provide
additional information about how to format and use some of these fields for
problem determination events, which should be used to clarify and extend the
information provided in the other documents.
- Component
- The component field in a problem determination event is used to identify
the manageable asset associated with the event. A manageable asset is open
for interpretation, but a good working definition is a manageable asset represents
a hardware or software component that can be separately obtained or developed,
deployed, managed and serviced. Examples of typical component names are:
- IBM eServer xSeries model x330
- IBM WebSphere Application Server#5.1 (5.1 is the version number)
- Microsoft Windows 2000
- The name of an internally developed software application for a component
- subComponent
- The subcomponent field in a problem determination event identifies the
specific part of a component associated with the event. The subcomponent
name is typically not a manageable asset, but provides internal diagnostic
information when diagnosing an internal defect within a component, i.e. ‘What
part failed?’. Examples of typical subcomponents and their names are:
- Intel Pentium processor within a server system (“Intel Pentium IV Processor”)
- the enterprise bean container within a web application server (“enterprise
bean container”)
- the task manager within an operating system (“Linux Kernel Task Manager”)
- the name of a Java class and method (“myclass.mycompany.com” or “myclass.mycompany.com.methodname()”).
The format of a subcomponent name is determined by the component, but
it is recommended that the convention shown above for naming a Java class
or the combination of a Java class and method is followed. Subcomponent is
a required field in the Common Base Event.
- componentIdType
- The componentIdType field is required by the base Common Base Event specification,
but provides minimal value for problem determination events. The only recommendation
regarding this field for problem determination events is to discourage the
use of the “application” value. The componentIdType field identifies the
type of component; the application is identified by the application field.
- application
- The application field is listed as an optional value within the Common
Base Event specification, but it should be provided within problem determination
events whenever it is available. The only reason this is not a required field
for problem determination events is there are instances where the issuing
component may not be aware of the overall business application.
- instanceId
- The instanceId field is listed as an optional value within the Common
Base Event specification, but it should be provided within problem determination
events whenever it is available.
The instanceID should always be provided
when a software component is being identified and should identify the operational
instance of the component (for example, which operation instance of an installed
software image is actually associated with the event). This value should
also be provided for hardware components, but not all hardware components
support the concept of operational instances.
The format of the supplied
value is defined by the component, but must be a value that can be used by
an analysis system (either human or programmatic) to identify the specific
running instance of the identified component. Examples include:
- cell\node\server name for the IBM WebSphere Application
Server
- deployed EAR file name for a Java enterprise bean
- serial number for a hardware processor
- processId
- The processId field is listed as an optional value within the Common Base
Event specification, but it should be provided for problem determination events
whenever it is available and applicable. It should always be provided for
software-generated events, and should identify the operating system process
associated with the component identified in the event. The format of the thread
ID should match the format of the operating system (or other execution environment,
such as a Java Virtual Machine). This field is typically not applicable or
used for events emitted by hardware (for example, firmware).
- threadId
- The threadId field is listed as an optional value within the Common Base
Event specification, but it should be provided for problem determination events
whenever it is available and applicable. It should always be provided for
software-generated events, and should identify the operating system thread
that was active when the event was detected or issued. A notable exception
to this recommendation is some operating systems or execution environments
do not support threads. The format of the thread ID should match the format
of the operating system (or other execution environment, such as a Java Virtual
Machine). This field is typically not applicable or used for events emitted
by hardware (for example, firmware).
- executionEnvironment
The executionEnvironment field, when used, should
identify the immediate execution environment used by the component being identified.
Some examples are:
- the operating system name when the component is a native software application.
- the operating system/Java Virtual Machine name when the component is a
Java J2SE application.
- the web server name when the component is a servlet.
- the portal server name when the component is a portlet.
- the application server name when the component is an enterprise bean.
The Common Base Event specification [CBE101] provides information on
the required format of these fields and the Common Base Event Developer’s
Guide [CBEBASE] provides general usage guidelines.