PDF de programación - Monitoreo de PostgreSQL con Munin

Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | [email protected]


Tipo de artículo: Artículo original
Temática: Sistemas de bases de datos
Recibido: 213/2011 | Aceptado: 18/4/2011 | Publicado: 29/9/2011

Monitoreo de PostgreSQL con Munin

PostgreSQL monitoring with Munin

Gunnar Eyal Wolf Iszaevich1*

1 Instituto de Investigaciones Económicas, Universidad Nacional Autónoma de México; [email protected]; Cto. Mtro. Mario de la Cueva S/N,

Ciudad Universitaria, México DF 04510



Resumen: Una de los principales tareas del trabajo diario de un administrador de sistemas, redes o bases de datos es

el monitoreo de recursos. Con herramientas adecuadas de monitoreo, el administrador puede no sólo detectar un

problema antes de que cause interrupciones en la operación de los sistemas, sino que puede prevenir que ocurran,

conociendo la evolución histórica de los valores relevantes. En el presente trabajo presento el marco de recopilación y

graficación de datos Munin, enfocándome a su uso para monitorear el gestor de base de datos relacional PostgreSQL,

así como en la flexiblilidad y facilidad con que administradores y programadores pueden adecuarlo para desarrollar

plugins específicos para el monitoreo de sus necesidades puntuales.

Palabras clave: Munin; monitoreo; análisis de tendencias; desarrollo



Abstract: One of the main tasks a system, network or database administrator must face in his everyday work is

resource monitoring. Given the adequate tools, an administrator can not only detect a problem before it disrupts

systems’ operations, but can prevent it from happening, by knowing the historic evolution of the relevant values. In

this work, I am presenting the Munin data gathering and graphing framework, focusing on its use for monitoring the

PostgreSQL relational database management system, as well a on the flexibility and ease with which administrators

and programmers can adequate it to develop specific plugins for monitoring their specific needs.

Keywords: Munin; monitoring; tendency analysis; development



1. Introducción

Prácticamente todas las organizaciones –empresas, dependencias de Estado, entidades académicas, etc.– han visto

cómo los procesos informáticos van ocupando lugares cada vez más centrales en su operación. Para mantener su

operación, se han creado los roles de administradores de sistemas, de redes, de bases de datos, etc.

El trabajo de estos administradores debe ser preventivo, no reactivo — Esto es, un buen administrador de sistemas

debe estar atento a los cambios que se presentan en los servicios a su cargo, para poder atacar a los problemas antes

de que se presenten. Una de las tareas más importantes que es necesario realizar periódicamente, para encontrar

tendencias y anticiparse a los problemas, es el monitoreo de recursos.

El presente trabajo se enfoca en presentar a Munin (2004), una herramienta orientada a trabajo en red de monitoreo

histórico de recursos que puede ayudar –a través de la graficación– a analizar tendencias en su uso, y a bosquejar

cómo desarrollar agentes de monitoreo específicos a elementos no contemplados por un desarrollo genérico. Entre sus

criterios de diseño se encuentra el ofrecer una instalación muy simple, plug-and-play, y al mismo tiempo facilitar a

Grupo Editorial ―Ediciones Futuro‖
Universidad de las Ciencias Informáticas. La Habana, Cuba
[email protected]

1

Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | [email protected]

sus usuarios el desarrollo de agentes recolectores de información para adecuarlo a sus necesidades. El enfoque

específico del presente trabajo hace énfasis en el uso de Munin para monitorear bases de datos PostgreSQL.

Nuestra intención es presentar a Munin detallando algunos casos de uso; para encontrar referencias de uso,

administración y desarrollo, sugerimos consultar la documentación oficial del proyecto (Munin-Doc, 2004), así como

el libro Munin: Graphisches Netzwerk- und System-Monitoring (Pohl, 2008).

2. Arquitectura operativa de Munin

A continuación, delineamos los criterios básicos de desarrollo de Munin. Cabe mencionar que la versión 2.0,

actualmente en desarrollo, probablemente revise o retire alguno de los puntos aquí mencionados.



Figura 1: Resultado del monitoreo con Munin: Gráfica del día, la semana, el mes y el año de interrupciones y cambios de contexto



Información histórica: la función principal de Munin es presentar un concentrado con la evolución de los diferentes

factores que monitoree del sistema, fácil de analizar visualmente, presentando los detalles en vista diaria, semanal,

mensual y anual. Una gráfica ejemplo puede apreciarse en la figura 1.



