PDF de programación - Monitoreo de PostgreSQL con Munin

Monitoreo de PostgreSQL con Munin

Gunnar Eyal Wolf Iszaevich

6 de febrero de 2011

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 her-
ramientas adecuadas de monitoreo, el administrador puede no sólo detec-
tar 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 gracación
de datos Munin, enfocándome a su uso para monitorear el gestor de base
de datos relacional PostgreSQL, así como en la exiblilidad y facilidad con
que administradores y programadores pueden adecuarlo para desarrollar
plugins especícos para el monitoreo de sus necesidades puntuales.

Palabras clave: Munin, monitoreo, análisis de tendencias, de-

sarrollo

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 exibility and ease with
which administrators and programmers can adequate it to develop specic
plugins for monitoring their specic needs.

Keywords: Munin, monitoring, tendency analysis, development

1

1.

Introducción

Prácticamente todas las organizaciones empresas, dependencias de Esta-
do, 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 ayu-
dar a través de la gracación a analizar tendencias en su uso, y a bosquejar
cómo desarrollar agentes de monitoreo especícos 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ícamente: Este trabajo es preparado para su presentación den-
tro 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 ocial 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.

Información histórica La función principal de Munin es presentar un concen-
trado con la evolución de los diferentes factores que monitoree del sistema,
fácil de analizar visualmente, presentando los detalles en vista diaria, se-
manal, mensual y anual. Una gráca ejemplo puede apreciarse en la gura
1.
En la gura 2 se aprecia un ejemplo dramático de la importancia de man-
tener 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

2

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

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

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.

Archivos estáticos Partiendo del principio de mínima supercie de exposi-
ció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ácas PNG.
Esto signica, claro, que la información presentada está en un formato
nal  Los niveles de cada una de las grácas nos es presentada por día,
semana, mes y año,

RRDtool Los datos recopilados por Munin son guardados en una base de datos

3

especializada, RRDtool [4]  Una base de datos respaldada en archivos
planos, orientada a guardar datos numéricos a intervalos de tiempo jos
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,
incluye además la funcionalidad de generación de grácas [6], y ha sido
empleado por un gran número de herramientas de monitoreo.

Componentes Munin se divide en tres componentes principales:

Servidor El único proceso que corre constantemente en todas las máquinas
monitoreadas. Su función es responder a las solicitudes del cliente,
y congurar 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.
Plugins Cada uno de los agentes de recolección de datos que son invo-
cados por munin-node. Dan la información que monitorean, y son
también capaces de describir su función y conguració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.

Autoconguración Uno de los atractivos del sistema es que no hace falta
invertir tiempo congurándolo para tener una conguración básica ade-
cuada al sistema, con los agentes plugins pertinentes congurados. Un
plugin puede indicar si considera recomendable su autoconguración, e
incluso con qué parámetros sugiere ser activado.

Es importante, sin embargo, mantener en mente que Munin no es un sis-
tema de alertamiento. Al hacer un monitoreo periódico y presentarnos la evolu-
ción de los indicadores del sistema a través del tiempo, sería comprensible es-
perar 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.

1Y, efectivamente, permite la noticación de ciertos eventos por correo electrónico. Para
quien requiera considerar un sistema exible y completo de monitoreo y alertamiento, sugeri-
mos referirse a Nagios [7].

2Hay fuentes de datos que muestran sus resultados como un acumulado, como el contador de
bytes transmitidos por una interfaz, y otras que muestran sus resultados como una magnitud
instantánea, como el nivel de carga del procesador. En caso del primero, Munin sí registrará los
picos que se presenten, pero en el segundo esto resulta imposible. Es fundamental comprender
la naturaleza de los datos a monitorear para obtener de ellos conclusiones válidas.

4

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

cong plugin Entrega la descripción de los datos a gracar (tanto ante el
humano como ante el gracador de RRDtool) y los rangos de datos esper-
ables.

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íco de PostgreSQL  Primero
a través de los plugins que son distribuídos por parte de los desarrolladores
ociales de Munin, seguido por aquellos que forman parte del sitio comunitario
Munin Exchange [8]. Después de revisar estas grácas 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 en junio d