Osmius es una herramienta de monitorización preparada para supervisar decenas de miles de elementos en entornos productivos.

Como herramienta Osmius ha sido diseñada para ser extremadamente robusta y muy rápida. Por ello cada componente software Osmius, desde los agentes que monitorizan, hasta la sentencias SQL que se lanzan contra la base de datos han sido optimizados y probados hasta la saciedad.

Según vamos teniendo más casos de utilización de Osmius en grandes instalaciones vemos y comprobamos las ventajas de haber diseñado Osmius como una arquitectura de componentes que nos permite afrontar las necesidades de grandes entornos corporativos en cuanto a:

• Distribución de la carga de monitorización
• Recuperación ante fallos de comunicaciones.
• Facilidad de Configuración

Estos tres elementos son de sobra cubiertos por las funcionalidades del software Osmius a través de los agentes maestros y a que la configuración de toda la instalación se guarda en la base de datos y se envía a los agentes en caso necesario. Leer más sobre la infraestructura de agentes de Osmius.

En Osmius es posible manejar toda la infraestructura a través de nuestro navegador: Cambiar parámetros de monitorización, distribuir scripts, actualizar agentes, activar modo proxy para redes privadas, etc.

Una instalación de Osmius con los componentes del servidor en una sola máquina tiene un rendimiento y una escalabilidad excelentes, pero cada vez más nos encontramos con entornos en los que se propone una distribución de componentes para cubrir necesidades de:

• Distribución en capas: Pooles de servidores Web, servidores de aplicaciones, bases de datos, control de seguridad.
• Escalabilidad: Vertical y horizontal.
• Alta Disponibilidad: Pooles de servicios activos o clusters activo-pasivo.
• Recuperación ante desastres: Copias de seguridad, vuelta atrás.

En el gráfico anterior se muestra la arquitectura de los componentes de la parte servidora de Osmius y de OSIP (Osmius Information Portal). Agentes y agentes maestros tienen su propia arquitectura distribuida como ya hemos comentado.

En una instalación media de Osmius todas las capas corren sobre un mismo servidor - virtual o físico - y la tolerancia a fallos y la recuperación ante desastres se dejan principalmente a cargo de las herramientas de copias de seguridad y recuperación. Por otro lado la escalabilidad se proyecta principalmente contra el servidor y sus recursos de CPU, Memoria y velocidad de los discos duros.

Los principales componentes de Osmius son:

• Servidor de Aplicaciones Consola: Tomcat 6.0 en la versión enterprise con acceso de lectura/escritura la base de datos sirviendo el WAR de Consola.
• Procesos del Engine de Osmius: Receptor de mensajes, gestor de tareas y otros, con acceso de lectura/escritura la base de datos.
• Base de Datos: Basada en MySQL 5.5.x en la versión enterprise. Todo el modelo está en InnoDB.

Por otro lado Osmius Information Portal tiene una base de datos MySQL propia (pequeña) y necesita acceso a la base de datos de Osmius en modo sólo lectura sirviendo el WAR de OSIP.

• Servidor de Aplicaciones OSIP: Tomcat 6.0 en la versión enterprise con acceso de lectura/escritura la base de datos.
• Base de Datos Propia: Basada en MySQL 5.5.x.
• Base de Datos de Osmius: Acceso sólo lectura (por eso puede ser una réplica).

