Centralizando los datos de munin de varios servidores

herramientas Hemos hablado bastante por aquí en los últimos años acerca de munin. No en vano se trata de una de mis herramientas de monitorización favorita. Vamos a completarlas con alguna cosa más.

Cuando queremos monitorizar varios servidores diferentes, lo más cómodo es verlos todos en la misma página del navegador. Para ello hacemos lo siguiente:

En primer lugar, recordad que munin tiene dos módulos diferentes: munin y munin-node. En el artículo inicial de esta “saga” instalábamos tres paquetes: munin, munin-node y munin-plugins-extra. Ahora instalaremos los tres sólo en la máquina que centralizará los datos de la monitorización. Esta máquina se configurará igual que vimos ya en su día y debe de contar con un servidor web, intérprete de php y todo lo que ya hablamos en su momento. En las máquinas que solamente queremos monitorizar sólo instalaremos los dos paquetes finales (munin-node y munin-plugins-extra).

En todas las máquinas (salvo la que centralizará la comunicación) tendremos que editar el fichero /etc/munin/munin-node.conf. En este fichero nos aseguraremos de que aparecen dos líneas como estas:

host_name nombre2.midominio.net
allow 33.44.55.66

Donde 33.44.55.66 es la IP de la máquina que centralizará la monitorización de munin y nombre2.midominio.net será el nombre con el que queremos que aparezca esta máquina en nuestro panel de monitorización. Una vez hecho esto reiniciamos el daemon de munin-node: systemctl restart munin-node

En la máquina donde queremos ver las gráficas editamos el fichero /etc/munin/munin.conf y escribimos algo como esto:

[nombre1.midominio.net]
    address 127.0.0.1
    use_node_name yes

[nombre2.midominio.net]
    address 11.22.33.44
    use_node_name yes

[nombre3.midominio.net]
    address 55.66.77.88
    use_node_name yes

El primer bloque (nombre1.midominio.net) corresponde a la máquina en la que estamos editando el fichero y por eso usamos 127.0.0.1 como dirección. Cada uno de los otros corresponde con una de las máquinas cuya información queremos recoger y centralizar en esta.

Por defecto las máquinas aparecerán en el panel de monitorización en orden alfabético. Si queremos alterar dicho orden debemos de introducir una nueva directiva:

[midominio.net;]
        node_order nombre2.midominio.net nombre1.midominio.net nombre3.midominio.net

Ojo al punto y coma final de la directiva que es importante para que funcione. Luego reiniciamos el daemon munin (systemctl restart munin).

Ahora, cuando entremos en nuestra página de monitorización veremos en la sección overview una línea llamada midominio.net y luego otra por cada una de las máquinas monitorizadas:

Página de Overview de munin con varios servidores

Y si pulsamos en la línea correspondiente a midominio.net veremos los datos de todos los servidores ordenados en columnas:

Página de monitorización de munin con varios servidores

Y ya. La próxima entrada que hagamos sobre esto irá sobre la posibilidad de que munin realice notificaciones en caso de error o de exceder de ciertos límites. Si, si, yo tampoco lo sabía, pero se puede 😉

Plugins de nginx y php5-fpm para munin

herramientas Vamos a añadir una nueva entrada a las “sagas” sobre munin y nginx que tenemos abiertas desde hace poco. Concretamente vamos a ver como configurar y hacer funcionar los plugins que nos permitan monitorizar nginx y php-fpm desde munin. Como siempre lo haremos en un Debian (versión 7) y puede que en otra distribución algo sea ligeramente distinto.

Lo primero que debemos de hacer es habilitar la publicación de estadísticas tanto en nginx como en php-fpm. La forma de hacerlo en cada uno es distinta. Para nginx basta con que creemos una directiva como la siguiente en el fichero de definición de uno de los virtual hosts del mismo (típicamente en el virtual host por defecto):

location /nginx_status {
	stub_status on;
	access_log off;
	allow 127.0.0.1;
	deny all;
	}

Las dos últimas líneas sirven para evitar conexiones que no vengan de la propia máquina y podemos quitarlas (o modificar las restricciones) si queremos consultar estas estadísticas en tiempo real desde nuestro propio navegador. Habilitar las estadísticas para php-fpm es un poco más complicado. En primer lugar tenemos que habilitar la publicación de estadísticas en el fichero /etc/php5/fpm/pool.d/www.conf. Las estadísticas están deshabilitadas y para corregir esto basta con descomentar la siguiente línea y modificar el path por el que queramos usar:

pm.status_path = /fpm_status

Luego de nuevo en el fichero de configuración en el fichero de virtual host añadimos la siguiente directiva:

location /fpm_status {
	access_log off;
	include fastcgi_param;
	include snippets/fastcgi-php.conf;
	fastcgi_param SCRIPT_FILENAME $request_filename;
	fastcgi_pass unix:/var/run/php5-fpm.sock;
	allow 127.0.0.1;
	deny all;
	}

Aparte del mismo comentario hecho antes sobre las dos últimas líneas, obtserva que en la línea fastcgi_pass se indica que el acceso a fpm está configurado mediante sockets. Si tu accedes a través de puertos TCP tendrás que modificar esa línea por la correspondiente que, típicamente, suele ser esta:

fastcgi_pass 127.0.0.1:9000;

Una vez hecho esto comprobamos que no hemos cometido ningún error (service nginx configtest) pedimos a nginx que vuelva a leer la configuración (service nginx reload) y probamos que todo está correcto desde línea de comando mediante curl:

Probando la publicación de estado de nginx y fpm-php desde curl

NOTA: fpm tiene unas estadísticas mucho más completas detalladas proceso a proceso que podemos consultar con el siguiente comando:

curl http://localhost/fpm_status?full

El segundo paso sería editar el fichero /etc/munin/plugin-conf.d/munin-node para proporcionar a munin-node las variables de entorno oportunas. Hacemos esto añadiendo los siguientes dos bloques al final del mismo:

[nginx*]
env.url http://localhost/nginx_status

