en Podcast

Hay servicios que tienen que estar funcionando 24/7 y en caso de de cualquier fallo o incidencia tenemos que estar informados inmediatamente para poder actuar y que esa falta de servicio se zanje lo antes posible.

Hoy para grabar el podcast he cambiado de micrófono y he probado un BCT dinámico con un mezclador externo, así que si notáis el audio un poco extraño es eso.

Enlaces:

  1. Nagios Core: https://www.nagios.org/projects/nagios-core/
  2. Icinga 2: https://www.icinga.com/download
  3. Zabbix: http://www.zabbix.com/
  4. Zenoss: https://www.zenoss.org/
  5. Nagstamon: https://nagstamon.ifw-dresden.de/
  6. Cacti: http://www.cacti.net/
  7. MRTG: http://oss.oetiker.ch/mrtg/
  8. Network Weathermap: http://www.network-weathermap.com/
  9. NFSen: http://nfsen.sourceforge.net/
  10. The Dude: https://mikrotik.com/thedude

Podemos tener para monitorizar un amplio abanico de servicios, podemos querer monitorizar que algún servidor sirva páginas web, podemos monitorizar que la carga de un puerto de un switch no pase de 600Mbps, podemos monitorizar que un certificado de una web no haya caducado, podemos monitorizar que la temperatura de un router no supere los 78 grados, podemos monitorizar que nadie abra la puerta de un rack, podemos monitorizar absolutamente todo, no tenemos límites.

Para monitorizar algo tenemos desde herramientas sencillísimas como un ping, protocolos como snmp, o una serie de complejos scripts que puedan alertarnos de situaciones que requieran una serie de calculos o acciones anteriores.

Si queremos comprobar que un servidor esté encendido quizás un ping cada minuto será suficiente, pero si queremos comprobar el consumo energético de una regleta eléctrica en un centro de datos ya tendremos que utilizar un protocolo llamado SNMP.

Pero, ¿qué es el SNMP?. Es un protocolo que permite conocer información de dispositivos, pero no cualquier tipo de información, sino aquella que el dispositivo tiene disponible en su MIB, que es la base de datos de eventos que tiene programado.

Por ejemplo, si queremos saber cual es el nombre de un servidor podemos preguntar por SNMP a un servidor por su nombre y nos contestará con esa información, igual si le preguntamos por la IP de sus interfaces o la carga del sistema el servidor nos va a contestar con esa información.

Pero esa base de datos tiene una estructura en árbol y esa información está organizada como tal, de forma que es jerarquica, si tenemos varios interfaces todos van a estar organizados en el mismo grupo o nivel y si queremos ver la IP tendremos que ir interfaz por interfaz y luego bajar hasta la IP.

Cada unidad de información de la MIB se llama OID (object identifier).

Tampoco quiero meterme mucho en SNMP pues no es el objetivo de este audio, sólo quiero que sepáis que podemos preguntar a un nodo por un OID concreto y este nos responderá con el valor de tal OID. Y también quiero que sepáis que el ODI viene definido en la MIB del elemento que estemos tratando.

Por ejemplo podemos ver la memoria utilizada en ese momento concreto, pero si quisieramos saber cómo ha variado el uso de la RAM en las últimas 24 horas tendríamos que bajarnos las mediciones concretas y luego con esas mediciones ya sabríamos cual ha sido la evolución, pero eso no ya es SNMP, SNMP es sólamente el valor concreto, si luego esa información la guardamos para tratarla posteriormente haciendo gráficos o lo que queramos ya no es SNMP, es otra cosa, esa otra cosa es lo que hacen algunos sistemas de monitorización.

Estupendo, ahora ya podemos monitorizar por ejemplo la temperatura y podemos dibujar como ha ido cambiando a lo largo del día, pero además puede ser que queramos que cuando llegué a un cierto umbral nos avise enviando una alarma, un email o un mensaje de telegram.

Y luego lo mejor queremos que cuando la temperatura llegue a un nivel concreto haga algo solo, como por ejemplo subir el aire acondicionado. Esto ya es algo más avanzado.

Pues bien, cuando hablamos de sistemas de monitorización hablamos de todo este ecosistema.

