Operating Systems: i5/OS
Personalize the table of contents and search results
Component identification for source and reporter
The component identification fields in the Common Base Event are
used to indicate which component in the system is experiencing the condition
that is described by the event (the sourceComponentID) and which component
emitted the event (the reporterComponentID).
Typically, these components are the same, in which case only the
sourceComponentID is supplied. Some notes and scenarios on when to use these
two elements in the Common Base Event:
- The sourceComponentID is always used to identify the component experiencing
the condition that is described by the event.
- The reporterComponentID is used to identify the component that actually
produced and emitted the event. This element is typically used only within
events that are 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 that are captured by a component
into Common Base Event format. The event conversion function is considered
an extension of the component and not identified separately.
The information that is 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 componentIdType
| Component name
| Identifies the asset name of the component, as well
as the type of component.
|
subcomponent
| Subcomponent name
| Identifies a specific part or subcomponent of a component,
for example 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,
that is 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, that is he 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, for example 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 provides
additional information about how to format and use some of these fields for
problem determination events, which can be used to clarify and extend the
information that is provided in the other documents.
- Component
-
The Component field in a problem determination event is used to identify
the manageable asset that is 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 version 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 that is 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, that is
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
use the convention shown previously for naming a Java class or the combination
of a Java class and method is followed. The subcomponent field is required
in the Common Base Event.
- componentIdType
-
The componentIdType field is required by the Common Base
Event specification, but provides minimal value for problem determination
events. For most problem determination events, it is encouraged to use the
value provided in the application field instead of the componentIdType. 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 provide it within problem determination events
whenever it this value is available. The only reason this field is not required
for problem determination events is that instances exist where the issuing
component might 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 provide this value within problem determination
events whenever it is available.
Always provide the instanceID when a software
component is identified and identify the operational instance of the component
(for example, which operation instance of an installed software image is actually
associated with the event). Provide this value for hardware components when
these components support the concept of operational instances.
The format
of the supplied value is defined by the component, but must be a value that
an analysis system can use (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 provide this value for problem determination events
whenever it is available and applicable. Always provide this value for software-generated
events, and identify the operating system process that is associated with
the component that is identified in the event. Match the format of the thread
ID with the format of the operating system (or other running environment,
such as a Java virtual machine). This field is typically not applicable or
used for events that are emitted by hardware (for example, firmware).
- threadId
-
The threadId field is listed as an optional value within the Common Base
Event specification, but provide this value for problem determination events
whenever it is available and applicable. Always provide for software-generated
events, and identify the active operating system thread when the event was
detected or issued. A notable exception to this recommendation is some operating
systems or running environments do not support threads. Match the format
of the thread ID with the format of the operating system (or other running
environment, such as a Java virtual machine). This field is typically not
applicable or used for events that are emitted by hardware (for example, firmware).
- executionEnvironment
-
The executionEnvironment field, when used, identifies
the immediate running environment that is 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 2 Platform, Standard Edition (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.
Related tasks
Adding logging and tracing to your application
Related Reference
The structure of the Common Base Event
Reference topic