[phpfpm_*]
env.url http://localhost/fpm_status
env.ports 80
env.phpbin php-fpm
env.phppool www

En tercer lugar tenemos que decirle a munin-node que añada los plugins correspondientes. Los de nginx vienen “de serie” y basta con que creemos los enlaces a los mismos en el directorio /etc/munin/plugins como ya hemos hecho otras veces:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/nginx_connection_request
ln -s /usr/share/munin/plugins/nginx_memory
ln -s /usr/share/munin/plugins/nginx_request
ln -s /usr/share/munin/plugins/nginx_status

Los de php-fpm tenemos que bajárnoslos desde este enlace. Copiamos los cinco plugins en el directorio /usr/share/munin/plugins y luego creamos los enlaces al directorio /etc/munin/plugins:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/phpfpm_average
ln -s /usr/share/munin/plugins/phpfpm_connections
ln -s /usr/share/munin/plugins/phpfpm_memory
ln -s /usr/share/munin/plugins/phpfpm_processes
ln -s /usr/share/munin/plugins/phpfpm_status

Y ya casi hemos terminado. Sólo tenemos ahora que reiniciar el demonio de munin-node (service munin-node restart) y en unos minutos nos aparecerán las nuevas gráficas bajo las etiquetas de nginx y php:

Gráficos de monitorización de munin para nginx y php5-fpm

Analizando el arranque de tu Linux con bootchart

herramientas ¿Qué es lo que hace tu Linux durante el arranque?¿Hay alguna forma de ver exactamente que se ejecuta, cuales son los procesos dependientes que genera y cuanto tiempo se invierte en cada uno de ellos de forma que podamos, si es necesario, saber donde tenemos que tocar para conseguir un arranque más rápido?

Bootchart es una herramienta que obtiene y procesa fácilmente esta información y genera como resultado un gráfico fácilmente interpretable. Como muestra, aquí tenéis la gráfica resultado en un servidor VPS con Debian 7 (ya sabes, pulsa sobre la gráfica para verla con mejor resolución):

Gráfica de bootchart 0.9 en un servidor VPS con Debian 7

La instalación básica en una Debian estable requiere dos paquetes (y sus dependencias): bootchart y pybootchartgui. El primero es el que recopila los datos y el segundo el que genera el gráfico a partir de ellos. bootchard se instalará por defecto en el directorio /sbin y su archivo de configuración se llama bootchard.conf y se encuentra en el directorio /etc. pybootchartgui se encuentra en el directorio /usr/bin/. Aunque tenemos muchas opciones interesantes para explorar, vamos a limitarnos a ver el funcionamiento tal y como queda recién instalado y sin tocar nada.

Una vez instalados ambos, tenemos que hacer que el kernel de nuestro Linux ejecute el proceso que realiza la recogida de datos lo antes posible y esto lo hacemos introduciendo dicha llamada directamente en GRUB. Si estamos en un equipo desde el que tenemos acceso directo a teclado y monitor lo más fácil es introducir a mano la opción necesaria en el momento del arranque. Para ello, una vez que nos aparece el menú de GRUB pulsamos la letra “e” (de editar) e introducimos la opción init=/sbin/bootchartd. De esta forma el proceso sólo se llamará en este arranque puesto que la opción no queda salvada:

Editando la entrada de Grub para invocar a bootchar

Si no tenemos acceso al teclado de la máquina en el momento del arranque (en un Hosting VPS, por ejemplo) el método pasa por introducir esta opción en los archivos de configuración de GRUB. El método es diferente según que usemos GRUB o GRUB2. En GRUB basta con editar el archivo /boot/grub/menu.lst, buscar el bloque correspondiente al kernel con el que qeremos realizar el arranque e introducir la misma opción que hemos visto antes. Por ejemplo, así:

title           Debian GNU/Linux, kernel 3.2.0-4-amd64
root            (hd0,0)
kernel          /boot/vmlinuz-3.2.0-4-amd64 root=/dev/vda1 ro quiet no-kvmclock init=/sbin/bootchartd
initrd          /boot/initrd.img-3.2.0-4-amd64

En GRUB2 tenemos que editar el fichero /etc/default/grub, buscar la línea etiquetada como GRUB_CMDLINE_LINUX_DEFAULT e incluir al final de lo que allí aparezca la opción de carga de bootchartd. Así, por ejemplo:

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/35a07870-ac1a-489f-a19b-629
6dca46903 init=/sbin/bootchartd"

En este segundo caso, una vez editado el fichero tendremos que ejecutar el programa update-grub para que los cambios tomen efecto.

Un cuarto método, disponible si estamos usando un equipo de escritorio con un gestor de ventanas instalado, es usar uno de los muchos programas existentes para configurar grub de forma gráfica. Por ejemplo, grub-customizer:

Configurando el arranque de bootchartd con grub-customizer

Sea cual sea el método que hayamos usado, en el próximo arranque se ejecutará bootchartd, pero no olvides que, salvo en el primer caso, cuando ya no quieras usarlo tendrás que deshacer los cambios efectuados.

Bien. Tras reiniciar la máquina se invocará al proceso llamado bootchartd que recogerá la información necesaria y la guardará en un archivo llamado bootchart.tgz en el directorio /var/log. Para crear el gráfico basta con invocar a pybootchartgui:

Generando el gráfico de bootchart con pybootchartgui

Nota que se toma por defecto la ubicación y nombre del archivo original y que, por tratarse este de un nombre genérico, cada vez que reiniciemos y/o generemos un nuevo gráfico machararemos los datos del anterior a menos que los renombremos manualmente o le echemos un vistazo a la forma de modificarlos mediante los parámetros en línea y/o opciones de configuración adecuadas. Y listo. A continuación tenéis otro ejemplo correspondiente a un servidor más modesto que el anterior montado sobre VirtualBox:

Gráfica de bootchart 0.9 en una máquina de virtualbox con Debian 7