Ahora vamos a ver unos cuantos softwares utilizados para monitorizar sistemas, vamos a empezar con la enorme familia de Nagios, los derivados y similares aunque no sean directamente derivados.

Empezamos con Nagios tal cual, el llamado Nagios Core.

Nagios Core es un sistema de monitorización que puede utilizar comandos como ping, snmp o comandos ejecutados en el sistema remoto gracias a NRPE (Nagios Remote Plugin Executor).

Es precisamente NRPE una de las características más importantes de Nagios. En las máquinas monitorizadas se puede instalar el nagios-nrpe-plugin y a través del puerto 5666 permitirá la ejecución de comandos remotos. Es interesante no permitir el acceso al puerto 5666 a máquinas que no sean el servidor de Nagios.

La ejecución de comandos remotos con NRPE va a permitir obtener información mucho más sofisticada de la que se pueda obtener con un simple SNMP, por ejemplo podremos solicitar con NRPE que nos devuelva el porcentaje de espacio en todas las particiones y que dependiendo del porcentaje de uso nos devuelva una alarma de tipo Warning o Critical.

Con NRPE podemos crear scripts que se van a ejecutar en el remoto, scripts que harán lo que queramos, y lo único que tienen que tener en cuenta es que nos va a devolver un resultado, que va a ser el mensaje que saldrá en la alarma de Nagios y luego un número 0,1,2 ó 3, siendo 0 Normal, 1 Warning, 2 Critical y 3 Unknown, así de faćil.

Por supuesto podremos ejecutar scripts que no usen NRPE y que devuelvan esos mismos valores.

Por poner un ejemplo concreto, en la MIB de Mikrotik no se devuelve el estado de los peers de BGP y con un script de este estilo se puede comprobar si algún peer ha caído y devolver un 2 (Crítical) y si lleva menos de 30 minutos arriba devolver un 1 (Warning).

Por supuesto también podemos usar SNMP para ver si algún interfaz cae o cosas así.

Las posibilidades y la flexibilidad de Nagios es enorme, pero , todo tiene un pero, su gestión es un infierno.

Nagios se maneja editando ficheros de texto, es horrible, lo más alejado de la usabilidad posible, aunque hay soluciones como NagiosQL que le dotan de un pequeño entorno de gestión web, pero con una instalación no exenta de problemas y complicaciones.

Para todos aquellos que quieran usar Nagios, pero que no estén dispuestos a pasar por el calvario de su gestión existen otras alternativas.

Las alternativas proporcionan un gestor mucho más amigable, muchas más posibilidades y facilidades, pero un sistema menos liviano y más pesado.

Dentro de estas alternativas he sido usuario de Opsview, pero ahora la versión Community está oculta y hay que ir a tiro hecho para poder descargarla y no me gusta la actitud, más siendo sofware libre, así que esta opción la desechamos.

Luego tenemos Icinga, un software muy utilizado, que nació fruto de un fork de Nagios en el 2009, así que cada minuto que pasa se separa más de su antiguo padre.

Icinga 2 a día de hoy se ha diferenciado lo suficiente de Nagios como para ser sistemas diferentes, lo que pasa es que en mi mente siguen estando juntos y realmente su enfoque sigue siendo muy parecido.

Icinga 2 está mucho más avanzado que Nagios, pero es como todo ¿qué es lo que realmente necesitáis? Con Icinga 2 vais a disponer de gráficas, informes, en fin, todo lo que necesitéis.

Y muy parecidos a Icinga 2 tenéis Zabbix y Zenoss, cada uno con sus cosas, pero al final muy similares entre si.

Si no tenéis unos requerimientos muy especiales realmente os podría servir cualquiera de ellos, lo que podéis hacer es probarlos con unos pocos servicios y después decidir.

Por supuesto todas estas opciones disponen de software para avisaros si hay alguna alarma, como Nagstamon, que es el cliente que yo tengo en mi portátil. Por supuesto también hay clientes para android, para windows o para mac. En Iphone hay un problema y es que Apple no permite software que haga pooling por rendimiento de la batería, así que tendréis que buscar soluciones diferentes basadas en push y su integración con el software que tengáis.

