Archivo de la etiqueta: cacti

SAI Salicru bajo Linux con nut y monitorización en Cacti

Recientemente he tenido que cambiar el SAI que tenía en casa desde hace unos años, un Powermust 1000 que me había dado muy buen resultado, sin embargo las baterías habían llegado a su fin. En App encontré uno con muy buena pinta, con puerto USB para monitorización, indicaban que soportaba Linux y, además, fabricado en España :|, el Salicru SPS 900 One, a un precio insuperable. Me lo llevo :P.

La decepción llegó al instalarlo. La monitorización se hace a través de una aplicación propia, algo que no me convencía ya que estaba acostumbrado a utilizar nut y a tenerlo integrado en Cacti.

Leyendo y probando algunos drivers encontré cómo hacerlo funcionar :). Muy sencillo.

./configure --with-usb --with-snmp --with-cgi --prefix=/usr --with-cgipath=/path/to/cgi-bin/nut/
make
make install

Esto instalará todo lo necesario y dejará los scripts para acceder vía web al estado del SAI en la ruta indicada.

No voy a entrar en detalles de la configuración, sólo indicar que el driver a utilizar es blazer_usb:

cat /etc/ups/ups.conf
[salicru]
driver = blazer_usb
port    = auto
desc    = "Sai Salicru 900"

Con eso iniciamos los demonios upsd y si todo va bien  lo tendremos funcionando. Si vamos a la ruta donde dejamos los scripts web veremos:

Primer paso preparado. Vamos ahora a configurar el monitor de avisos para que sepamos cuando el SAI cambia de estado (se va la luz en casa, vuelve, se queda sin batería, etc.). Esto lo controla el demonio upsmon. Como veis se monitoriza todo bien excepto el nivel de batería, este SAI no informa de ese dato, pero tampoco es algo crítico, los cambios de estado sí que funcionan correctamente, con eso es suficiente para nuestro propósito.

Primero preparamos la configuración.

# cat upsmon.conf
MONITOR salicru@localhost 1 monmaster momi master
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"

NOTIFYCMD /bin/avisoups

POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower

NOTIFYMSG ONBATT "El SAI esta funcionando con bateria."
NOTIFYMSG LOWBATT "La bateria del SAI esta muy baja"
NOTIFYMSG SHUTDOWN "El servidor sera apagado inmediatamente"
NOTIFYMSG ONLINE "EL SAI esta funcionando con alimentacion externa"

NOTIFYFLAG ONBATT WALL+EXEC
NOTIFYFLAG LOWBATT WALL+EXEC
NOTIFYFLAG SHUTDOWN WALL+EXEC
NOTIFYFLAG ONLINE WALL+EXEC

RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

Además de definir los mensajes que queremos recibir, le indicamos también que en los cambios de estado llame al script /bin/avisoups.

# cat /bin/avisoups
#!/bin/bash
/bin/echo "$*" | /usr/local/bin/gammu --sendsms TEXT 666666666
echo "$*" | mail -s "Aviso del SAI" [email protected]

Este script se ejecutará en cada cambio de estado que se produzca en el SAI y recibirá como parámetro el texto correspondiente al nuevo estado. En mi caso me envío un email y un SMS a través de Gammu.

Levantamos el demonio upsmon y probamos a enchufar y desenchufar la alimentación externa del SAI. Si todo va bien recibirás un email y/o un sms con el aviso :).

Cuando al SAI se le termine la batería apagará el servidor para evitar que se corte la alimentación de golpe. Si configuras la Bios para que arranque automáticamente cuando reciba alimentación, se reiniciará él solito en cuanto vuelva la luz :).

Integración con Cacti

Para integrar la monitorización en Cacti podemos utilizar estas plantillas ya creadas.

Una vez instalada y creada en el host que hace de monitor debemos configurar el “Data source” correspondiente indicando el SAI que debe monitorizar, en mi caso salicru@localhost.