En la paquetería de Manjaro Linux (e, imagino, que ocurre igual con Arch) se usa otro programa similar también llamado bootchart pero que, en realidad, integra en un sólo servicio la recolección de datos y la generación del gráfico final. El gráfico resultante presenta, además, algunos aspectos diferenciadores. Podéis ver una muestra en la siguiente imagen que corresponde con el arranque de un PC de escritorio:

Gráfica de bootchart 1,2 en un PC de escritorio con Manjaro Linux

Para usarlo basta instalar el paquete llamado bootchart. El programa que tendremos que invocar se llamará igualmente bootchartd pero en este caso reside en el directorio /usr/bin. Podemos usar cualquiera de los métodos anteriormente vistos para invocarlo pero el parámetro a incluir en las opciones de carga del kernel será init=/usr/bin/bootchard. El archivo de configuración también es sensiblemente diferente y está en el directorio /etc/systemd. Cuando reiniciamos la máquina, el archivo que bootchart genera es ya directamente un gráfico en formato svg. El directorio destino del mismo es, igualmente, /var/log pero en este caso el nombre incluye una marca de tiempo (por ejemplo bootchart-20130916-0800.svg) de forma que si realizamos sucesivos reinicios tendremos disponible una colección de gráficos para su posterior estudio sin necesidad de ninguna intervención manual.

Existe aún, al menos, otro tercer sistema similar a estos denominado bootchart2 y que, por el momento, no he tenido ocasión de probar. Ahí queda el enlace por si alguien se anima…

NOTA: Desde hace ya unos meses estoy usando Manjaro Linux (con Openbox como window manager) como distribución de escritorio, tanto en mi ordenador de sobremesa como en mi portatil. Manjaro es una distribución rolling release, muy, muy ligera basada en Arch Linux que me está gustanado bastante, así que previsiblemente hablaremos bastante de ellas en lo sucesivo.

Plugins de memcached y bind9 para munin

herramientasEl otro día dejamos munin instalado y funcionando con los plugins más comunes que vienen de serie y se configuran de forma automática sin (casi) necesidad de manipulación extra alguna. El principal problema que vamos a encontrar con esta herramienta de monitorización es que cuando tratemos de instalar alguno de los centenares de plugins adicionales de que dispone nos encontraremos, según el caso, una información bastante irregular en cuanto a la forma en que tenemos que hacerlo: dependencias, configuración, etc. Hoy vamos a instalar un par de estos plugins adicionales de forma manual y así conoceremos un poco mejor sus tripas y veréis claramente a lo que me refiero.

La primera herramienta que debemos de conocer a la hora de añadir plugins adicionales es munin-node-configure, un script que nos ayuda a identificar que plugins nos pueden resultar útiles y ayudarnos a instalarlos. Como ya vimos, la instalación base de munin identifica muchos de los elementos que pueden resultarnos útiles y los configura e instala, pero si existe algún requisito o dependencia adicional para que funcionen no es capaz de resolverlo aunque si deja un mensaje informándonos de ello si usamos el parámetro --suggest. No suelen ser muy descriptivos y suele hacer falta hacer uso de Google para encontrar la solución (por ejemplo, si te falta la librería libcache-cache-perl para que funcione el plugin de MySQL el mensaje que aparece es “Missing dependency Cache::Cache”), pero bueno, algo es algo.

Para configurar el plugin de bind9 no necesitamos instalar nada adicional, pero si hacer algunos cambios en la configuración de nuestro servidor DNS. En el archivo named.conf.options (típicamente en el directorio /etc/bind) tenemos que introducir la siguiente línea dentro del bloque de options:

statistics-file "/var/cache/bind/named.stats";

Y añadir al final del fichero el siguiente bloque:

logging {
        channel b_query {
                file "/var/log/bind9/query.log" versions 2 size 1m;
                print-time yes;
                severity info;
        };
        category queries { b_query; };
};

A continuación creamos el directorio /var/log/bind9, le damos permisos de escritura al usuario bind, reiniciamos el demonio de nuestro servidor DNS y ejecutamos el comando rndc stats. Con esto el servicio dejará los logs detallados de estadísticas de consultas en ese directorio. A continuación tenemos que configurar el plugin de munin para que las lea y nos las muestre de forma gráfica. Para ello editamos el fichero /etc/munin/plugin-conf.d/munin-node y añadimos los siguientes bloques:

[bind9]
user root
env.logfile   /var/log/bind9/query.log

[bind9_rndc]
user root
env.querystats /var/cache/bind/named.stats

Por último, creamos un enlace a los plugins en el directorio de configuración como explicábamos el otro día:

ln -s /usr/share/munin/plugins/bind9 /etc/munin/plugins/bind9
ln -s /usr/share/munin/plugins/bind9_rndc /etc/munin/plugins/bind9_rndc 

Y ya sólo nos queda reiniciar el demonio munin-node. Casi inmediatamente tendremos una nueva categoría de gráficos dedicada a la monitorización de nuestro servicio de nombres:

Plugin de bind9 para munin

La configuración del plugin para memcached es bastante más sencilla. Lo primero que debemos de hacer es instalar el paquete libcache-memcached-perl (en una debian o derivada). A continuación añadimos el siguiente bloque en el archivo /etc/munin/plugin-conf.d/munin-node:

[memcached_*]  
env.host 127.0.0.1  
env.port 11211  
env.timescale 3

Creamos los enlaces:

ln -s /usr/share/munin/plugins/memcached_bytes /etc/munin/plugins/memcached_bytes
ln -s /usr/share/munin/plugins/memcached_counters /etc/munin/plugins/memcached_counters
ln -s /usr/share/munin/plugins/memcached_rates /etc/munin/plugins/memcached_rates

Reinciamos munin-node y ya:

Plugin de memcached para munin

NOTA: Tienes información bastante detallada acerca del fichero de configuración munin-node, las opciones que admite y su significado en este enlace.

Instalación y primeros pasos con Munin en Debian 7

