[SCOM] - Authoring: Componentes dinámicos en aplicaciones distribuidas

  • Article

Hola!,

Para iniciar la serie de posts de Operations Manager hoy hablaré sobre la posibilidad de crear componentes dinámicos en Aplicaciones Distribuidas.

Es muy común encontrar en entornos monitorizados con SCOM que se utiliza el diseñador de Aplicaciones Distribuidas (en adelante DAs) de la Operations Console para monitorizar servicios en cuyo estado de salud intervienen varios componentes distribuidos en distintas máquinas monitorizadas.

El mero hecho de construir DAs es una buena  práctica para monitorizar los servicios pero, quizá no tanto si el hecho de crearlas nos exige un mayor mantenimiento del deseado.

Con el fin de mejorar esa situación tenemos la posibilidad de desarrollar nuestras DAs utilizando el Authoring Console Resource Kit, creando componentes que se vayan poblando de forma dinámica reduciendo al mínimo el mantenimiento posterior de
los mismos.

  • Es cierto que el uso del diseñador de DAs tiene una serie de ventajas, como pueden ser:
  • Un diseño intuitivo y sencillo sin necesidad de tener profundos conocimientos de desarrollo.
  • Abstraernos de la creación de clases, relaciones y discoveries de los componentes que creamos.
  • Una herramienta gráfica que con la cual rápidamente tenemos un vistazo de lo que será nuestra DA.
  • Etc.

Pero, también tiene una serie de limitaciones que, en ocasiones, podamos encontrar como inconvenientes. Por esto, para aquéllos administradores que tienen un bagaje más profundo en el desarrollo de Management Packs suelo recomendar el uso del
Authoring Console frente al diseñador de la Operations Console porque:

  • Es más versátil y nos da mayores posibilidades de desarrollo.
  • Podemos construir aplicaciones dinámicas frente a las estáticas que desarrollamos con el diseñador.
  • El desarrollo desde el Authoring Console es más ágil que desde el diseñador, sin necesidad de cargar todo el árbol de clases cada vez que creamos o editamos un componente. Tarea que en ocasiones, y dependiendo de la envergadura del entorno, puede llevarnos minutos por cada componente.
  • Podemos realizar tantos cambios como queramos y, tras un Verify del Management Pack y analizarlo con el MPBPA importarlo en nuestro entorno desencadenando una única distribución del Management Pack.
  • Etc,

Un ejemplo muy común de componente dinámico en una aplicación distribuida es el que menciono a continuación:

"¿Cómo podría crear un componente dinámico que albergue objetos Health Service Watcher de las máquinas/servidores que tienen desplegada la Aplicación X (Windows Local Application)?". Es decir, que si tras crear mi DA despliego un nuevo servidor con la aplicación X que automáticamente se añada su Health Service Watcher al componente indicado.

Si analizamos las relaciones existentes entre la clase Health Service Watcher, Health Sercice, Windows Computer y Windows Local Application (clase de la cual hereda nuestra clase "Application X") la respuesta es sencilla.

Tras crear nuestro Component Group, el discovery del mismo debería ser el que sigue:

<ManagementPack>
  <Monitoring>
    <Discovery ID="DemoDynamicDA.HSW.Discovery" Enabled="true" Target="DemoDynamicDA.HSWComponentGroup.Class" ConfirmDelivery="true" Remotable="true" Priority="Normal">
      <Category>Discovery</Category>
      <DiscoveryTypes>
        <DiscoveryClass TypeID="MSSCLib!Microsoft.SystemCenter.AgentWatcher" />
      </DiscoveryTypes>
      <DataSource ID="HSWCompDiscovery" TypeID="MSSCLib!Microsoft.SystemCenter.GroupPopulator">
        <RuleId>$MPElement$</RuleId>
        <GroupInstanceId>$Target/Id$</GroupInstanceId>
        <MembershipRules>
          <MembershipRule>
            <MonitoringClass>$MPElement[Name="MSSCLib!Microsoft.SystemCenter.AgentWatcher"]$</MonitoringClass>
            <RelationshipClass>$MPElement[Name="HSWComponentGroup_Membership_HealthServiceWatcherAgent"]$</RelationshipClass>
            <Expression>
              <Contains>
                <MonitoringClass>$MPElement[Name="MSSCLib!Microsoft.SystemCenter.HealthService"]$</MonitoringClass>
                <Expression>
                  <Contained>
                    <MonitoringClass>$MPElement[Name="MSWinLib!Microsoft.Windows.Computer"]$</MonitoringClass>
                    <Expression>
                      <Contains>
                        <MonitoringClass>$MPElement[Name="DemoDynamicDA.ApplicationX.Class"]$</MonitoringClass>
                      </Contains>
                    </Expression>
                  </Contained>
                </Expression>
              </Contains>
            </Expression>
          </MembershipRule>
        </MembershipRules>
      </DataSource>
    </Discovery>
  </Monitoring>
</ManagementPack>

Lo más importante en este ejemplo a tener en cuenta son las expresiones CONTAINS y COINTAINED. Analizando las relaciones podemos observar que existe una relación entre la clase Health Service Watcher y la clase Health Service, una relación Host entre la clase Windows Computer y la clase Health Service y, finalmente, una relación de Host entre Windows Computer y Windows Local Application (heredada por nuestra clase Application X) lo que nos permite que nuestro Component Group con el código de arriba se pueble dinámicamente respondiendo a la pregunta anterior.

Espero que esto os ayude a hacer más dinámicas vuestras aplicaciones y a investigar más el desarrollo utilizando el Authoring Console y, ahora con Operations Manager 2012 con Visual Studio Authoring Extensions .