Implementación del método del proveedor de diagnósticos
Para crear un proveedor de diagnósticos (DP), debe tener un MBean que debe incluir los siguientes métodos en el archivo XML (Extensible Markup Language) de despliegue. Estos métodos definen las operaciones, atributos y agregadores necesarios para que un MBean sea un proveedor de diagnósticos.
getRegisteredDiagnostics
Este método expone la información de registro de este proveedor de diagnósticos. El programa de utilidad DP lo utiliza generalmente en la consola administrativa para recopilar información sobre las proveedores de diagnósticos que se visualizan en la consola. Este método devuelve un objeto DiagnosticProviderInfo que generalmente se obtiene pasando el XML adecuado a una clase de ayudante DiagnosticProviderHelper. A continuación figura un ejemplo:
public DiagnosticProviderInfo getRegisteredDiagnostics() {
InputStream regIS= Thread.currentThread().getContextClassLoader().getResourceAsStream(
"com/ibm/ws/xxx/SampleDP2DiagnosticProvider.xml");
dpInfo = DiagnosticProviderHelper.loadRegistry(regIS, sDPName) ;
if (dpInfo == null) {
sSampleDP2MBeanLogger.logp(Level.WARNING, sThisClass, "getRegisteredDiagnostics",
"RasDiag.DPInfo.NoGotz") ;
}
return dpInfo ;
}
Tenga en cuenta que XML se empaqueta y está disponible en la vía de acceso de clases del cargador de clases actual. El XML de registro contiene información crucial que el proveedor de diagnósticos utiliza para Relleno de la parte principal y localize los resultados.
getDiagnosticProviderName
Este método generalmente consiste en una devolución muy sencilla de una constante, como muestra el siguiente ejemplo:
public String getDiagnosticProviderName() {
return sDPName;
}
getDiagnosticProviderID
Este método generalmente consiste en una devolución muy sencilla de un ID de objeto JMX (Java™ Management Extensions) que los MBeans pueden extraer del método de clase básica. Por ejemplo:
public String getDiagnosticProviderId() {
return getObjectName().toString() ;
}
configDump
El método configDump permite que el proveedor de diagnósticos exponga los datos de configuración que estaban en vigor cuando se inició el proveedor de diagnósticos (o los valores actuales). Los objetos DiagnosticEvent que devuelve este método devuelven incluyen una Parte principal que contiene los datos principales. A continuación, se ofrece el fragmento de un método configDump:
public DiagnosticEvent [] configDump(String aAttributeIdSpec, boolean aRegisteredOnly) {
HashMap cdHash = new HashMap(64) ;
// Relleno de la parte principal
DiagnosticEvent [] diagnosticEvent = new DiagnosticEvent[1] ;
diagnosticEvent[0] = DiagnosticEventFactory.createConfigDump(getObjectName().toString(),
"ThisClassName", "configDump", cdHash) ;
return diagnosticEvent ;
}
Este método devuelve una matriz de objetos DiagnosticEvent. Generalmente, configDump y stateDump sólo devuelven un objeto. No obstante, el método acepta una matriz porque en los sistemas z/OS un servidor puede tener varios servidores y la agregación de la salida de los sirvientes se almacena en la matriz.
stateDump
El método stateDump permite que el proveedor de diagnósticos exponga los datos del estado actual o los datos sobre las condiciones operativas actuales del proveedor de diagnósticos. Los datos que están disponibles disponibles pueden ser cualquier tipo de información que pueda servir de ayuda a un cliente, una persona de soporte de IBM® o herramienta automática para analizar el buen funcionamiento del componente y la determinación de problemas si hay alguno. La cantidad de datos disponibles se ve afectada por la Especificación de la colección de estados en vigor en ese momento. Si la especificación de la colección de estados actual implica la colección de datos adicionales mediante el proveedor de diagnósticos, estos datos adicionales pueden exponerse en el stateDump. Los objetos DiagnosticEvent que devuelve este método devuelven incluyen una Parte principal que contiene los datos principales. A continuación aparece el fragmento de un método stateDump:
public DiagnosticEvent [] stateDump(String aAttributeIdSpec, boolean aRegisteredOnly) {
HashMap sdHash = new HashMap(64) ;
// Relleno de la parte principal
DiagnosticEvent [] diagnosticEvent = new DiagnosticEvent[1] ;
diagnosticEvent[0] = DiagnosticEventFactory.createStateDump(getObjectName().toString(),
"ThisClassName", "stateDump", sdHash) ;
return diagnosticEvent ;
}
Este método devuelve una matriz de objetos DiagnosticEvent. Generalmente, configDump y stateDump sólo devuelven un objeto.
No obstante, el método acepta
una matriz porque un servidor z/OS puede tener varios
servidores y la agregación de la salida de los sirvientes se almacena en la
matriz.
selfDiagnostic
El método selfDiagnostic permite que el proveedor de diagnósticos realice varias actividades predefinidas para probar las funciones clave del sistema. Estas pruebas no deben tener un efecto prolongado en el sistema. Por ejemplo, si la prueba es para crear una conexión TCP/IP a fin de eliminar un host remoto, la prueba también debe interrumpir esa conexión antes de devolver los resultados para que el estado del componente permanezca inalterado por la prueba. La información devuelta por la prueba viene determinada por los atributos incluidos en la sección de pruebas del archivo XML. A continuación aparece un fragmento de un método selfDiagnostic:
public DiagnosticEvent [] selfDiagnostic(String aAttributeIdSpec, boolean aRegisteredOnly) {
TestInfo [] testInfo = dpInfo.selfDiagnosticInfo.testInfo ; // Recuperar la información de registro de prueba
Pattern testChecker = Pattern.compile(aAttributeIdSpec) ; // Compilar el parámetro regexp de prueba para una comprobación más rápida
ArrayList deList = new ArrayList(8) ; // Asignar lista ampliable de DiagnosticEvents
for (int i = 0; i < testInfo.length; i++) {
if (testChecker.matcher(testInfo[i].id).matches()) {
HashMap deHash = new HashMap(32) ;
// Relleno de la parte principal
deList.add(DiagnosticEventFactory.createDiagnosticEvent(getObjectName().toString(),
DiagnosticEvent.EVENT_TYPE_SELF_DIAGNOSTIC, DiagnosticEvent.LEVEL_INFO,
"ThisClassName", "selfDiagnostic", dpInfo.resourceBundleName,
"RasDiag.SDP2.createDE3", // MsgKey for localization
// Parámetros para incorporar en msg
new Object [] { "OneParm", "TwoParm", "RedParm", "BlueParm"}, deHash)) ;
}
}
DiagnosticEvent [] diagnosticEvent = new DiagnosticEvent[deList.size()] ;
diagnosticEvent = (DiagnosticEvent [])deList.toArray(diagnosticEvent) ;
return diagnosticEvent ;
}
Este método devuelve una matriz de objetos DiagnosticEvent. Es este ejemplo, se ha creado un DiagnosticEvent de cada prueba que coincidía con la expresión normal de parámetro. No es necesario que el proveedor de diagnósticos produzca sólo uno por prueba. La generación de la Parte principal es parecida a la de configDump y stateDump.
La agregación de varios sirvientes de
z/OS para un servidor individual concatena las matrices de cada
sirviente.
localize
Los DiagnosticEvents que los métodos devuelven contienen HashMaps de la parte principal que contienen MessageKeys y ResourceBundles. El consumidor final de estos sucesos a menudo no está en el servidor y es posible que no tenga la classpath adecuada para resolver esto. Para este fin, se realiza un retorno de llamada al proveedor de diagnósticos para localizar la variable. Un método de ayudante, no obstante, ayuda a que sea un método sencillo de escribir, como demuestra este ejemplo:
public String [] localize(String [] aKeys, Locale aLocale) {
return DiagnosticProviderHelper.localize(dpInfo.resourceBundleName, aKeys, aLocale) ;
}
Tenga en cuenta que el objeto dpInfo (DiagnosticProviderInfo) es necesario ya que este objeto incluye un referencia al ResourceBundle.
Parte principal
Un tema recurrente en estos métodos es la posibilidad de incluir una parte principal en los objetos devueltos. Esta consiste en un conjuntos de pares nombre=valor que incluyen la información expuesta por el método. Los diagnósticos de sucesos devueltos de una prueba de configDump, stateDump o selfDiagnostic son objetos Java relativamente complejos. La mayoría de la información que se devuelve está contenida en la parte DiagnosticData del objeto DiagnosticEvent. Todos los atributos devueltos por el proveedor de diagnósticos se almacena en una entrada de un HashMap. Puede haber HashMaps en cascada en un único objeto DiagnosticEvent (si el desglose de los datos en subgrupos tiene sentido). Todas las entradas de HashMap contienen una referencia a un HashMap hijo o DiagnosticTypedValue (que contiene el valor, el tipo de datos y una MsgKey para la localización de la etiqueta o /name). Los valores devueltos deben filtrase con:
- El tipo de método (es decir, configDump, stateDump o selfDiagnostic)
- AttributeIdSpec que se ha enviado para filtrar los valores
- La especificación de la colección de estados (que puede afectar a la cantidad de datos disponibles).
Relleno de la parte principal
La documentación de la API para DiagnosticProviderHelper.queryMatchingDPInfoAttributes explica cómo realizar el filtrado antes de recuperar los datos. En algunos casos, es más fácil y facilita el rendimiento que un proveedor de diagnósticos recupere todos los datos de la parte principal y, a continuación, filtre el HashMap después de la recuperación. El filtrado posterior a las actividades de relleno puede realizarse con el método DiagnosticProviderHelper.filterEventPayload. Para obtener información sobre cómo utilizar el enfoque de tipo JavaBeans, consulte la documentación de la API para el método AttributeBeanInfo.populateMap.
XML de registro
El XML de registro permite que mucha de la información necesaria para el proveedor de diagnósticos se externalice. También proporciona un medio para comunizar la localización y consumo de la pruebas (facilitando la automatización). A continuación aparece un fragmento de este XML de un proveedor de diagnósticos de ejemplo:
<!DOCTYPE diagnosticProvider PUBLIC "RasDiag" "/DiagnosticProvider.dtd">
<diagnosticProvider>
<resourceBundleName> com.ibm.ws.rasdiag.resources.RasDiagSample</resourceBundleName>
<state>
<attribute>
<id>Leg-Foot</id>
<descriptionKey>SampleDiagnostic.LegFoot.descriptionKey</descriptionKey>
<registered>true</registered>
</attribute>
<attribute>
<id>Leg-Ankle</id>
<descriptionKey>SampleDiagnostic.LegAnkle.descriptionKey</descriptionKey>
<registered>true</registered>
</attribute>
</state>
<config>
<attribute>
<id>Arm-Hand-Size</id>
<descriptionKey>SampleDiagnostic.HandSize.descriptionKey</descriptionKey>
<registered>true</registered>
</attribute>
<attribute>
<id>Leg-Foot-Size</id>
<descriptionKey>SampleDiagnostic.FootSize.descriptionKey</descriptionKey>
<registered>true</registered>
</attribute>
</config>
<selfDiagnostic>
<test>
<id>Kick</id>
<descriptionKey>SampleDiagnostic.Kick.descriptionKey</descriptionKey>
<attribute>
<id>Kick-Pain</id>
<descriptionKey>SampleDiagnostic.KickPain.descriptionKey</descriptionKey>
</attribute>
<attribute>
<id>Kick-Length</id>
<descriptionKey>SampleDiagnostic.KickLength.descriptionKey</descriptionKey>
</attribute>
</test>
<test>
<id>Throw</id>
<descriptionKey>SampleDiagnostic.Throw.descriptionKey</descriptionKey>
<attribute>
<id>Throw-Pain</id>
<descriptionKey>SampleDiagnostic.ThrowPain.descriptionKey</descriptionKey>
<registered>true</registered>
</attribute>
<attribute>
<id>Throw-Length</id>
<descriptionKey>SampleDiagnostic.ThrowLength.descriptionKey</descriptionKey>
<registered>true</registered>
</attribute>
</test>
</selfDiagnostic>
</diagnosticProvider>
Para comprender el almacenamiento de esta información en un objeto DiagnosticProviderInfo, consulte la documentación de la API para DiagnosticProviderInfo. Para obtener la información acerca de la finalidad del XML de registro, consulte Atributos y pruebas registrados del proveedor de diagnósticos.