Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2014 sistema de monitorización

351 views

Published on

Published in: Technology
  • Be the first to comment

2014 sistema de monitorización

  1. 1. SISTEMA DE MONITORIZACIÓN PARA UNA ARQUITECTURA SOA José Román Fernández Engo1 1 Área de Desarrollo y Gobernanza SOA. Subdirección de Tecnologías de la Información y las Comunicaciones. Servicio Andaluz de Salud. 41092-Sevilla. España. Resumen. Una pieza fundamental en la gobernanza de una Arquitectura SOA es su monitorización. El cuadro de mandos presentado es la herramienta que permite mantener monitorizada la red de buses federados hospitalarios del Servicio Andaluz de Salud y el comportamiento de los módulos que interactúan con la misma. En este sentido se supervisan tanto aspectos relacionados con la salud tecnológica de la plataforma como de los eventos recogidos en el consumo o provisión de los servicios del catálogo de servicios de la STI. El cuadro de mandos permite, en consecuencia, detectar de forma temprana posibles problemas relacionados con la provisión o consumo de servicios levantando alertas que puedan ser interpretadas con facilidad tanto por los usuarios como por los profesionales tecnológicos. Adicionalmente el cuadro de mandos facilita la trazabilidad de los eventos y la fuente delos mismos para identificar el resolutor más indicado para cada problema detectado. 1. Introducción Desde finales de 2.009 el Servicio Andaluz de Salud viene trabajando en la adopción de una estrategia orientada a servicios (STIC - SSPA, 2.011) para la gestión de sus sistemas de información. Esta adopción, provocada principalmente de la necesidad de alcanzar una interoperabilidad efectiva de los sistemas (Fernández Engo, 2012), está basada principalmente en la asunción de una gobernanza efectiva de la información, procurando un conocimiento profundo de los procesos y flujos de información de la organización, el modelado de los mismos y la definición e implementación de los servicios que componen estos procesos, una intensa utilización de estándares (Fernández Engo, Andalusia Health Service: a new SOA and HL7 Strategy, 2012) y la formación de un equipo de tecnólogos expertos (Fernández Engo, Oficina Técnica de Interoperabilidad del Servicio Andaluz de Salud, 2011) que permiten la aplicación de este modelo. En este contexto, la monitorización de los servicios se convierte en parte fundamental de la estrategia a aplicar. 2. Alcance del Sistema y condiciones de funcionamiento. El cuadro de mandos ESB es una herramienta que permite mantener monitorizada la red de buses federados hospitalarios y las integraciones de los módulos que interactúan sobre ellos. En este sentido se monitorizarán tanto aspectos relacionados con la salud de la plataforma como de los eventos recogidos en el consumo o provisión de los servicios del catálogo de integraciones de la STI. En concreto desarrolla: • Monitorización activa de métricas hardware y comunicaciones de la plataforma ESB
  2. 2. • Monitorización de las métricas relacionadas con el funcionamiento de los diferentes servicios del catálogo • Identificación de las métricas de los consumidores de servicios del ESB. • Visualización global del estado de los módulos consumidores de los servicios. • Alertar a los usuarios mediante iconos representativos, correos electrónicos y SMS. Para su correcto funcionamiento es necesario que las estaciones implementen de forma correcta la política de gestión de errores definida por la organización (STIC - SSPA, 2.011). En caso contrario, se dan falsos positivos que deben ser resueltos por el personal de la OTI. 3. Contenido El sistema de monitorización está concebido para representar el estado de salud de la infraestructura de servicios tanto a nivel tecnológico (ya implementado) como de negocio. Intenta homogeneizar el tratamiento de los errores, códigos de alerta, etc. de forma que quien lo gestiona tenga una referencia clara y unificada de los niveles de gravedad, qué se está gestionando, etc. Icono Descripción Critical. El estado de la métrica supera los umbrales definidos como críticos Warning. El estado de la métrica ha alcanzado el umbral definido de advertencia aunque no se ha alcanzado el umbral crítico. OK. El servicio se comporta con normalidad, el funcionamiento es correcto El servicio está siendo configurado por los administradores de la plataforma o no se ha podido capturar la métrica en la última ventana de monitorización El servicio tiene un problema en vías de solución. Se considera el problema como conocido. Tabla 1: Iconos. Código de colores 3.1. Sistemas El primero de los niveles monitorizados es el nivel de sistemas que abarca desde el nivel más bajo de hardware (disco, memoria, etc.) a la gestión derivada del sistema operativo, incluyendo el estado de salud del cluster. Como en todos los niveles de monitorización de la herramienta se presenta a nivel gráfico con la posibilidad de bucear a dato o indicador concreto en caso necesario. Permite la detección de variables importantes como los periodos de purgado del sistema. Ilustración 1: captura de monitorización de sistemas
  3. 3. Variables monitorizadas Descripción Clustat Estado del cluster (2 nodos balanceados activo/pasivo) ENSEMBLE_DATA Espacio de disco utilizado para la partición de datos. En dicha partición están registrados los diferentes ítems de integración así como los mensajes de interoperabilidad registrados en las transacciones. ENSEMBLE_JOURNAL Espacio de disco utilizado para el Journaling. En dicha partición se registran todas las operaciones que se van registrando en el ESB. Su utilidad consiste en restaurar el sistema ante fallos. ENSEMBLE_SYSTEM Espacio de disco utilizado por la instalación del ensemble. Espacio en CACHETEMP Espacio de disco temporal utilizado por la plataforma intersystems Nivel de carga El nivel de trabajo computacional que puede gestionar el sistema ESB Puerto TCP 56775 Latencia a través del puerto (56775). Puerto utilizado para conectar con la BBDD de caché Puerto TCP 57775 Latencia a través del puerto (57775). Puerto sobre el que escuchan los servicios web publicados por el ESB. Total de procesos Número total de procesos corriendo en el sistema Total de procesos CACHE Número total de procesos de la plataforma caché corriendo en el sistema Total de procesos CUXD Número total de procesos específicos de la plataforma de ensemble Total de procesos HTTPD Número total de procesos Total de procesos Java Número total de procesos JAVA en ejecución. Algunos procesos tienen necesidad de atacar a una BBDD Oracle a través de JDBC, esta métrica contabiliza los procesos en ejecución de este tipo Uso de CPU Porcentaje de uso de la CPU Uso de RAM Detalle de uso de la memoria RAM Tabla 2: ejemplo de variables de sistema 3.2. Servicios publicados Tanto en esta sección como la siguiente nos basamos en el comportamiento mostrado por la capa de servicios del sistema, ya sea dentro o fuera del bus, para mantener la imagen de la salud del sistema. Básicamente nos basamos en la monitorización de las siguientes variables: Variables monitorizadas Descripción Nº de transacciones Nº de transacciones registradas para el servicio Tiempo medio de cada transacción Tiempo medio en segundos registrado en cada servicio Porcentaje de errores registrados Porcentaje de errores registrado con respecto a las dos últimas horas monitorizadas Nº de mensajes encolados Número de mensajes encolados por servicio Total de mensajes encolados por destino Número total de mensajes de por cola. Tabla 3: ejemplo de variables de servicios A través de los siguientes niveles de abstracción:
  4. 4. Ilustración 2: niveles de abstracción de los servicios De las 5 capas la correspondiente de hospital sólo es visible para los administradores del cuadro de mandos mientras que el resto es accesible para todos los perfiles. Cada uno de los 5 niveles de anidamiento recoge todas las métricas del grupo inmediatamente anterior representando, de acuerdo al código de colores indicado anteriormente el estado de la agrupación. Bastará que una métrica tenga estado Warning o critical para que todas las agrupaciones de mayor abstracción representen el estado del servicio más crítico. Ilustración 4: servicios detalleIlustración 3: servicios nivel 3
  5. 5. Para ilustrar la manera de interpretar la existencia de estas circunferencias conviene poner en conocimiento algunos aspectos básicos de las integraciones que corren en el ESB. Las integraciones monitorizadas en este cuadro de mandos se sustentan de las trazas que registra el ESB al recibirse y entregar los mensajes de los servicios del catálogo. En muchas de estas integraciones el ESB actúa como enrutador identificando los destinos correspondientes y entregando los mensajes, no obstante en muchas otras integraciones el ESB realiza una orquestación completa en base a lógicas complejas que suponen incluso transformación de los mensajes en otros distintos. Teniendo en consideración este aspecto se identifican dos fuentes de información a revisar que se interpretarán en el cuadro de mandos de la siguiente manera:  Problemas derivados de las orquestaciones que gestiona el ESB se representan en la circunferencia interior. Cualquier error detectado en este ámbito genera la creación de una incidencia en el equipo de Gestión de Incidencias TIC de la organización con resolutor OTI para su estudio y corrección.  Problemas detectados en la entrega y aceptación de los mensajes en los suscriptores. Los problemas detectados en el ESB se representarán en la circunferencia exterior. Si se detecta algún error en los suscriptores será necesario acceder a la siguiente vista para identificar que suscriptor o suscriptores presentan problemas. 3.3. Consumidores: colas de mensajería Generalmente cuando se producen errores técnicos en una aplicación suelen afectar a todos o a la mayoría de los servicios a los que dicha aplicación está suscrito. Teniendo en cuenta este aspecto resulta conveniente representar el estado de una cola de mensajes por cada suscriptor ya que de esta manera se visualizará con rapidez cuando haya un problema en una aplicación suscriptora concreta que requiera intervención inmediata. La propia lógica implementada en el ESB supone la definición de una o varias colas de mensajería por negocio y destino que pueden ser monitorizadas desde esta vista como complemento a la vista de aplicación. La métrica que se monitoriza en ella se corresponde con el número de mensajes encolados que tiene cada aplicación. 4. Impacto: alertas tempranas y contratación El cuadro de mandos es una herramienta de apoyo y, por lo tanto, la interacción con la misma debería ir encaminada a consultas concretas en el rastreo de problemas y para identificar los posibles resolutores de los problemas detectados. También puede utilizarse para revisar las gráficas de evolución registradas que nos aportarán más información que el dato discreto de una métrica en critical. De esta manera podrán observarse tendencias, patrones y realizar previsiones para tareas de mantenimiento y planes de actuación. La forma más ágil para poner en conocimiento los problemas detectados por la plataforma es la parametrización de alertas desatendidas. Existen dos mecanismos de configuración de estas alertas que son el envío de emails y de SMS a teléfonos móviles.
  6. 6. Para configurar los destinatarios de estas alertas se contacta con el equipo de la OTI que procede al alta de las direcciones de correo y teléfonos. Cada vez que una métrica cambia su estado en cualquier tipo de transición (OK -> Warning, Warning -> Critical, Critical -> OK) se recibe una alerta indicando el detalle del servicio problemático, si el problema es sostenido en el tiempo se notifican alertas periódicas refrescando el estado de la métrica hasta que la misma retorna al estado de funcionamiento normal. Cuando un problema quede debidamente acotado, para evitar este tipo de notificaciones es necesario marcar la alerta como “Problema conocido”, momento en el que dejan de recibirse alertas de ese servicio. Así mismo, y derivado de la monitorización por estaciones reflejada en el punto anterior, se empieza a gestionar la inclusión en los desarrollos de acuerdos de nivel de servicios medidos gracias a esta herramienta. En concreto se contemplan dos principales: Tiempo de disponibilidad de los servicios, especialmente servicios críticos como son los de gestión intrahospitalaria del paciente o la consulta de informes de resultados. Gestión de los tiempos de vida de las colas de mensajería. 5. Conclusiones Los procedimientos asociados a la gobernanza ayudan a controlar y garantizar el correcto movimiento de la información a través de las aplicaciones. La disponibilidad de una infraestructura de Buses, la orientación a servicios y la monitorización de estos ayudan de forma muy notable a la consolidación de esta gobernanza y a sacarle el máximo rendimiento en todos los sentidos, desde la pura alerta temprana ante posibles eventos tecnológicos a la gestión de los contratos de los consumidores, pasando por la posibilidad de la gestión de errores a nivel funcional. Referencias Fernández Engo, J. R. (Febrero de 2011). Oficina Técnica de Interoperabilidad del Servicio Andaluz de Salud. I+S Informática y salud(91), 29-35. Fernández Engo, J. R. (Mayo de 2012). Andalusia Health Service: a new SOA and HL7 Strategy. HL7 International News, 16-17. Fernández Engo, J. R. (2012). Gobernanza SOA e Interoperabilidad: Servicio Andaluz de Salud. (F.-F. p. eSalud, Ed.) Revista eSalud, 8(32), 1-11. STIC - SSPA. (2.011). Unifica. Portal de conocimiento de la Subdirección de Tecnologías de la Información. Servicio Andaluz de Salud. Obtenido de Área pública de Interoperabilidad.: https://ws001.juntadeandalucia.es/unifica/interoperabilidad

×