Si todo ha ido bien, comenzaremos a ver la gráfica de nuestro SAI. Tendremos sólo las líneas Input, Output y Load, la de Batteries, como he indicado, no se recibe en este SAI.

Ya tenemos nuestro SAI baratito bien instalado y configurado. A partir de ahora nos avisará cuando haya cortes de luz, apagará el equipo, se encenderá de nuevo automáticamente y, si lo configuramos todo bien, tendremos hasta un SMS en nuestro móvil. Y todo ello monitorizado a través de Cacti :).

Monitorizando Qmail con Cacti

Hace ya mucho tiempo que no hablamos de Cacti, mi sistema de monitorización preferido. Hoy veremos como controlar con él la actividad de nuestro Qmail.

Habitualmente la instalación de Qmail se realiza utilizando las daemonTools, pero nunca me han gustado mucho así que lanzo el servicio qmail-send con un script propio, mientras que los servidores smtpd y pop3d los integro con xinetd. Ya sé que a muchos no les gustará esto último, pero para mi es muy cómodo :P. El caso es que con este sistema, estos últimos demonios escapan del control de multilog, el sistema de logging de las daemontools, mala suerte. Veremos en este artículo cómo monitorizar el servicio de envío y recepción de Qmail pero no veremos nada relativo a smtp o pop3 debido a que no tengo esos logs. Si los tuvieses sería muy sencillo añadir estas gráficas de actividad, incluso las de spamassasin o clamav.

Supondremos que nuestro multilog deja sus archivos en /var/log/qmail, sustituye esto por tu ruta real, esa es la mía :P.

Lo primero que tendremos que hacer será instalar el paquete qmailmrtg7. Este software permite crear gráficas mrtg a partir de los logs de multilog. Será la herramienta que utilicemos para obtener los datos. NO es necesario que configuremos todo el qmailmrtg7, sólo necesitamos el ejecutable. Podemos comprobar que funciona bien haciendo:

[osus@servidor ~]#/usr/local/bin/qmailmrtg7 q /var/qmail/queue
636
0

Como se puede ver, nos devuelve dos líneas, en la primera los mensajes en cola y en la segunda los mensajes sin procesar. Esto marcha bien.

Configuremos ahora el servidor snmp para que podamos obtener estos valores a través de Cacti, para ellos simplemente añadimos al archivo de configuración las siguientes líneas:

/etc/snmpd/snmpd.conf

extend .1.3.6.1.4.1.18689.1.3 qmail-message-status /usr/local/bin/qmailmrtg7 s /var/log/qmail
extend .1.3.6.1.4.1.18689.1.3 qmail-bytes-transfer /usr/local/bin/qmailmrtg7 b /var/log/qmail
extend .1.3.6.1.4.1.18689.1.3 qmail-smtp-concurrency /usr/local/bin/qmailmrtg7 t /var/qmail/supervise/qmail-smtpd/log/main
extend .1.3.6.1.4.1.18689.1.3 qmail-smtp-sessions /usr/local/bin/qmailmrtg7 a /var/qmail/supervise/qmail-smtpd/log/main
extend .1.3.6.1.4.1.18689.1.3 qmail-queue /usr/local/bin/qmailmrtg7 q /var/qmail/queue
extend .1.3.6.1.4.1.18689.1.3 qmail-messages /usr/local/bin/qmailmrtg7 m /var/log/qmail
extend .1.3.6.1.4.1.18689.1.3 qmail-concurrency /usr/local/bin/qmailmrtg7 c /var/log/qmail

Ahora podemos probar que funciona buscando, por ejemplo, el tamaño de la cola que veíamos antes:

[osus@servidor ~]# snmpwalk -Os -c COMUNIDAD -v 2c SERVIDOR  .1.3.6.1.4.1.18689.1.3.4.1.2.11.113.109.97.105.108.45.113.117.101.117.101.1
enterprises.18689.1.3.4.1.2.11.113.109.97.105.108.45.113.117.101.117.101.1 = STRING: "636"