herramientas Munin es un sistema de monitorización muy similar a cacti (que ya hemos tratado hace poco por aquí) pero que en lugar de usar snmp usa su propio programa recolector de información (llamado munin-node). La instalación básica sobre un único servidor (que es la que vamos a ver) es muy sencilla y proporciona más de 60 gráficas y cerca de 100 indicadores del estado y rendimiento de nuestro servidor sin que apenas tengamos que despeinarnos. Está escrito en perl, viene con una amplia colección de plugins (a la que se le añaden las múltiples contribuciones de los usuarios) y también admite monitorización de servidores windows.

La versión actual en los repositorios estables de Debian wheezy es 2.0.6-4 (de aproximadamente un año de antiguedad) que será la que instalaremos aquí. Si usas los repositorios de la versión inestable (sid) tienes disponible la versión 2.0.14. La máquina donde queremos instalarlo es un servidor LAMP típico con Apache2 y MySQL. Los paquetes necesarios son estos. Y sus dependencias, claro:

apt-get install munin munin-node munin-plugins-extra
NOTA: La versión de munin en una debian estable es la 2.06 mientras que en backports tienes disponible la 2.0.19. Si quieres instalar esta última basta con que sigas las instrucciones que se te indican aquí.

La instalación por defecto en Debian configura Munin para que sólo pueda accederse a la instancia web de monitorización desde la misma máquina en la que hemos realizada la instalación. Para solucionar esto y poder acceder en remoto a través de un navegador tenemos que editar el fichero /etc/apache2/conf.d/munin en el que se encuentra la configuración de la instancia web. Buscamos la directiva <Directory /var/cache/munin/www> y en su interior comentamos las líneas siguientes:

# Order allow,deny
# Allow from localhost 127.0.0.0/8 ::1

Y añadimos esta otra:

Order deny,allow

Luego repetimos la misma operación en las directivas <Location /munin-cgi/munin-cgi-graph> y <Location /munin-cgi/munin-cgi-html>. Con esto el acceso será libre para cualquiera que conozca la URL de acceso. Si queremos proteger la entrada mediante usuario y contraseña podemos, por ejemplo, usar htdigest como contábamos por aquí en su día.

Y listo. Ahora recargamos la configuración de apache:

service apache2 reload

Y ya podemos acceder a través de la URL http://ip-del-servidor/munin/. La pantalla inicial, una vez introducida la identificación, es así de sosa minimalista:

Primera ejecución de munin. Pantalla inicial.

ACTUALIZACIÓN: Si realizas la instalación en Debian 8 (esta entrada se escribió aún con la versión 7) o actualizas a ella existen ciertas diferencias introducidas por la nueva versión de Apache, la 2.4. En el directorio de configuración de munin (/etc/munin/) te encontras un fichero llamado apache24.conf. Asegurate que es a este al que apunta el enlace que se encuentra en el directorio /etc/apache2/conf.d con el nombre de munin. Luego edítalo y modifica las dos veces en las que aparece la línea Require local sustituyéndola por Require all granted. Recarga la configuración de apache y listo.

Vamos a pararnos un poco a ver donde ubica sus diferentes elementos. Como ya hemos comentado, munin usa una estructura cliente servidor con nodos recolectores en cada uno de los equipos que queremos monitorizar y un elemento que centraliza la información de todos ellos. El daemon del primer elemento se llama munin-node y el del segundo munin. Ambos son servicios que residen, como es habitual, en el directorio /etc/init.d y responden a los argumentos habituales (start y stop). munin-node responde, además, a restart (necesario cuando añadimos un nuevo plugin o modificamos la configuración de uno ya existente) y alguno mas.

Los archivos de configuración se encuentran en /etc/munin/. Existen, entre otros, un archivo por cada uno de los servicios (munin.conf y munin-node.conf) y un directorio donde se encuentran los plugins en uso de este nodo. El procedimiento para activar los plugins es crear un enlace en este directorio al archivo que contiene el código del plugin. Los que vienen por defecto con la instalación se encuentran en /usr/share/munin/plugins/.

Por último, los datos de la instancia web de monitorización se encuentran en /var/cache/munin/www/, la base de datos en bruto en /var/lib/munin/ (no, no usa mysql como hace cacti), y los logs en /var/log/munin.

Volvemos al pantallazo anterior. En la parte central tenemos acceso a las diferentes máquinas monitorizadas ordenadas por grupos (en nuestro caso sólo una) Mientras que en la barra de la izquierda, abajo, tenemos un menú organizado por categorías con acceso directo a las gráficas diarias, semanales, mensuales o anuales de cada una de ellas. De cualquiera de las formas accedemos a una colección de gráficas pero con una pequeña diferencia. Si accedemos a través del menú superior llegamos a una página donde se encuentran todas las gráficas almacenadas en dos versiones, diaria y semanal (semanas, en realidad, de ocho días 🙂 , muy bien pensado para detectar mejor las secuencias):

Munin - Gráficas del sistema diarias y semanal

Mientras que si pulsamos en el lateral sólo se nos muestra la lista de las gráficas de la categoría elegida y exclusivamente en la modalidad de vista elegida según la letra que pulsemos: diaria (d), semanal (w), mensual (m, 33 días aproximadamente) o anual (y, 13 meses):

Munin - Gráficas de postfix diarias

Pulsando sobre cualquier gráfica accedemos a la vista en mosaico de las cuatro vistas disponibles antes mencionadas y si de nuevo pulsamos sobre cualquiera de ellas llegamos a una vista ampliada de la misma con un panel de control desde el que podemos, analítica o gráficamente, hacer la ampliación o reducción de cualquier zona de la misma:

Munin - Gráfica de Load Average

NOTA: Lógicamente, los gráficos de una instalación recién concluida no presentan este aspecto. Tendrás que esperar al menos 24 horas para ello 😉

Lo normal tras la instalación inicial es que, como nos ha pasado, no te instale los plugins correspondientes a apache y mysql debido a que falta algún prerequisito para ello. munin viene con un asistente llamado munin-node-configure que identifica cuales de los plugins que tienes en tu sistema están activos, cuales te podrían ser útiles… Incluso te asiste dándote el comando que necesitas para crear los enlaces necesarios al archivo y directorio adecuados. Échale un vistazo al enlace anterior de este párrafo para más detalles.

