Monitorizar el estado de disponibilidad de nuestra infraestructura de sistemas es vital para anticiparnos a que se produzcan incidencias y nos permite actuar con mayor celeridad en caso de que se produzcan, además permite detectar incidentes de seguridad que podrían pasar por alto por su nivel ‘bajo’ de impacto en el rendimiento del equipo afectado. Por todos es sabido que durante los últimos años la monitorización nos ha facilitado en gran medida el desempeño de las tareas de mantenimiento preventivo de sistemas:

  • Ya no es necesario conectarnos equipo por equipo a revisar, por ejemplo, el estado de utilización de sus recursos: espacio en disco, uso de CPU o de memoria RAM. La monitorización nos proporciona un punto centralizado en el que está disponible la información de los distintos sistemas.
  • Podemos priorizar nuestras intervenciones en aquellos equipos que la monitorización ha detectado que requieren mayor atención.
  • Disponemos de históricos de rendimiento que nos facilitan en gran medida estimar las ampliaciones o reducciones de recursos para un sistema. Nos pueden facilitar la obtención de cifras para SLAs.

slas

 

Pero no solo hablamos de acciones preventivas, si no que gran parte de su valor también reside en la detección de incidentes en tiempo real: la recepción de alertas (ya sea vía email, sms u otros) en las que se nos avisa de la indisponibilidad de algún servicio, nos permite proporcionar una respuesta rápida a estos eventos, facilitando además la resolución de las incidencias. Imaginad esta situación: recibimos una alerta de que el servicio de base de datos de nuestro ERP empresarial no está respondiendo, los técnicos de sistemas nos ponemos rápidamente a trabajar en su resolución, anticipándonos a que los usuarios puedan verse afectados por ello, y teniendo un foco claro de cuál es el punto de fallo en el caso de que alguien nos reporte un fallo en la aplicación de gestión, ya que la alerta nos ha informado de que el servicio no disponible es el de base de datos.

¿Y en que nos ayuda esta monitorización a detectar compromisos de seguridad en los elementos de nuestra infraestructura? Imaginaos que un servidor ha sido comprometido y ahora forma parte de una botnet de minado de criptomonedas, ¿Cómo detectarlo si el servidor sigue estando online y proporcionando sus servicios de manera ‘normal’ si no disponemos de una solución de seguridad avanzada como un SIEM? La monitorización del mismo reflejará valores de uso de CPU anormales, y a partir de ese momento actuaremos en consecuencia al ser alertados de un rendimiento anormal. ¿Y si nuestro servidor de correo on premise está siendo usado para el envío de correo no deseado? La monitorización constante de la cola de correo o del tráfico de la tarjeta de red del servidor nos permitirá detectar este tipo de compromisos. Ciertamente, un sistema de monitorización nunca podrá equipararse a un SIEM u otros dispositivos de seguridad específicos, pero es un complemento o un buen punto de entrada a la hora de mejorar nuestra seguridad.

Tradicionalmente hemos venido monitorización valores de RAM, CPU, ocupación de discos o estado de los servicios de los equipos, pero la realidad es que podemos extender la monitorización no solo a los equipos o servidores finales, si no también podemos monitorizar la infraestructura que los sustenta, algunos ejemplos de valores que podemos y deberíamos monitorizar son:

  • Estado de infraestructura virtual VMware: espacio en datastores, estado de salud de los host ESXi, valores de uso de los hosts ESXi, snapshots existentes en los equipos virtuales,…
  • Estado de salud de cabinas de almacenamiento: discos en fallo y otros errores de hardware, estado de replicación entre cabinas (si existiese), estado de los arrays,…
  • Estado de salud del hardware de chasis Blade y otros equipos gama server.
  • SAIs: estado de la carga, información sobre voltajes entrada/salida, valores del entorno…
  • PDUs: estado del dispositivo, líneas de entrada/salida.
  • Switches: estado de salud hardware, tráfico de los distintos interfaces, existencias de bucles,…

 

switches

Además de en monitorización de infraestructura, también se puede realizar monitorización en detalle de elementos tales como:

  • Base de datos: MySQL (tamaños, consultas costosas, conexiones…), MS SQL Server (tamaños, conexiones, bloqueos…), Oracle, Postgre,…
  • Servicios de red: disponibilidad directorio activo, DHCP, DNS interno,…
  • Infraestructura de impresoras: niveles de tóner, fallos hardware en la impresora,…
  • Microsoft IIS: estado de los pools, de aplicaciones web,…

Los anteriores son solo algunos ejemplos, pero la lista de elementos a monitorizar es muy amplia. Recordemos además que en muchos casos esta monitorización podemos realizarla usando el protocolo SNMP, el cual es ligero y no implica la instalación de ningún tipo de agente ni aplicación de terceros en los equipos a monitorizar. Incluso para una abundante cantidad de chequeos de estado ni siquiera es necesario el uso de consultas SNMP, pudiéndose realizar mediante el uso de protocolos de red comunes.

 

snmpYendo un paso hacia adelante, cabe destacar la utilidad de integrar los elementos monitorizados en mapas que nos permitan tener una visión general rápida del estado de nuestros sistemas.

Las plataformas de monitorización existentes en el mercado son varias, algunas de las más conocidas son Nagios, Centreon, Zabbix, SolarWinds, PRTG, y por supuesto SCOM de Microsoft. Entre ellas algunas son open source, y otras de pago, las hay más básicas y otras con características más avanzadas, la elección de una u otra solución dependerá de las características de nuestra organización y de la funcionalidad que deseemos obtener de la misma. En cualquier caso, lo mejor antes de iniciarnos en un proyecto de monitorización es asesorarnos con expertos en despliegues de estas características que nos aconsejen cuál es la mejor solución para nosotros y nos acompañen durante el despliegue del proyecto y en su posterior soporte.

Leave a Reply