Debes sustituir COMUNIDAD y SERVIDOR por los datos de tu servidor snmpd. Ya tenemos todo preparado, vamos a por las gráficas.

Cuando comencé a buscar plantillas de Cacti para Qmail encontré bastantes referencias, pero no conseguí que funcionasen, unas simplemente me daban errores al importarlas y otras tenían los OID del snmp incorrectas y no recopilaban nada, así que lo que hice fue una mezcla de todas ellas modificadas por mi. Aquí podéis descargar mis cacti_qmail_templates, espero que os sirvan a todos. Lo importante es que los “data templates” se importen bien, a partir de ellos puedes crear tus propias gráficas. Yo os adjunto una plantilla que crea una gráfica común de todos los indicadores, cacti_graph_template_qmail_-_statistics.xml, cuyo resultado es lo que véis:

qmail_cactiPero también podéis crear gráficas independientes para cada indicador, mucho más claras, sin duda, que todas juntas. Debéis importar, en este caso, todas las demás plantillas que aparecen en el archivo.

qmail_cacti2Eso es todo, ahora podemos ver el tráfico de nuestro MTA visualmente y buscar potenciales problemas.

Descarga los templates de cacti para Qmail.

Alertas y acciones en tu servidor a través de SMS

Tal y como he prometido sigo en mi empeño de, como mínimo, dos artículos por semana, así que ahí va el segundo de esta 🙂 .

Hoy veremos cómo aprovechar un móvil que ya no utilicemos para recibir alertas y ejecutar acciones remotamente en nuestros servidores.

Monté un sistema de este tipo por primera vez allá por 2002 y desde entonces lo hago siempre que tengo nuevos servidores que manejar, sobre todo en aquellos que hacen de monitor (Cacti y/o Nagios) y backup.

La idea inicial era recibir alertas de problemas en el servidor sin tener que estar delante de la máquina. En aquél momento no había más opciones que el email, pero si no estabas delante de la máquina no recibirías nada. Posteriormente aparecieron las primeras pasarelas SMS por HTTP (con una llamada HTTP y los parámetros adecuados, envías un SMS), pero aún hoy tienen un inconveniente, si tu máquina se queda sin conectividad (problemas de red, router, ataques DOS..) nunca recibirás alertas y nunca te enterarás de que algo ocurre.

Se me ocurrió entonces que podría utilizar un Nokia 3210 que acababa de jubilar ya que además me había comprado el cable para conectarlo al ordenador por el puerto serie, pero me faltaba lo más importante, el software. Me puse a investigar y encontré lo que buscaba, era lógico, no iba a ser yo el primero al que se le ocurriese esa idea 😉 . La solución se llamaba Gnokii, un software que se comenzó a desarrollar ni más ni menos que a finales de 1998. Por lo que me consta, dejó de actualizarse allá por 2003, aunque probablemente siga funcionando perfectamente en la mayoría de casos, sin embargo hace ya tiempo que apareció un fork de Gnokii, Gammu, que es el que utilizo desde hace ya unos años y sobre el que nos centraremos en este artículo. Además he cambiado la forma de conectar el terminal al ordenador, ya no es por el puerto serie sino por bluetooth.

Podríamos dividir el artículo en cuatro pasos:

  1. Conectando el móvil con el servidor.
  2. Enviando mensajes.
  3. Sistema de mensajería avanzado.
  4. Ejecutando acciones.

Conectando el móvil con el servidor

Comenzaremos por configurar el servidor. No voy a explicar detenidamente los pasos puesto que, aunque hoy en día son sencillos, se salen del alcance del artículo. De todos modos configurar el bluetooth hace cuatro o cinco años era bastante más complicado, hoy todas las distribuciones Linux tienen los paquetes preparados.

Lo primero, obviamente, será tener una antena bluetooth en el servidor, con una USB será suficiente y funciona perfectamente, yo lo tengo así desde hace años.

