Identificación de los componentes origen e informador

Los campos de identificación de componentes del suceso base común se utilizan para indicar qué componentes del sistema están experimentando la condición descrita en el suceso (sourceComponentID) y qué componente ha emitido el suceso (reporterComponentID).

Estos componentes suelen ser el mismo componente, en cuyo caso solo se proporciona sourceComponentID. A continuación se indican algunos escenarios en los que se deben utilizar estos dos elementos en el suceso base común:
  • Se utiliza siempre sourceComponentID para identificar el componente que está experimentando la condición descrita por el suceso.
  • Se utiliza reporterComponentID para identificar el componente que ha producido y emitido el suceso. Este elemento solo se suele utilizar en los sucesos emitidos por un componente que está supervisando otro componente y proporciona información de funcionamiento relativa a dicho componente. El componente supervisor (por ejemplo, un agente Tivoli o controlador de dispositivo de hardware) se identifica mediante reporterComponentID y el componente supervisado (por ejemplo, un servidor supervisado o dispositivo hardware) se identifica mediante sourceComponentID.

    Un uso potencialmente incorrecto de reporterComponentID consiste en la identificación de un componente que proporciona conversión de sucesos o servicios de gestión a un componente, por ejemplo, la identificación de un adaptador que transforme los sucesos capturados por un componente al formato de suceso base común. La función de conversión de sucesos se considera una extensión del componente y no debe identificarse separadamente.

La información utilizada para identificar un componente del sistema es la misma tanto si se trata del componente de origen como del componente informador.
Tabla 1. Identificación de los componentes origen e informador. La información utilizada para identificar un componente del sistema es la misma tanto si se trata del componente de origen como del componente informador.
Componente de origen Componente informador Descripción
location locationType Ubicación del componente Identifica la ubicación del componente.
component componentIdType Nombre de componente Identifica el nombre de activo del componente además del tipo del componente.
subcomponent Nombre de subcomponente Identifica una parte específica o subcomponente de un componente, es decir, un módulo de software o pieza de hardware.
aplicación Nombre de la aplicación de negocio Identifica el proceso o la aplicación de negocio de los que forma parte el componente y a los que proporciona servicios.
instanceId Instancia operativa Identifica la instancia operativa de un componente, es decir, la instancia real en ejecución del componente.
processId threadId Instancia operativa Identifica la instancia operativa de un componente en del contexto de un sistema operativo de software, es decir, el hilo y el proceso del sistema operativo que se están ejecutando cuando se produce el suceso.
executionEnvironment Instancia operativa Ubicación del componente Proporciona información adicional sobre la instancia operativa de un componente o su ubicación identificando el nombre del entorno que aloja la instancia operativa del componente, por ejemplo, el nombre del sistema operativo de una aplicación de software, el nombre del servidor de aplicaciones de una aplicación J2EE (Java™ 2 Platform, Enterprise Edition) o el tipo de servidor hardware de una pieza de hardware.
La especificación de Common Base Event [CBE101] (suceso base común) proporciona información sobre el formato necesario de estos campos y la Guía del desarrollador de suceso base común [CBEBASE] proporciona pautas generales de uso. Esta sección proporciona información adicional sobre cómo dar formato y utilizar algunos de estos campos en los sucesos de determinación de problemas, que pueden utilizarse para clarificar y ampliar la información facilitada en los demás documentos.
Component
El campo Component de un suceso de determinación de problemas se utiliza para identificar el activo gestionable asociado al suceso. Un activo gestionable se presta a varias interpretaciones, pero una buena definición funcional sería que un activo gestionable representa un componente de hardware o software que, de forma independiente, se puede obtener o desarrollar, desplegar, gestionar y al que se puede dar servicio. Ejemplos de nombres de componente típicos son:
  • IBM® eServer xSeries model x330
  • IBM WebSphere Application Server version 5.1 (5.1 es el número de versión)
  • Nombre de una aplicación de software desarrollada internamente para un componente