En la figura 2 se aprecia un ejemplo dramático de la importancia de mantener el contexto histórico de la información:

Al considerar los niveles de uso del sistema de archivos con una temporalidad local, a través del día o de la semana, la

voz de alerta parece ir sobre el uso cercano al 90% de uno de los sistemas de archivos (indicado por el color verde);

sin embargo, al ver la información anual, resultan mucho más alarmantes el crecimiento limeal sostenido del sistema

marcado con el color naranja, que aumentó a una tasa constante casi un 10% de utilización a lo largo de seis meses, y

más aún, el comportamiento aparentemente exponencial del indicado por el color rojo, que pasó del 20% en

septiembre al 40% en noviembre.



Grupo Editorial ―Ediciones Futuro‖
Universidad de las Ciencias Informáticas. La Habana, Cuba
[email protected]

2

Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | [email protected]


Figura 2: Importancia de la información histórica en las gráficas de niveles del sistema (leyenda recordada para conservar el espacio)

Archivos estáticos: partiendo del principio de mínima superficie de exposición, y a diferencia de buena parte de los

marcos de monitoreo accesibles por Web, consultar los datos recopilados por Munin no requiere de la ejecución de

código — Toda la información generada por Munin queda disponible como archivos HTML y gráficas PNG.

Esto significa, claro, que la información presentada está en un formato final — Los niveles de cada una de las gráficas

nos son presentados en la configuración default por día, semana, mes y año.

RRDtool: los datos recopilados por Munin son guardados en una base de datos especializada, RRDtool (Oetiker,

1994a) — Una base de datos basada en archivos planos, orientada a guardar datos numéricos a intervalos de

tiempo fijos y de una duración total predeterminada, lo cual lleva como consecuencia directa que el espacio de

almacenamiento de cada base no crece a lo largo del tiempo.

RRDtool nació como parte de MRTG (Oetiker, 1994b), iniciado en 1994, y convertido en un proyecto

independiente hacia 2001. Como herencia de éste proyecto, incluye además la funcionalidad de generación de

gráficas (Roncero, 2002), y ha sido empleado por un gran número de herramientas de monitoreo.

2.1 Componentes

Munin se divide en tres componentes principales:

1. Servidor: el único proceso que corre constantemente en todas las máquinas monitoreadas. Su función es

responder a las solicitudes del cliente, y configurar y llamar a los plugins, manejando todos los aspectos

relacionados con la comunicación en red. El servidor debe ejecutarse con privilegios de superusuario, para

poder lanzar a cada uno de los plugins con los privilegios que requieran. Al servidor veremos que muchas

veces se hace referencia también como munin-node, al ser el componente que corre en todos los nodos.

2. Plugins: Cada uno de los agentes de recolección de datos que son invocados por munin-node. Entregan los

niveles de la información que monitorean, y son también capaces de describir su función y configuración.

3. Cliente: Proceso que corre periódicamente (típicamente cada 5 minutos) desde un nodo central,

interrogando a cada uno de los servidores, y generando las páginas Web estáticas.

Grupo Editorial ―Ediciones Futuro‖
Universidad de las Ciencias Informáticas. La Habana, Cuba
[email protected]

3

Revista Cubana de Ciencias Informáticas (RCCI)
ISSN: 1994-1536 | RNPS: 0547
http://rcci.uci.cu | [email protected]

2.2 Autoconfiguración

Uno de los atractivos del sistema es que no hace falta invertir tiempo configurándolo para tener una configuración

básica adecuada al sistema, con los agentes (o plugins) pertinentes configurados. Un plugin puede indicar si considera

recomendable su autoconfiguración, e incluso con qué parámetros sugiere ser activado.

Es importante, sin embargo, mantener en mente que Munin no es un sistema de alertamiento. Al hacer un monitoreo

periódico y presentarnos la evolución de los indicadores del sistema a través del tiempo, sería comprensible esperar

que Munin funcionara como sistema de alertamiento1. Sin embargo, es fundamental recalcar que el monitoreo que

realiza es periódico, consultando los niveles cada cinco minutos. Munin no hace monitoreo continuo, sólo en puntos

discretos en el tiempo2.

2.3 Protocolo de consulta

El protocolo de consulta al servidor de Munin es muy simple, orientado a texto (por lo cual el funcionamiento de un

plugin puede monitorearse fácilmente desde la línea de comandos). La interacción básica consiste de los siguientes

tres comandos:





list: presenta un listado de los plugins disponibles. Éste listado es básicamente el listado de archivos presentes

en el directorio de plugins (típic