El siguiente paso será instalar los paquetes necesarios para tener conectividad bluetooth, normalmente son dos, bluez-libs y bluez-utils. Si tu sistema operativo es medianamente moderno probablemente los tengas ya instalados, sino estarán en cualquier repositorio.

Como supondremos que estamos trabajando con servidores, lo más probable es que no tengas entorno gráfico, así que lo configuraremos todo a mano. Si tuvieses entorno gráfico hay paquetes gnome para hacer el emparejamiento automáticamente.

En mi Centos5.0 los archivos de configuración se encuentran en /etc/bluetooth, en el tuyo pueden variar. Tendremos que configurar tres archivos:

  • hcid.conf: configura los servicios que ofrecerá la antena bluetooth.
  • pin: pin de la SIM del móvil para no tener que introducirlo manualmente. Tambien puedes configurar la SIM para que no solicite pin.
  • rfcomm.conf: configura los canales de comunicación.

La verdad es que no recuerdo mucho las distintas opciones de hcid.conf, así que me limitare a copiar mi configuración para que tengáis un punto de inicio.

options {
        autoinit yes;
        security user;
        pairing multi;
        passkey "123";//aqui el pin de acceso a la antena del servidor
}
device {
        name "%h-%d";
        class 0x120104;
        iscan enable; pscan enable;
        lm accept;
        lp rswitch,hold,sniff,park;
}

El archivo pin es muy sencillo, simplemente debes poner el pin de la SIM de tu teléfono.

Finalmente configuramos el canal de conexión con el móvil. Para ello debemos averiguar la dirección bluetooth de tu móvil, sería algo así como la dirección MAC, de hecho tiene una estructura semejante. Para ello, inicia el servicio bluetooth, o reinícialo si lo tienes ya iniciado,

/etc/init.d/bluetooth restart

y ejecuta

hcitool scan

Esto te devolverá la lista de dispositivos bluetooth a tu alcance con el nombre y la dirección que tienen. Si obtienes algo como Device is not available: No such device, tu antena no está iniciada, quizás no se ha detectado correctamente, consulta el log de inicio con dmesg a ver qué ocurre cuando conectas la antena al USB.

Supondremos que todo ha ido bien y tienes la lista de dispositivos. Busca el del móvil que estás utilizando y apunta la dirección, la necesitarás añadir al siguiente fichero, rfcomm.conf.

rfcomm0 {
        bind yes;
        device 00:0E:07:E7:12:27;//aqui la dirección bluetooth de tu movil
        channel 1;
        comment "linea bluetooth";
}

Si todo ha ido bien tenemos el sistema bluetooth preparado y enlazado con el móvil.

Enviando mensajes

Instalamos el paquete Gammu. De nuevo, lo más probable es que haya un binario para tu sistema en los repositorios habituales, sino siempre puedes descargar el fuente y compilarlo tu mismo. Configurarlo es muy sencillo. Para empezar tenemos un sólo archivo:

/etc/gammurc
[gammu]
port=/dev/rfcomm0
connection = at19200
logfile = /var/log/smsdlog
logformat = textall
startinfo = yes

En la primera línea indicamos el canal que vamos a utilizar, que es el que configuramos en el paso anterior y añadimos un log para tener información.

Comprobamos si todo va bien. Para eso preguntamos a nuestro teléfono la hora que tiene su sistema, por ejemplo:

gammu --getdatetime

Nos devolverá la hora del teléfono y tendremos todo preparado. Ya podemos probar a enviar mensajes.

echo "probando el envio de SMS" | gammu --sendsms TEXT NUMERODESTINO

Con este sencillo comando podemos configurar cualquier aplicación que necesite enviar alertas para que nos haga llegar un SMS. Así de fácil.

Sistema de mensajería avanzado

Una vez teníamos el sistema anterior montado caímos en la cuenta de que podríamos utilzarlo para hacer más cosas de las que habíamos pensado, sólo necesitábamos saber cómo 🙂 .