Cambiamos de tercio y si Nagios y demás estaban enfocados a las alarmas, ahora vamos a hablar de sistemas más enfocados en visualización de gráficas.

Los más conocidos son dos MRTG y Cacti, ambos son dos sistemas basados en RRDTool, que es el software que utilizan ambos sistemas para generar sus gráficas.

cacti

El objetivo de estos sistemas es poder ver fácilmente y de forma gráfica la evolución de algo, ya sea tráfico, temperatura, utilización de disco, etc…

Cacti para extraer los datos hace uso de SNMP y la configuración se realiza dentro de la propia web del servicio. Resulta muy conveniente y cómoda la utilización de Cacti pues de forma rápida se pueden crear gráficas que nos muestren datos, incluído el famoso percentil 95 que es la medida por la que nos van a cobrar el ancho de banda en la mayoría de los sitios.

La única pega que tienen tanto MRTG como Cacti es la organización de las gráficas, porque si tenemos 10 gráficas perfecto, pero en cuanto tengas 500 pues ya no es un sistema manejable.

Para hacerlo manejable y que sea posible gestionarlo hay aplicaciones, como Network Weathermap, que a mi me gusta mucho, con el que podemos hacer mapas que al pinchar en los nodos se abran las gráficas de Cacti.

Luego tenemos otro software que sólo sirve para monitorizar el tráfico de BGP que se basa en Netflow y se llama NFSen.

NFSen nos va a permitir ver flujos de tráfico y detectar por ejemplo patrones de trafico extraños o no adecuados, etc….

El entorno clásico es Nagios + Cacti + NFSen, pero claro hay muchísimas opciones más.

Por ejemplo en entornos WISP sobre todo que se utiliza muchísimo Mikrotik lo que hace mucha gente es ir a la opción a medida que sería The Dude, el software de Mikrotik.

También tenemos el entorno corporativo o de gran Telco donde soluciones del tipo Netcool, OpenView o similar son muy utilizadas.

De todos modos el software que os he nombrado es un software genérico en su mayoria y existen casos en los que es necesario utilizar un software especializado que luego sea el que mande las alarmas a nuestro sistema paraguas o genérico.

Vamos a suponer que queremos monitorizar la apertura de una puerta de una caseta o un rack y que ese sensor de apertura no dispone de SNMP sino de una solución específica, en ese caso si hubiera una apertura el sistema específica se enterará y mandará una alerta a nuestro sistema de gestión paraguas.

Los sistemas de gestión paraguas o intermedios son muy necesarios en el caso de entornos en los que puede haber decenas o centenas de softwares especializados de gestión para poder unificar todas las alarmas en una sola pantalla, porque al final lo que queremos es tener constancia de lo que ocurre de la forma más fácil sin tener que inspeccionar 17 pantallas diferentes.

Hasta aquí perfecto, ya tenemos sistemas que nos dan alarmas y que nos pintan datos, pero nos falta algo, si se cayese nuestra infraestructura, incluyendo nuestro sistema de monitorización no nos vamos a enterar, pues no llegará ninguna alarma, está todo caído. ¿Qué hacer en ese caso?

En ese caso es muy interesante disponer de una monitorización externa, puede ser mucho más sencilla para avisarnos en el momento el que perdamos la monitorización por la razón que sea, que puede ser porque el sistema de monitorización principal ha caído o porque la infraestructura completa ha caído.

Para montar un sistema de monitorización externo lo único que necesitaremos es disponer de un servidor fuera de nuestra infraestructura o contratar un servicio externo de monitorización, lo que más rábia os de y lo que os sea más cómodo.

El sistema de monitorización externo no debe de tener la precisión del interno ni todos los datos del interno, pero sí que tiene que avisarnos en el caso que haya algún problema en nuestra infraestructura para no quedarnos ciegos.

La monitorización al final nos va permitir reaccionar más rápido que nuestros clientes en caso de un problema, porque no es lo mismo que nos llamen para comunicar un problema y que ya lo sepamos a que no tengamos ni idea, no tiene absolutamente nada que ver.

Escribir un comentario

Comentario