Cómo se instala y configura una capa previa basada en Apache y que se conecte a un Pool de servidores TomCat queda fuera del ámbito de este documento pero si queremos reseñar que de esta forma - teniendo un pool de servidores de la cosolas de Osmius o del Portal OSIP - dotamos a la infraestructura de monitorización de capacidades de Alta Disponibilidad (en caso de caída de uno de los servidores podemos seguir accediendo) y de Escalabilidad Horizontal (al distribuir la carga de los servidores de aplicaciones. Ver Apache Tomcat 6.0 clustering/session replication.

A continuación se definen las características y necesidades de cada componente en cuanto a recursos, alta disponibilidad y recuperación ante desastres.

La consola de administración de Osmius consiste en una aplicación Java Web que se despliega en el servidor de aplicaciones Apache TomCat en su versión 6.0 (Osmius Enterprise Edition).

Dicha aplicación se conecta a la base de datos de Osmius (BDO) para la consulta de estado y valores de los eventos y para todas las acciones de definición y cambio de la configuración. No hay comunicación directa con los procesos del engine de Osmius.

Cuando desde la consola de administración se varía, por ejemplo, el tiempo de muestreo de un determinado evento se inserta una tarea en base de datos que posteriormente será tratada por el proceso encargado leyéndola y actulizándola en la base de datos.

Es por esto que este componente de la aplicación es relativamente estático y no cambia excepto en lo que se refiere a actualizaciones del software o en el contenido de los ficheros de log.

Al ser una aplicación desplegada en Tomcat, se puede beneficiar de las configuraciones en cluster que proporciona Apache Tomcat.

Revisar Apache Tomcat configuration reference

Osmius permite que existan varias consolas accediendo de forma simultánea a la base de datos.

Esto permite:

• Distribuir la carga de ejecución de los servidores de aplicaciones
• Distribuir a los usuarios por perfiles o redes de acceso
• Proporcionar capacidades de tolerancia a fallos.
• Aprovecharse de las ventajas de la Alta Disponibilidad para aplicaciones Web en Tomcat.

Si la instalación requiere de la utilización de un “pool” de servidores de aplicaciones aconsejamos seguir las recomendaciones de Apache TomCat respecto a Alta Disponibilidad.

Como hemos dicho la consola de Osmius es un elemento relativamente estático.

Desde Osmius suministramos un fichero.war con cada versión del producto que liberamos. Copiar y almacenar fichero omsius.war.

Si guardamos copia de dicho fichero podemos recuperarnos de una corrupción del software simplemente desglegando de nuevo dicho fichero en los servidores de aplicaciones Apache Tomcat 6.0.

El ”Osmius Engine” está formado por un conjunto de procesos que gestionan el inetrfaz entre los agentes de monitorización y la consola de administración a través de la base de datos.

Sus principales funciones son:

• Recibir, correlacionar e insertar en la base de datos todos los eventos recibidos de los diferentes agentes de la infraestrucutura.
• Atender las peticiones de conexión de los agentes maestros.
• Enviar las configuraciones de monitorización a toda la infraestructura de agentes distribuidos.
• Procesar las tareas tales como: envío de scripts, actualización de agentes, instalación de plugins.
• Comprobar que procesos y agentes se ejecutan correctamente e informar en caso de fallo.
• Procesar limpieza de históricos.
• Cálculos de SLA y de Previsiones de Capacidad y otros procesos estadísticos.

En general todos ellos se conectan a la base de datos la recomendación inicial es que corran en el mismo servidor en el que se encuentra la base de datos permitiendo así que las conexiones sean también locales.

Cada proceso consiste en un binario ($OSM_ROOT/bin/osm_<nombre_proceso>) que hace uso de unas librerías (localizadas en $OSM_ROOT/lib) y con un fichero de configuración (($OSM_ROOT/cfg/osm_<nombre_proceso>.cfg).

En este caso siempre habremos de adoptar una configuración Activo-Pasivo, es decir, que en principio no está soportado tener más de un conjunto de procesos del Engine accediendo a la base de datos.

Deberemos tener copiados, compartidos o sincronizados el directorio principal del Engineen ambas máquinas:

$OSM_ROOT, normalmente /opt/osmius/osmius

/-rw-rw-r-- 1 osmius osmius 3425 2011-01-13 16:31 README.txt
/-rw-rw-r-- 1 osmius osmius 4720 2011-01-13 16:31 LICENSE.txt
/-rw-rw-r-- 1 osmius osmius 1009 2011-01-13 16:31 INSTALL.txt
/drwxr-xr-x 4 osmius osmius 4096 2011-01-18 14:10 user
/drwxr-xr-x 3 osmius osmius 4096 2011-01-18 14:10 osmius
/drwxr-xr-x 2 osmius osmius 4096 2011-01-18 14:10 lib
/drwxr-xr-x 2 osmius osmius 4096 2011-01-18 14:10 bin
/drwxr-xr-x 2 osmius osmius 4096 2011-01-18 14:10 data
/drwxr-xr-x 4 osmius osmius 4096 2011-01-28 09:51 scripts
/drwxr-xr-x 2 osmius osmius 4096 2011-02-18 12:45 files
/drwxr-xr-x 3 osmius osmius 4096 2011-02-18 12:46 tmp
/drwxr-xr-x 2 osmius osmius 4096 2011-06-24 12:55 log
/drwxr-xr-x 2 osmius osmius 4096 2011-06-28 11:50 cfg

Además denemos arrastrar la IP de comunicación con los agentes en el cambio de servidor Activo.

Copiar los ficheros de configuración y los directorios de scripts y de ficheros:

• cfg
• user
• scripts
• files
• log (en caso de queres consultarlos posteriormente)

Los directorios de binarios ($OSM_ROOT/bin) y librerías ($OSM_ROOT/lib) bastará con copiarlos cada vez que cambiemos de versión de Osmius Enterprise, siempre consultando con los servicios de soporte.

La recomendación final es copiar todo el directorio $OSM_ROOT una vez al día y, como siempre, hacer periódicamente pruebas de restauración.

Se recomienda también, una vez terminada la recuperación, recargar desde la consola de Osmius la configuración del Agente maestro MASTER01 Agentes Maestros

La base de datos de Osmius (BDO) es el elemento más importante de una infraestructura de monitorización basada en Osmius. En la BDO se encuentran almacenados tanto los datos de:

• configuración de Instancias (eventos, umbrales, tiempos de pooling, plantillas)
• configuración de Servicios (ANS / SLA, horarios, dependencias)
• configuración de Infraestructura (agentes maestros, capacidades de monitorización, IPs de los agentes, etc)

Como los valores de cada uno de los eventos monitorizados y:

• Históricos de evolución de cada variable.
• Históricos de cambios de estados y de disponibilidad de cada Instancia.
• Históricos de cambios de estados y de disponibilidad de cada Servicio.
• Seguimiento de SLA / ANS.

Todo está organizado en torno a la base de datos y esto es tan así, que podemos recuperar una instalación de Osmius en una nueva máquina con una IP diferente sólo contando con una copia de seguridad de la BDO en una nueva máquina. Los procesos de Osmius extraerían la información de los Agentes Maestros, se conectarían con ellos, les enviarían la información necesaria para monitorizar las instancias y les informarían de la nueva IP del servidor central.

Algunas recomendaciones de Osmius respecto a la Base de Datos según nuestra experiencia en grandes entornos:

• Los procesos de Osmius han sido diseñados para consumir pocos recursos de CPU y de memoria, y aquellos que acceden a la base de datos (procesos centrales y consola) han sido revisados y todas las sentencias se han optimizado. Por eso conseguimos procesar de manera sostenida más de 500 eventos por segundo en hardware relativamente modesto. Aun así es importante afinar la base de datos en caso necesario ya que sería ella el primer cuello de botella de la totalidad de la infraestructura de Osmius.
• Memoria: Es importante asignar suficiente memoria RAM y asignársela al motor de InnoDB de Mysql de forma correcta (Osmius Enterprise ya viene configurado para utilizar la memoria de forma adecuada, pero en grandes entornos no está de más que el DBA la revise periódicamente).
• Almacenamiento en Disco: Con un “tuning” adecuado de la BDO el potencial cuello de botella acaba siendo la velocidad de acceso a los discos. Recomendamos prestar atención a que el almacenamiento esté adecuadamente distribuido (con los armario de discos con caches de memoria grandes ls distribución en RAID tiene menos impacto) y repartir la carga de datos e índices por un lado (innodb) y de los ” redo logs” y ” binary logs” por otro. En cualquier caso revisar filesystems con el administrador de almacenamiento no está de más.
• Cantidad de Variables Monitorizadas: Osmius está preparado para gestionar una gran cantidad de eventos por segundo y por lo tanto también lo está para gestionar históricos de datos “grandes”; de decenas de millones de eventos. Aun así es importante gestionar si vale la pena monitorizar 30 variables por cada elemento monitorizado y hacer cada 5 segundos. Las herramientas de Osmius para racionalizar el número de eventos almacenados son:
  • Agrupar variables monitorizadas en plantillas y modificar los tiempos de muestreo a la baja para eventos no fundamentales.
  • Activar la monitorización silenciosa de forma que los eventos sólo se guarden ante un cambio de severidad. Así además ahorramos en consumo de recursos de red.
  • Activar el “Roud Robin Database” agrupando eventos por hora o por día según vayan perdiendo actualidad.

Enlace a resumen de conceptos de Osmius.

Para la base de datos recomendamos utilizar el software de Alta Disponibilidad con el que nos encontremos cómodos y cumpla con los requisitos de tolerancia a fallos de nuestra instalación.

Hemos tenido conocimiento directo o indirecto de instalaciones de la BDO utilizando:

• MySQL Cluster (MySQL Enterprise Edition).
• DRDB y HeartBeat.
• Capacidades de AD de VMWare.
• HP Service Guard
• Veritas Cluster Server

Para el caso de clusters Activo/Pasivo Osmius está preparado para recuperarse del intervalo de pérdida de servicio de forma automática de forma que los agentes guardan en un buffer temporal los eventos monitorizados que reenvía al recuperarse las comunicaciones. Ver más sobre la infraestructura de Osmius.

Enlace a soluciones de Alta Disponibidad para MySQL.

En el punto anterior nos protegemos de caídas del servidor de base de datos o de las comunicaciones, pero no de la corrupción de los datos o de fallos humanos como por ejemplo el borrado de la configuración de las instancias (aunque esto en Osmius sería complicado de conseguir).

La solución de copia de seguridad y restauración deberá elegirse en función de los requisitos de la instalación respecto a:

• Tiempo de recuperación máximo tolerable: Que definirá si la solución será automática o manual y cuáles serán los costes tanto en hardware y software.
• Tiempo máximo de pérdida de datos: Define qué intervalo de datos podemos perder uan vez nos hallamos recuperado del desastre. En una herramienta de monitorización este tiempo no suele ser muy corto ya que lo que queremos en comenzar la monitorización cuanto antes y no importa tanto si recuperamos con los datos de ayer o de hace unos minutos.

Estos dos parámetros son los que indicaran si necesitamos hacer copias de seguridad (completas o incrementales) cada 5 minutos o cada noche, y si necesitamos una infraestructura de servidor de base de datos replicada por fibra a 30 kilómetros de la sede principal o nos basta con un robot de cintas.

Hecho este análisis Osmius recomienda realizar las copias de seguridad con herramientas especializadas que cumplan los requisitos en cada caso, como por ejemplo:

• Copias de seguridad lógicas mysqldump: Si el tamaño de la base de datos no es muy grande puede ser una opción para la recuperación automática de los datos.
• Copias de seguridad físicas: Copiando los “filesystems” de la base de datos directamente o mediante herramientas como Legato, OmniiBack, ExtraBackup.
• Copias de seguridad incrementales: Utilizando las herramientas anteriores o similares y los "//binary logs//"
• Réplicas Remotas: Las réplicas remotas de MySQL funcionan razonablemente bien y permiten distribuir carga de sólo lectura, pero también realizar copias de seguridad consistentes sin tener que parar el entorno de producción congelando por un tiempo el proceso de replicación de los datos. Leer procedimiento de creación de réplicas de la base de datos de Osmius.
• Réplicas locales o remotas usando BCV (” business continuance volumes”) o tecnologías similares.

Respecto a copias de seguridad lógicas:

• No está soportada la recuperación de la base de datos utilizando “dumps” parciales de la base de datos excepto cuando sólo se excluye la tabla de histórico del histórico OSM_DWH_HISTEVENTS.
• Para este procedimiento recomendamos utlizar la característica de Round Robin Database que Osmius ofrece.
• Si por alguna razón no se realiza copia de seguridad de OSM_HISTEVENTS, se debe ser consciente de que se alteraraán los históricos y las gráficas de todos los eventos monitorizados.

Respecto a particionamiento del modelo de Datos

• Actualmente no está soportado el particionamiento de las tablas del modelo de datos de Osmius excepto para la tabla OSM_DWH_HISTEVENTS.
• A pesar de el particionamiento de tablas permite abstraerse del número de particiones hay que tener en cuenta que:
  • Osmius puede reducir mucho el número de registros en OSM_HISTEVENTS usando RRDB y el modo “silent” en los eventos.
  • El particionamiento en este caso ideal sería por fecha (DTI_RECSERVER) que no es parte de la clave y puede traer problemas.
  • Para facilitar el particionamiento por DTI_RECSERVER lo ideal sería tener un campo precalculado y numérico por el día (YYYMMDD) que implica cambios en el motor de inserción pero también en todas las consultas para aprovechar bien el particionamiento.
  • Osmius realiza consultas a los eventos por diferentes campos e índices; lo que ganamos por un lado podemos perderlo por el otro.

Leer más sobre Restricciones y limitaciones del particionamiento en MySQL 5.1.

Las base de datos de réplica permiten el escalado horizontal de una instalación de monitorización basada en Osmius ayudando a:

• Distribuir la carga para procesos de solo lectura:
  • Base de datos para Osmius Information Portal (OSIP).
  • Base de datos para Dataware House y procesos de consulta.
  • Base de datos para consulta de Osmius en modo sólo lectura (perfiles Viewer y otros).
• Tener una copìa de los datos de producción en una localización remota (DR)
• Facilitar copias de los datos consistentes en el tiempo.

La replicación de bases de datos MySQL es una herramienta muy utilizada para mejorar la escalabilidad y la tolerancia a fallos de aplicaciones con datos masivos. Podemos replicar a una o más bases de datos, y en éste último caso, elegir diferentes papeles para cada una de las bases de datos de réplica.

Revisar el procedimiento de creación de réplicas de Osmius.

Normalmente las réplicas no se suelen instalar en infraestructuras de alta disponibilidad, ya que ya son ellas mismas una copia de una base de datos principal y, de hecho, es común que sean ellas mismas parte de una solución de alta disponibilidad.

De todas formas, y como ocurre con la BDO, recomendamos utilizar el software de Alta Disponibilidad con el que nos encontremos cómodos y cumpla con los requisitos de tolerancia a fallos de nuestra instalación.

Enlace a soluciones de Alta Disponibidad para MySQL.

Ocurre lo mismo que en el caso anterior; hacer copias de seguridad de una réplica no tiene demasiado sentido a no ser que utilicemos dicha copia como forma de recuperar la base de datos origen o principal.

Sí es común este último caso en el que utilizamos la réplica para hacer una copia de seguridad consistente en el tiempo (congelando temporalmente el traspaso de datos) de una base de datos en producción y con una tasa de cambio alta o muy alta.

Si de todas formas es ncesario realizar copias de seguridad de las bases de datos de réplica recomendamos los mismos procedimientos y herramientas que en la Base de Datos de Osmius.

Osmius Information Portal (OSIP) es un portal web de Business Intelligence para proveedores de monitorización que puede ser instalado como una herramienta externa a Osmius Enterprise Edition. OSIP proporciona una manera sencilla de acceder a los datos almacenados en cualquier número de bases de datos de Osmius, con cuadros de mando configurables que además pueden integrarse con fuentes de datos externas fácilmente.

OSIP es especialmente útil in entornos de monitorización multi-site tales como grandes corporaciones y proveedores de monitorización.

Como portal web, OSIP puede gestionar comunidades, roles y permisos y puede integrarse con otras aplicaicones web. De esta forma, puede gestionar sus usuarios y componer pantallas desde las que éstos puede visualizar no sólo los datos de los servicios monitorizados por Osmius, también hacer seguimiento de otros datos como emails, calendarios, datos con origen en la nube…

Este esquema es perfecto para gestionar los clientes de un proveedor de monitorización o para un departamento tradicional de IT para proporcionar cuadros de mando a los usuarios finales. OSIP les permite abstraerse de los procesos de monitorización utilizando una aplicación orientada a negocio que pone el foco en los datos recogidos por el sistema de monitorización, haciendo más sencillo visualizar y comprender qué está ocurriendo en sus servicio y enriquecer esta experiencia con datos externos.

OSIP accede a la base de datos de Osmius en modo solo lectura, lo que nos permite utilizar las réplicas como origen de datos y dota a la solución Osmius + OSIP de escalabilidad horizontal, distribución de carga y capacidades de recuperación ante fallos.

OSIP almacena sus datos de configuración en una base de datos propia de MySQL. La recomendación es crear el esquema en la base de datos de Osmius, permitiendo que entre también en el flujo de las réplicas.

Al ser una aplicación desplegada en Tomcat, se puede beneficiar de las configuraciones en cluster que proporciona Apache Tomcat.

Revisar Apache Tomcat configuration reference

Pueden existir varias consolas de OSIP accediendo a una o varias bases de datos.

Esto permite:

• Distribuir la carga de ejecución de los servidores de aplicaciones
• Distribuir a los usuarios por perfiles o redes de acceso
• Proporcionar capacidades de tolerancia a fallos.
• Aprovecharse de las ventajas de la Alta Disponibilidad para aplicaciones Web en Tomcat.

Si la instalación requiere de la utilización de un “pool” de servidores de aplicaciones aconsejamos seguir las recomendaciones de Apache TomCat respecto a Alta Disponibilidad.

La consola de OSIP es un elemento relativamente estático.

Desde Osmius suministramos un fichero.war con cada versión del producto que liberamos. Copiar y almacenar fichero OSIP.war.

Si guardamos copia de dicho fichero podemos recuperarnos de una corrupción del software simplemente desglegando de nuevo dicho fichero en los servidores de aplicaciones Apache Tomcat 6.0.