Una de las máquinas que utilizábamos de monitor se encontraba en la oficina, tras una línea ADSL. El router de esta línea tenía algún problema que hacía que bajo ciertas circustancias se colgase y había que reiniciarlo, con lo que había que ir personalmente a la oficina para hacerlo. Se nos ocurrió entonces que, si ya teníamos un sistema de envío de SMS funcionando, ¿por qué no hacer que pueda recibir y ejecutar acciones en base a lo que reciba? Dicho y hecho. En vez de responder a POLI BULERIA 😉 , nuestro sistema respondería a ROUTER, aunque posteriormente fuimos ampliando las acciones, como REBOOT que permite hacer un reinicio limpio del servidor y todas las que posteriormente se te ocurran.

Investigando la ayuda de Gammu descubrimos que hay una forma de poner el sistema en modo demonio y que automáticamente recoja los SMS que lleguen al terminal y envíe los que se le encolen. Este procedimiento requiere modificar un poco el sistema, pero una vez configurado ganarás en robustez y efectividad.

La clave es la opción -smsd de gammu que lo pone automáticamente en modo demonio. Este servicio lo que hace es recoger los SMS que se reciban en el móvil y dejarlos como archivos de texto en un directorio específico mientras que coge los SMS que se quieren enviar y que previamente hemos dejado en otro directorio y los envía. Es decir, en vez de hacer los envíos directamente como veíamos antes, los dejas en archivos de texto y automáticamente el demonio los envia. Veamos primero la configuración necesaria. El archivo que maneja toda la configuración es /etc/smsdrc. De nuevo os copio mi configuración tal cual puesto que tiene mucho tiempo y no recuerdo los parámetros.

[gammu]
port=/dev/rfcomm0
connection = at19200
logfile = /var/log/smsdlog
startinfo = yes[smsd]
PIN = PINDETUSIM
logfile = /var/log/smsdlog
commtimeout = 1
sendtimeout = 10inboxpath = /var/spool/gammu/inbox/
outboxpath = /var/spool/gammu/outbox/
sentsmspath = /var/spool/gammu/sent/
errorsmspath = /var/spool/gammu/error/

No tiene mucha ciencia, el primer sector es igual que en el apartado anterior mientras que en el segundo configuramos el PIN de tu SIM y los directorios donde dejar y recoger los SMS tal como explicábamos antes.

Es importante puntializar el formato de los archivos de texto que dejaremos para enviar mensajes los que recibiremos.

  • Mensajes salientes: en outboxpath dejaremos los archivos con el nombre siguiento el patrón
    OUT<phone number>.txt,
    por ejemplo con el nombre OUT666777888.txt se enviaría al 666777888 el contenido del archivo de texto.
  • Mensajes entrantes: en inboxpath recibiremos los mensajes con el nombre del archivo siguiendo el patrón
    IN<date>_<time>_<serialno>_<phone number>_<sequence>.txt
    ,
    por ejemplo IN20021130_021531_00_+45409000931640979_00.txt. En este caso habríamos recibido el 30/11/2002 a las 02:15:31 un mensaje desde el +45409000931640979. Creo que sobran detalles adicionales.

Teniendo esto claro, podemos lanzar el demonio. Tan simple como

/usr/bin/gammu  --smsd FILES /etc/smsdrc &

Si algo va mal nos devolverá algún error, si no, tendremos nuestro sistema de envío y recepción funcionando. Para probarlo, comprueba la ruta inboxpath, si tenías SMS’s en tu teléfono empezarás a ver como entran los archivos de texto. También puedes probar a crear uno en el outboxpath siguiendo el patrón descrito, verás como lo recibes en el otro teléfono.

Hasta aquí tenemos el nuevo sistema de envío y recepción terminado. Deberás modificar tu sistema de alertas para crear los archivos de texto tal como hemos explicado y lo tendrías automáticamente funcionando. También puedes crear un sencillo script PHP que te permita enviar SMS de una manera cómoda, simplemente dejarás los mensajes en forma de archivos de texto en la cola del directorio y el demonio se encargará de enviarlos.