Para MySQL, en concreto, basta con que instaléis el siguiente paquete:

apt-get install libcache-cache-perl

Para apache2 necesitamos también instalar una librería extra de perl:

apt-get install libwww-perl

Además, debemos añadir la siguiente línea (o asegurarnos de que ya está) en el fichero /etc/apache2/mods-available/status.conf:

ExtendedStatus On

Y habilitar los módulos status e info de Apache:

a2enmod status info

Por último, reiniciamos el servidor web:

apache2ctl graceful

Creamos los enlaces a los plugins (fíjate en la forma diferente de hacerlo para mysql que se trata de un wildcard plugin) y reiniciamos el recolector de munin de esta máquina:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/apache_accesses
ln -s /usr/share/munin/plugins/apache_processes
ln -s /usr/share/munin/plugins/apache_volume
ln -s /usr/share/munin/plugins/mysql_ mysql_bin_relay_log
ln -s /usr/share/munin/plugins/mysql_ mysql_commands
ln -s /usr/share/munin/plugins/mysql_ mysql_connections
ln -s /usr/share/munin/plugins/mysql_ mysql_files_tables
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_bpool
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_bpool_act
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_insert_buf
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_io
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_io_pend
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_log
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_rows
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_semaphores
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_tnx
ln -s /usr/share/munin/plugins/mysql_ mysql_myisam_indexes
ln -s /usr/share/munin/plugins/mysql_ mysql_network_traffic
ln -s /usr/share/munin/plugins/mysql_ mysql_qcache
service munin-node restart

Y con esto (tal vez tengas que esperar unos minutos para ver los resultados) ya tenemos dos categorías nuevas (apache y mysql2) con las gráficas correspondientes. Un par de ejemplos de cada una de ellas:

Munin - Gráfica de threads de Apache

Munin - Gráfica de operaciones de MySQL

Existen muchos otros plugins de monitorización que os pueden ser útiles (asterisk, bind9, memcached, varnish…). En algunos casos puede ser necesario instalar algún otro requisito o realizar algún cambio en la configuración como nos ha ocurrido con Apache y MySQL. Como siempre, lo mejor en el caso de que simplemente creando el enlace al plugin este no funcione es buscar información (que es lo que yo he hecho con estos dos, no creáis que hay muchas otras formas de resolver estas cosas 😉 ). También es sencillo eliminar cualquier gráfico que no nos interese en absoluto simplemente borrando el enlace del plugin correspondiente y reiniciando munin-node. Si tenemos duda acerca del plugin que genera la gráfica, el nombre del archivo aparece en la pantalla de los datos que nos permite realizar zooms de los datos. Añadir otros nodos para centralizar la monitorización de los mismos en esta máquina es bien fácil, pero ya lo dejamos para otro día 😉

En definitiva, se trata de una herramienta mucho más potente que cacti que nos proporciona toda la información que podemos desear de una máquina y más sin apenas consumir recursos. Hecho en falta, tal vez, la facilidad de cacti para crear vistas personalizadas con ciertos gráficos que te interesa consultar de forma habitual. Y, por supuesto, no es tan cómoda como Cacti para monitorizar electrónica de red usando snmp. Pero bueno, no se puede tener todo ¿no?

Instalación y primeros pasos con ntop 5 en Debian 6

ntop es la herramienta más popular y completa para monitorizar el tráfico de una red cuando nos interesa, no sólo conocer la magnitud del mismo sino su procedencia y características. Colocado en un punto estratégico de nuestra red nos sirve para detectar cualquier tipo de anomalía en la misma. Si lo instalamos en un servidor nos sirve para auditar el tipo de tráfico que este emite y recibe de forma gráfica y muy didáctica.

Como ocurre en algunas ocasiones la versión en la paquetería de debian (4.0.33 en la estable y 4.99.3 en testing y unstable) va bastante por detrás de la del producto (5.0.1) así que si te apetece jugar con lo último lo mejor es bajarte los fuentes y compilarlos en tu máquina. Pero ya sabes que, en este caso, tendrás que preocuparte de posibles actualizaciones de forma manual. ntop, en particular, no parece tener ningún aviso automático de la aparición de nuevas versiones. Vamos a ello.

Antes que nada, instalamos los paquetes necesarios para realizar la instalación, las dependencias y alguna otra cosa necesaria:

apt-get install build-essential libtool automake autoconf libpcap-dev libgdbm-dev rrdtool librrd-dev libssl-dev python-dev libgeoip-dev graphviz subversion python-pip

A continuación nos descargamos de aquí la última versión estable de ntop, la copiamos en, por ejemplo, el directorio /tmp de nuestra máquina y la descomprimimimos:

wget -c http://sourceforge.net/projects/ntop/files/ntop/Stable/ntop-5.0.1.tar.gz
tar xvfz ntop-5.0.1.tar.gz

Ahora entramos al directorio donde se han descomprimido los fuentes (ntop-5.0.1 en este caso) y generamos los binarios.

cd ntop-5.0.1/
./autogen.sh
make
make install
ldconfig

Y listo. Sólo nos quedan unos cuantos retoques. Los datos que ntop capture una vez esté en funcionamiento se guardarán en /usr/local/var/ntop. El daemon de ntop se ejecuta con el usuario nobody, así que debemos de hacerlo propietario de dicho directorio para que pueda escribir libremente en él:

chown -R nobody /usr/local/var/ntop

El binario de ntop ya está listo para ejecutarse y se encuentra en el directorio /usr/local/bin. Si escribes ntop -help tendrás una detallada lista de posibles opciones. Las mías son estas:

/usr/local/bin/ntop -i eth0 -w 3001 -L -d

De esta forma ntop monitorizará todo el tráfico enviado y recibido por el interfaz de red eth0 de nuestra máquina, el interface web de ntop escuchará peticiones en el puerto 3001 (por defecto lo haría en el 3000), guardará los mensajes de log en el syslog de la máquina (/var/log/syslog) y se ejecutará como daemon o servicio en segundo plano.

