Este documento describe un sistema de monitorización para una arquitectura SOA implementada en el Servicio Andaluz de Salud. El sistema permite monitorizar la red de buses federados hospitalarios y el comportamiento de los módulos que interactúan con ella. Proporciona alertas tempranas sobre posibles problemas relacionados con la provisión o consumo de servicios para facilitar su detección y resolución.

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. • 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. 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. 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. 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. 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