Ejecutando acciones remotas

Ahora deberemos hacer el script que compruebe los SMS recibidos y decida qué hacer con ellos. Os pondré un ejemplo básico para que tengáis una idea clara de cómo habría que hacerlo, es responsabilidad vuestra asegurar el acceso al sistema de acciones de manera que sólo determinados teléfonos puedan ejecutarlas. Yo, por comodidad, lo haré en PHP, pero podéis hacerlo como queráis, PERL, Python, bash, C,…

<?
$inbox="/var/spool/gammu/inbox/";
$outbox="/var/spool/gammu/outbox/";
$d = dir($inbox);
while (false !== ($entry = $d->read())) {
    if ($entry != "." && $entry != ".." && substr($entry, 0, 2)=="IN"){
        $contenido=file_get_contents($inbox.$entry)
        $palabras=explode(" ", trim($contenido));
        $mensaje=substr($entry, 2, strlen($entry));
        $datos=split("_", $mensaje);
        $fecha=$datos[0];
        $hora=$datos[1];
        $numero=$datos[3];
	//utiliza el numero para decidir si permites el reinicio desde ese cliente

	switch(trim(strtoupper($palabras[0]))){
            case 'ROUTER':
                system("/usr/bin/router.sh");
                $mensaje="El Router ha sido reiniciado";
                break;
            case 'REBOOT':
                system("reboot");
                $mensaje="El servidor se está reiniciando";
                break;
            default:
                $mensaje="La palabra clave enviada no se corresponde con ninguno de nuestros servicios.";
        }
        $serial=date("YmdHis");
        $arch=$outbox."OUTA_".$numero."_".$serial.".txt";
        $fp=fopen($arch, "w");
        fwrite($fp, $mensaje);
        fclose($fp);
        unlink($inbox.$entry);
    }
}
$d->close();
?>

El script es muy sencillo, buscamos los archivos del directorio INBOX, analizamos el nombre para ver el número de origen y separamos el contenido por palabras para decidir la acción. Fijáos que con este sistema es fácil crear acciones con parámetros, simplemente se añaden palabras y en el switch se opera como se necesite. En mi caso, cada acción recibida genera una respuesta en modo de SMS a enviar para que sepamos que la acción ha funcionado.

Y esto es todo amigos. Si has seguido bien las instrucciones tendrás un precioso sistema de envío y recepción de SMS desde tu servidor sin necesidad de tener conectividad a Internet. A través de Gammu puedes enviar también MMS, por si te apetece montar un sistema de seguridad que te envíe una captura de una webcam 😉 , por ejemplo. El límite está en tu imaginación y en tus necesidades.

Monitorizando servidores con Cacti

A nadie le cabe duda hoy por hoy que una de las tareas más importantes y necesarias en el trabajo de los departamentos de sistemas es la monitorización, tanto de máquinas como de servicios.

Hoy en día está de moda Nagios, no es la primera oferta de trabajo que veo donde buscan desarrolladores de plugins para Nagios. Antes fue Big Brother, todo un clásico de la monitorización. Ámbas son muy semejantes y su funcionalidad es parecida, la diferencia está en que Nagios es Open Source y Big Brother es comercial. En general, su utilidad es comprobar la disponibilidad de servicios en los servidores (http, pop, smtp…). Si en un periodo de tiempo determinado no hay acceso a un determinado servicio (es decir, se ha intentado varias veces sin éxito), se lanza una alerta puesto que se supone que puede haberse caído. Las alertas son ampliamente configurables, se pueden crear grupos de usuarios que la recibirán y pueden ser de distinto tipo (email, pager, sms…). Como herramienta de alertas es perfecta, sin embargo, como herramienta de monitorización se limita a ser un almacén de semáforos, mientras todos están en verde, no hay problemas, cuando uno se pone en rojo, salta a alarma. Así de sencillo. Sin embargo no nos responde a algunas de las preguntas más interesantes:

  • ¿Por qué se ha caído el servicio?
  • ¿Qué estaba ocurriendo en la máquina cuando se cayó?
  • ¿Qué otros servicios de esa máquina podrían estar influyendo en el problema?