En la primera ejecución nos pedirá que introduzcamos la contraseña para el usuario admin necesaria para entrar a ciertas páginas restringidas del programa. Muy pocas, la verdad, pero luego veremos como solucionar esto.

ACTUALIZACI?N: Las últimas compilaciones llevan por defecto la contraseña admin para el usuario admin

Para acceder a ntop ya sólo tenemos que ir a nuestro navegador y escribir lo siguiente sustituyendo ip-de-la-maquina por la dirección o nombre correcto donde hemos hecho la instalación y cambiando el puerto por el adecuado si lo hemos modificado en la orden de inicio anterior:

http://ip-de-la-maquina:3001

Pantalla principal de ntop (Traffic Summary)

Para proteger el acceso a cualquier página de ntop (imprescindible sobre todo si es visible desde Internet) debemos de entrar en el menú superior (Admin -> Configure -> Protect URLs) y añadir una regla con un asterisco ‘*’ al limitado grupo de usuarios que deseemos (o al usuario admin si es una instalación de uso particular).
Protegiendo el acceso a ntop

Ahora ya sólo nos quedan unos pequeños ajustes para disponer de algunos gráficos y diagramas adicionales que, por defecto, no vienen configurados. El plugin Round-Robin Database debería de estar activado para disponer de los gráficos de Network Load generales o por protocolo.
Gráficos de carga por protocolo en ntop con rrd activado

Para ello, además de activar el plugin (Plugins -> Round-Robin Database -> Activate), deberíamos de comprobar que en la pantalla de Preferencias (Admin -> Configure -> Preferences) la cadena rrd.rrdPath apunta a un directorio donde el usuario nobody tenga permisos de escritura (típicamente /usr/local/var/ntop/rrd), que en la configuración del plugin (Plugins -> Round-Robin Database -> Configure) las dos cadenas del bloque RRD Files Path apuntan al mismo directorio y que en el bloque Data to Dump de esta misma pantalla tenemos seleccionada, al menos, la opción de Interfaces. Si seleccionamos todas las opciones tendremos muchos más datos de captura pero a costa de cargar más la ejecución y el espacio ocupado por las capturas. Mucho cuidado con el espacio en disco, que podemos necesitar fácilmente 2 Gigas por día en un servidor con un tráfico corrientito.
Configurando rrd en ntop

Para ver los mapas por regiones tenemos que instalar las plantillas Mako para python. Como al principio de todo hemos instalado el paquete python-pip nos basta con salir a línea de comandos y ejecutar lo siguiente:

pip install Mako

Graficos geográficos con Mako y ntop

Por último, aunque hemos instalado graphviz y Dot es uno de sus elementos integrantes, nos hace falta añadir un path en las Preferencias (Admin -> Configure -> Preferences) para disponer de los Mapas de Tráfico de Red Locales. Entramos en ellas y, al final de la tabla, añadimos la cadena dot.path con el valor /usr/bin/dot. Pulsamos Add, confirmamos y listo.
Gráficos de tráfico de red local en ntop

ntop tiene muchas otras gráficas y páginas de información útil e interesante además de estas que he mostrado y cuyo único motivo para aparecer aquí es que necesitan de algún retoque extra en la configuración para poder usarlas, así que lo mejor es que las explores una a una. La documentación para interpretarlas es escasa, todo hay que decirlo, pero últimamente se están poniendo las pilas en este sentido y han prometido, por fin, un manual de usuario en breve.

Y ya sólo nos queda un pequeño detalle para concluir. Si quieres que ntop se ejecute de forma automática como servicio cada vez que hagas un reinicio de la máquina donde la tienes instalada sólo tienes que crear un fichero .sh (por ejemplo ntop.sh) con la línea de ejecución que has usado antes para ponerlo en marcha, crear un enlace al mismo en el directorio init.d y ejecutar lo siguiente:

ln -s /opt/Scripts/ntop.sh /etc/init.d/ntop
update-rc.d ntop defaults 99

Instalación y configuración básica de Cacti en Debian para monitorizar un host

herramientas La instalación más sencilla (y, me atrevería a decir, más frecuente que he tenido que realizar) que suele hacerse con Cacti es aquella que se se usa para monitorizar los recursos de un único host (típicamente un servidor dedicado o VPS en una empresa de hosting) en el que el propio Cacti se encuentra instalado de forma local.

Cacti necesita para funcionar un servidor web (apache2, por ejemplo) con php, una base de datos de mysql-server, las rrdtools y snmp (cliente y agente). Seguramente tendremos ya instalados apache2 y mysql-server y, si no, añade los paquetes apache2, php5 y mysql-server al comando siguiente:

sudo apt-get install cacti snmp snmpd rrdtool

Durante la instalación se nos pedirá si queremos configurar de forma automática la base de datos que necesita cacti (en caso afirmativo, se nos pedirá la contraseña de root de mysql-server para crear dicha base de datos y un usuario de acceso a la misma) y el servidor web que usaremos (apache2 en nuestro caso).

Una vez concluida la instalación podremos acceder a Cacti con la URL http://ip_o_nombre_del_servidor/cacti. En el primer acceso se ejecutará un asistente en el que se nos pedirá aceptar la licencia de uso, decidiremos el tipo de instalación (nueva o actualización de una versión anterior) y se realizará un chequeo de dependencias:
chequeo inicial de dependencias durante la instalación de Cacti

Una vez cumplimentado esto se nos redirecciona a la ventana de login. El usuario inicial es admin y su password la misma. Inmediatamente después de realizar el primer login se nos forzará a cambiar esta password, así que tenla pensada de antemano 😉
Login inicial en Cacti. Usuario admin y password admin

