Munin: creando plugins

En el artículo anterior vimos las características de Munin; en esta ocasión veremos cómo adaptarlo a nuestras necesidades escribiendo plugins específicos para nosotros.

Los plugins pueden escribirse en cualquier lenguaje. Veremos la estructura básica, independiente del lenguaje en el que lo escribamos.

Lo básico

Un plugin para munin debe escribir sus resultados por la salida estándar. Lo importante es cumplir varias condiciones:

1. La ejecución debe ser rápida. Pensad que se lanzará al menos una vez por minuto y que, si tarda demasiado, Munin asumirá que ha fallado.
2. No debe consumir muchos recursos. Cuantos más requiera, más influirá el observador en lo observado.

Además, un plugin puede recibir un parámetro, indicando el tipo de operación que se requiere. Vamos a ver qué parámetros hay, cuáles son obligatorios y cuáles opcionales. Podéis encontrarlos todos en The Concise guide to plugin authoring, aquí sólo comentaré los más importantes:

Sin parámetros

Obligatorio. La llamada más básica es sin parámetros. Munin llamará así a sus plugins cuando le interese recoger las mediciones.

Su estructura es la siguiente:

1

[métrica].value [valor]

Nuestro plugin podrá devolver varias líneas como ésa, con una métrica por línea. Ejemplo:

1
2

load.value 7.8890
memory.value 84.321

config

Obligatorio. Cuando se llame a nuestro plugin con el parámetro “config”, significa que munin nos pregunta qué valores vamos a devolver. La estructura básica puede ser la siguiente:

1
2
3
4

graph_title [Título de nuestro gráfico]
graph_category [Categoría en la que clasificar nuestro gráfico]
graph_vlabel [Etiqueta del eje vertical]
[métrica].label [Etiqueta de la métrica]

autoconf

Opcional. Devolverá “yes” cuando el plugin detecte que se cumplen todas las condiciones para poder ejecutarse. Por ejemplo, un plugin que toma mediciones de Jenkins podría detectar si Jenkins está instalado.

En caso de que no se cumplan estas condiciones, devolverá “no. [razón]”, de manera que la razón aparezca cuando ejecutemos munin-node-configure, como vimos en el artículo anterior.

Para utilizar esta característica, debemos añadir en un comentario las cadenas:

1
2

#%# family=auto
#%# capabilities=autoconf

suggest

Opcional. Munin suele crear un gráfico por plugin, pero en ocasiones podemos necesitar más: un plugin que comprueba un puerto podría comprobar varios; varias interfaces de red en lugar de una, etc.

Para que funcione, requiere encontrar en el código la cadena “#%# capabilities=suggest”, aunque podemos aprovechar la de autoconf, separándolo con espacios:

1

#%# capabilities=autoconf suggest

Al llamarlo con esta opción, el plugin debe imprimir qué recursos puede atender. Al llamarlo sin parámetros, el plugin tomará un parámetro extra de su propio nombre, por lo que deberemos llamarlo “plugin_parámetro”. Ejemplo:

1
2
3

if_ suggest
eth0
eth1

En este ejemplo podríamos configurar los plugins “if_eth0” e “if_eth1”. Mirad el apartado de instalación para terminar de entenderlo.

Instalación

Para instalar nuestro plugin, basta con copiarlo con los plugins de Munin, en el directorio /usr/share/munin/plugins. Una vez hecho esto, existen dos opciones:

• Si nuestro plugin admite “autoconf”, podemos instalarlo tal y como se explicó en el artículo anterior:

1

$ munin-node-configure --suggest --remove-also --shell | bash

• Si no es así, podemos crear un enlace a mano en el directorio /etc/munin/plugins. En este caso, debemos tener dos cosas en cuenta:

  • Si más tarde usamos munin-node-configure, el enlace se borrará.
  • Si acepta la opción suggest, deberíamos crear los enlaces con el parámetro que se requiere. Ejemplo:

1
2
3

$ ls -l /etc/munin/plugins/if_*
if_eth0 -> /usr/share/munin/plugins/if_
if_wlan0 -> /usr/share/munin/plugins/if_

Multigráficos

En ocasiones puede interesarnos generar varios gráficos desde un único plugin en lugar de provocar varias llamadas al mismo con distintos argumentos. Por ejemplo, si estamos obteniendo información de los trabajos de Jenkins, es absurdo (y lento) solicitarle dos veces la misma información a Jenkins. Por eso podemos generar dos gráficos desde el mismo plugin.

Para ello debemos alterar la salida de las mediciones y de la configuración, añadiendo en ambas multigraph [nombre del gráfico] al comienzo de cada gráfico. El “nombre del gráfico” debe coincidir en la configuración y los valores.

Ejemplo completo en bash

Veamos un ejemplo completo en bash: Un pequeño plugin que muestra el estado de la cola en Jenkins. Soportará autoconf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#!/bin/sh

JENKINS_URL=https://localhost:8080

#%# family=auto
#%# capabilities=autoconf

case $1 in
    config)
        cat <<'EOM'
graph_title Jenkins queue
graph_category Jenkins
graph_vlabel jobs
load.label Num of Jobs
EOM
    ;;
    autoconf)
        if [[ $(wget -q $JENKINS_URL) ]]; then echo "no. Jenkins is not running";
        else echo "yes"
        fi
    ;;
    *)
        echo -n "jobs.value "
        wget "$JENKINS_URL/queue/api/json?pretty=true&tree=items[id]" -O - -q|grep '"id"'|wc -l
    ;;
esac

Más información

Tenéis más información en la página de Munin, en concreto cómo escribir plugins y todos sus enlaces.