PDF de programación - Monitoreo de PostgreSQL con Munin

Monitoreo de PostgreSQL con Munin

PostgreSQL monitoring with Munin

Gunnar Eyal Wolf Iszaevich

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 D.F. 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 claves: 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

todas

Prácticamente
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 [1], 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 sus usuarios el
desarrollo de agentes recolectores de información para adecuarlo a sus necesidades.
Más específicamente: Este trabajo es preparado para su presentación dentro de los trabajos del III
PGDay Latinoamericano 2011 [2], razón por la cual haremos é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 [3].

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.

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 es presentada por día, semana, mes y año,

RRDtool Los datos recopilados por Munin son guardados en una base de datos especializada,
RRDtool [4] — Una base de datos respaldada 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 [5], iniciado en 1994, y convertido en un proyecto
independiente hacia 2001. Como herencia de éste proyecto,
la
funcionalidad de generación de gráficas [6], y ha sido empleado por un gran número de
herramientas de monitoreo.

incluye además

Componentes Munin se divide en tres componentes principales:

Servidor El único proceso que corre constantemente en

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.

todas

Plugins Cada uno de los agentes de recolección de datos que son invocados por munin-
node. Dan la información que monitorean, y son también capaces de describir su
función y configuración.

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.

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
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 recordar 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.1 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ípicamente /etc/munin/plugins).

config plugin Entrega la descripción de los datos a graficar (tanto ante el humano como ante el

graficador de RRDtool) y los rangos de datos esperables.

fetch plugin Efectúa la consulta a los datos solicitados, regresando los valores obtenidos.

Si bien hay algunos comandos adicionales, para implementar un plugin sencillo basta con
implementar este comportamiento.

3. PLUGINS DISPONIBLES PARA POSTGRESQL

Iniciemos el acercamiento al monitoreo específico de PostgreSQL — Primero a través de los
plugins que son distribuídos por parte de los desarrolladores oficiales de Munin, seguido por
aquellos que forman parte del sitio comunitario Munin Exchange [8]. Después de revisar estas
gráficas disponibles, cubriremos cómo desarrollar plugins a la medida.

3.1 COMO PARTE DE MUNIN

Como parte de la versión 1.4.5 de PostgreSQL, publicada