Cacti está ya funcionando y recogiendo datos de forma automática del servidor en el que se encuentra instalado. Si lo dejamos unos minutos para que le de tiempo a recoger algunos y pulsamos sobre la solapa de gráficos (arriba a la izquierda) veremos que ya tenemos gráficas (no tan completas como estas que llevan ya más de 24 horas, claro) de carga de la CPU, ocupación de memoria, número de procesos y número de usuarios conectados.
Solapa de entrada a los gráficos de Cacti
Gráficos iniciados de forma automática para localhost en cacti

Para monitorizar el tráfico de red es preciso “tirar” de snmp. Lo primero que tenemos que hacer es configurar el daemon de snmp para que Cacti pueda leer de él. Para ello editamos el fichero /etc/snmp/snmpd.conf y quitamos el comentario que deshabilita la siguiente línea:

rocommunity public localhost

Reiniciamos el servicio (sudo service snmpd restart) y volvemos a Cacti para configurar la nueva gráfica. Para ello entramos en la opción Devices del menú de la izquierda, pulsamos sobre la entrada de localhost (la única que tendremos) y, en la ficha resultante, editamos el campo destacado en la imagen de aquí abajo (el correspondiente a la versión de SNMP que aparecerá como Not in Use) y luego pulsamos el botón de Save. Si todo ha salido bien y Cacti es capaz de contactar con el demonio SNMP de nuestro equipo, arriba a la izquierda aparecerán las líneas de información que también puedes ver resaltadas en este gráfico:
Añadiendo SNMP al dispositivo localhost en Cacti

En la parte inferior de esta misma ficha de datos, en el bloque de “Associated Data Queries” debería de aparecer ahora una línea etiquetada como “SNMP – Interface Statistics” (a la derecha de “Add Data Query”). La seleccionamos, pulsamos el botón de Add y, a continuación, el de Save.
Añadiendo gráficos de SNMP en Cacti

Bien, ahora volvemos a la parte superior de la página y pulsamos en el enlace de “Create Graphs for this Host”. En la página que nos aparece marcamos los interfaces de red cuyo tráfico queremos monitorizar y, ya que estamos, las unidades de disco cuya ocupación queremos controlar (eth0 y sda1, respectivamente, en el ejemplo aquí abajo). Bajo las líneas correspondientes a los interfaces de red tenemos, como puedes ver, un selector que nos permite elegir entre diferentes tipos de gráficos. A mi particularmente la que aparece por defecto (In/Out bits) es la que me parece más cómoda pero, ya sabéis, para gustos… 😉
Añadiendo gráficos de SNMP en Cacti

Pulsamos Create y listo. Los datos se empezarán a tomar inmediatamente y, a los pocos minutos, si volvemos a entrar en la solapa de Gráficos tendremos ya las primeras muestras disponibles. Después de 24 horas tus nuevas gráficas de tráfico de red y de ocupación de disco lucirán como estas:
Gráfica de tráfico de red en Cacti
Gráfica de ocupación de disco en Cacti

El siguiente gráfico que añadiremos será el de activida de lectura y escritura en discos, muy interesante sobre todo para monitorizar la actividad de nuestro disco de swap y detectar si la máquina está corta de memoria. También es el que más “trabajo” nos va a dar para ponerlo en marcha, así que atención.

Lo primero que necesitas es descargarte y descomprimir este fichero (extraído de este hilo del foro de Cacti que es de donde he sacado las instrucciones que te voy a contar) donde encontraras dos archivos con extensión XML. El que se llama net-snmp_devio.xml tienes que copiarlo al directorio /usr/share/cacti/site/resource/snmp_queries/ de la máquina. El otro, llamado cacti_data_query_ucdnet_device_io.xml, tienes que importarlo desde la opción “Import Template” que aparece en el menú de la izquierda.
Importando plantilla para IO de disco en Cacti

Si el resultado es correcto veremos algo como esto:
Importando plantilla para IO de disco en Cacti

Ahora volvemos a la opción de Devices, volvemos a seleccionar localhost y en la parte inferior, en el mismo bloque de ??Associated Data Queries?. ahora nos aparecerá una nueva línea etiquetada como “ucd/net – Device I/O” que debemos de seleccionar y, luego, pulsar el botón de Add y salvar los cambios.
Añadiendo una gráfica de tráfico de disco en Cacti

Volvemos a pulsar ahora en el enlace de “Create Graphs for this Host” y en el nuevo bloque que nos aparece seleccionamos las líneas correspondientes a los discos cuya actividad queremos seguir. En el ejemplo de aquí abajo se han seleccionado sda1 (la partición donde reside el sistema) y sdb (el disco de swap).
Añadiendo una gráfica de tráfico de disco en Cacti

Cambiamos al pie del bloque el tipo de gráfico si así lo deseamos y pulsamos el botón de Create. Listo:
Gráfica de tráfico de disco en Cacti

Y para terminar, un pantallazo con todos los gráficos de monitorización que tenemos ahora en nuestro servidor tras configurar sus dimensiones para que puedan verse cómodamente con un sólo vistazo (pulsa sobre él para verlo ampliado):
Mosaico de gráficas de monitorización de un host con Cacti

phpSysInfo

herramientas phpSysInfo es un script escrito en PHP que muestra información acerca del sistema en el que corre. Es bastante ligero y extensible mediante la programación de plugins. Tienes una demo real bastante completa aquí, mucha información en las páginas del proyecto en sourceforge y hasta un cliente para tu android.

phpsysinfo

Las instalación es tan sencilla como descomprimir y copiar los ficheros del proyecto en un virtual host de tu apache, renombrar el ejemplo del archivo de configuración (de phpsysinfo.ini.new a phpsysinfo.ini) y editarlo siguiendo las indicaciones de los comentarios que lo acompañan.

Instalando Pandora FMS en Debian

opinion Pandora FMS (Flexible Monitoring System) es una herramienta de monitorización de software libre (desarrollada por Ártica, una empresa española) que hace ya tiempo que tenía ganas de probar, así que aprovechando las vacaciones y el reciente lanzamiento de su versión 3.1 me he puesto manos a la obra. Al estilo de lo que dejamos por aquí hace ya unos años cuando hablamos de Nagios, tocaremos en esta primera entrada la instalación y primeros pasos y en posteriores posts veremos algunas de las principales tareas de configuración y gestión. Agarraos.