Nos informa de la disponibilidad pero no de las posibles causas.

Cacti responde a esas cuestiones de un modo muy eficaz. Cacti es otro concepto de monitorización. Si conoces MRTG sabes de lo que hablamos. Cacti también se base en rrdtool para generar gráficos de actividad periódica. El día que tenga ganas jugaremos con rrdtool puesto que es una experiencia interesantísima, aunque hace ya tres o cuatro años que no lo toco.

Veamos un ejemplo para ir entendiendo sus ventajas. Aquí tenemos una gráfica de uso de CPU con bastante detalle.

Gráfico de actividad con 1 CPU

Alguno dirá, bueno, está bien, pero con mrtg hago cosas parecidas. Vale, veamos el segundo ejemplo, ahora con dos CPU’s, gráficas independientes y combinada.

2cpu.jpg

Vale tío, pero no me has enseñado nada nuevo, se puede hacer con otras herramientas algo parecido. Seguro, pero no con la facilidad de Cacti. Pero mira lo que te voy a enseñar ahora:

Monitorización de servicios con Cacti

No se vayan todavía, aún hay más…

Monitorización de servicios con Cacti 2

Si a estas alturas no estás sorprendido creo que no deberías seguir leyendo :P.

Como veis, podemos llegar a tener gran cantidad de información de cada uno de los servicios que tenemos corriendo en el servidor, no sólo tráfico de red o actividad de CPU. Ahora podemos responder a muchas más preguntas en caso de error:

  • ¿Qué actividad de Apache había?
  • ¿Y de MySQL?
  • ¿Cómo íbamos de tráfico de correo?
  • ¿Y de DNS? A ver si vamos a estar teniendo un DoS a través del DNS…

Más aún…

  • ¿Será un fallo hardware por la temperatura o los ventiladores de la máquina?
  • ¿Falta de espacio en disco?
  • ¿Nos hemos quedado sin memoria?
  • Por curiosidad… ¿como vá el SAI de nuestra máquina?

Con un sólo vistazo a las gráficas respondes a todas las preguntas de golpe.

¿Qué servicio está provocando el incremento de CPU? No hay más que revisar las gráficas de actividad de los principales servicios y ver cual tiene una actividad por encima de lo normal.

Conocí Cacti hará unos cuatro años y desde entonces no puedo vivir sin el. Pero Cacti es mucho más que eso. Llegados a este punto, pensarás:

Si tenemos comprobaciones periódicas de los servicios, ¿por qué no ofrecer una funcionalidad semejante a Nagios en cuanto a disponibilidad?

Voila, parece que alguien ya lo había pensado antes y tenemos un plugin para Cacti que nos ofrece los famosos semáforos verde/rojo.

Semáforos en Cacti

Bueno vale, pero ¿qué pasa con las alertas?. Sencillo, tenemos otro plugin para lanzar alertas al más puro estilo Nagios.

Según mi experiencia, la combinación Cacti/Nagios roza la perfección y se complementan entre ellos.

Hay cientos de plugins para comprobar y registrar servicios desde Cacti, prácticamente todos los servicios conocidos tienen algún plugin, y, si no encuentras lo que necesitas, siempre puedes hacértelo tú mismo. Puedes incluso crear un pequeño script en tu servidor que genere los datos que necesites y configurar un trap snmp que los lea y los devuelva a una llamada remota, de esta forma integras a la perfección tus registros personalizados con un estándar como es snmp con el que Cacti se comunica a la perfección.

Si aún no monitorizas tus servidores… tarde o temprano vas a pasarlo mal :).