subComponent
El campo Subcomponent de un suceso de determinación de problemas identifica la parte concreta de un componente asociado al suceso. El nombre de subcomponente no suele ser un activo gestionable, pero proporciona información de diagnóstico interna cuando se diagnostica el defecto interno de un componente, es decir, qué pieza ha fallado. Ejemplos de nombres de subcomponentes típicos son:
  • el procesador Intel Pentium en un sistema de servidor (Intel Pentium IV Processor)
  • el contenedor de enterprise beans en un servidor de aplicaciones web (contenedor de enterprise beans)
  • el gestor de tareas de un sistema operativo (Gestor de tareas de Linux Kernel)
  • el nombre de una clase y de un método Java (miclase.miempresa.com o miclase.miempresa.com.nombremetodo).
El formato del nombre de un subcomponente está determinado por el componente, pero se recomienda que se siga la convención mostrada anteriormente para nombrar una clase Java o la combinación de una clase y un método Java. El campo de subcomponente es obligatorio en Common Base Event.
componentIdType
El campo componentIdType es obligatorio en la especificación Common Base Event, pero es de escaso valor para los sucesos de determinación de problemas. En la mayoría de sucesos de determinación de problemas, se recomienda utilizar el valor proporcionado en el campo application en lugar de componentIdType. El campo componentIdType identifica el tipo de componente; el campo application identifica la aplicación.
aplicación
El campo application se lista como un valor opcional en la especificación Common Base Event, pero debe facilitarse en los sucesos de determinación de problemas siempre que esté disponible. La única razón por la que no es un campo obligatorio en los sucesos de determinación de problemas es que puede haber casos en los que el componente emisor no tenga conocimiento de la aplicación de negocio global.
instanceId
El campo instanceId se lista como un valor opcional en la especificación Common Base Event, pero debe facilitarse en los sucesos de determinación de problemas siempre que esté disponible.

Proporcione instanceID siempre que se identifique un componente de software e identifique la instancia operativa del componente (por ejemplo, qué instancia operativa de una imagen de software instalada está asociada al suceso). Facilite este valor en los componentes hardware cuando dichos componentes soporten el concepto de instancias operativas.

El formato del valor suministrado lo define el componente, pero debe ser un valor que un sistema de análisis pueda utilizar (ya sea un analista o un programa) para identificar la instancia de ejecución concreta del componente identificado. Los ejemplos incluyen lo siguiente:
  • el nombre de célula, nodo, servidor de IBM WebSphere Application Server
  • nombre de archivo EAR desplegado de un enterprise bean Java
  • número de serie de un procesador hardware
processId
El campo processId se lista como un valor opcional en la especificación Common Base Event, pero facilite este valor en los sucesos de determinación de problemas siempre que esté disponible y sea aplicable. Siempre debe proporcionarse este valor en los sucesos generados por software e identificarse el proceso del sistema operativo asociado al componente identificado en el suceso. Haga coincidir el formato del ID de hilo con el formato del sistema operativo (o de otro entorno de ejecución, como una máquina virtual Java). Este campo no se suele aplicar ni utilizar en sucesos emitidos por hardware (por ejemplo, firmware).
threadId
El campo threadId se lista como un valor opcional en la especificación Common Base Event, pero facilite este valor en los sucesos de determinación de problemas siempre que esté disponible y sea aplicable. Siempre debe proporcionarse en sucesos generados por software e identificarse el hilo del sistema operativo que estaba activo al detectarse o emitirse el suceso. Una excepción significativa a esta recomendación es que algunos sistemas operativos o entornos de ejecución no soportan hilos. Haga coincidir el formato del ID de hilo con el formato del sistema operativo (o de otro entorno de ejecución, como una máquina virtual Java). Este campo no se suele aplicar ni utilizar en sucesos emitidos por hardware (por ejemplo, firmware).
executionEnvironment
El campo executionEnvironment, cuando se utiliza, debe identificar el entorno de ejecución inmediato utilizado por el componente que se está identificando. Algunos ejemplos son:
  • El nombre del sistema operativo cuando el componente es una aplicación software nativa.
  • El nombre del sistema operativo/máquina virtual Java cuando el componente es una aplicación J2SE (Java 2 Platform, Standard Edition).
  • El nombre del servidor web cuando el componente es un servlet.
  • El nombre del servidor de portales cuando el componente es un portlet.
  • El nombre del servidor de aplicaciones cuando el componente es un enterprise bean.
La especificación de Common Base Event [CBE101] (suceso base común) proporciona información sobre el formato necesario de estos campos y la Guía del desarrollador de suceso base común [CBEBASE] proporciona pautas generales de uso.

Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_cbecompid
File name: rtrb_cbecompid.html