Vaya por delante que yo nunca he pensado que instalar y/o configurar Nagios sea algo complicado. Pero es que instalar Pandora FMS y crear un primer mapa de los elementos de tu red (que es lo que veremos hoy aquí) es tan fácil como comerse un bizcocho. No existen extrañas dependencias, no hay nada que compilar, ni arcanos ficheros que editar. La instalación de Pandora FMS es más fácil aún que la de wordpress, drupal o la de cualquier otro CMS vulgarote. Una verdadera gozada. Ya no hay excusa válida para no monitorzar el estado de tu red y de sus elementos de forma centralizada.

Pandora FMS está formado por tres componentes: servidor, consola y agente. A grandes rasgos, los servidores son las máquinas desde las que se lanzan los diferentes tests, la consola la que contiene la instancia de Apache a la que nos conectamos para administrar, configurar y monitorizar el conjunto y los agentes serían las máquinas a monitorizar. Una instalación típica de Pandora FMS tendrá una consola, uno o más servidores y tantos agentes (en máquinas windows o GNU/Linux) como deseemos. Para este ejemplo partiremos de una instalación limpia de Debian Lenny 5.0.5 eligiendo sólo los paquetes standard mínimos. Sobre esta máquina instalaremos el servidor, la consola y un primer agente.

Lo primero que debemos hacer es instalar las dependencias previas. Se trata, en su práctica totalidad, de paquetes estándar y disponibles en los repositorios stable de Debian. En la wiki del proyecto (con muy buena documentación, por cierto) hay un apartado dedicado a esto pero a mi me han faltado algunos. La lista que yo he necesitado es la siguiente:

# apt-get install snmp snmpd sudo xprobe2 nmap traceroute mysql-server mysql-client dbconfig-common apache2 php5 libapache2-mod-php5 php5-gd php5-mysql php-pear php5-snmp php-db php-gettext php-db php5-xmlrpc php5-ldap libtime-format-perl libxml-simple-perl libnetaddr-ip-perl libdbi-perl libhtml-parser-perl libmail-sendmail-perl libio-socket-multicast-perl libhtml-tree-perl graphviz

En segundo lugar, nos descargamos e instalamos las herramientas y dependencias que Debian no ofrece como paquetes estándar de las páginas del proyecto en Sourceforge.

Tercero: nos bajamos, también de Sourceforge, los paquetes de los tres componentes de Pandora FMS (consola, servidor y agente) y los instalamos igualmente. El paquete del agente que está disponible ahora mismo da un error de instalación que se soluciona siguiendo las indicaciones de este foro.

Se acabó la línea de comandos. Puesto que en la máquina en la que estamos haciendo la instalación no hemos instalado siquiera las X, nos vamos a nuestra máquina de escritorio, abrimos un navegador y cargamos la siguiente URL para iniciar la configuración:

http://<ip o nombre de la maquina>/pandora_console/install.php

La configuración se hace a través de seis sencillos pasos que podeis ver en las diapos de aquí abajo. Aceptamos la licencia, verificamos que todas las dependencias se han instalado correctamente, aceptamos los datos relativos a la base de datos y la instancia web y cumplimentamos los datos de un usuario con privilegios para crear la nueva base de datos y, muy importante, anotamos la contraseña aleatoria que nos muestra en la pantalla número 5.


Antes de entrar por primera vez en la consóla debemos de proporcionar al servidor la contraseña que se nos ha facilitado durante la instalación. Para ello editamos el fichero /etc/pandora/pandora_server.conf y localizamos en él el parámetro dbpass:

dbpass ghqshtvw

Finalmente relanzamos el proceso del servidor (que debe de haber abortado tras la instalación debido a la ausencia de esta contraseña):

# /etc/init.d/pandora_server start /etc/pandora/pandora_server.conf

pandora fms login Y esto es todo. Si ha habido algún problema debería de haber quedado reflejado en los archivos de log que se encuentran en el directorio /var/log/pandora. Si todo ha salido bien podemos ir a nuestra máquina de escritorio y entrar en la consola a través de la siguiente URL. El usuario creado inicialmente de forma automática es admin y la contraseña pandora:

http://<ip o nombre de la maquina>/pandora_console/

La pantalla inicial que se nos presenta tiene el aspecto de la imagen de aquí abajo (pulsa sobre ella para ampliarla). En la wiki de documentación del proyecto tienes una buena descripción de cada uno de sus apartados:
Pantalla inicial de Pandora FMS

Y vamos a terminar por hoy diciendole a Pandora que lance una tarea de reconocimiento para que veamos cuan fácil es crear un mapa de nuestra red. Para ello, y dentro del menú lateral de administración, desplegamos la opción de “Gestionar servidores” y pulsamos sobre “Gestionar tarea recon”. Pulsamos el botón de Crear y cumplimentamos la ficha con los datos de nuestra red:
Creando una tarea de reconocimiento en Pandora FMS

Ya experimentaremos más adelante con los campos de plantillas, puertos, etc. Por el momento sólo pondremos un nombre a la tarea, cumplimentaremos correctamente el “scope” de nuestra red y pulsaremos el botón de Añadir. La tarea se creará y se lanzará de forma automática. Si queremos ver el avance de la exploración vamos al menú lateral de operaciones, desplegamos la opción de “Servidores” y pulsamos sobre el nombre de nuestro servidor para que nos muestre las tarea que está ejecutando en este momento y el progreso de las mismas:
Creando una tarea de reconocimiento en Pandora FMS

Al terminar la exploración desplegamos la opción de “Ver agentes” (también en el menú de operación) y elegimos “Mapa de red”. Et voilà:
Mapa de red en Pandora FMS

Pulsando sobre cualquiera de los dispositivos mostrados en el mapa obtendremos una ventana de detalle como la siguiente:
Vista de detalle de un host en Pandora FMS

Y por el momento basta. Otro día seguimos con ella.