Enfocados en la monitorización de servidores virtuales

Monitorización de servidores virtuales: puntos clave que debemos tener en cuenta

Es innegable el hecho de que hoy en día realmente habitamos en las nubes… de servidores virtuales. Esto es así porque la gran mayoría de servicios y aplicaciones «reposan» en ellas: cualquier encuesta que se haga a los usuarios arroja, de plano, que los utiliza muy frecuentemente (bancos, universidades, comercio electrónico, etc.). Pero, ¿cómo se realiza la monitorización de servidores virtuales? En ello Pandora FMS (PFMS) ha hecho bien sus deberes y hoy os explico cómo.

Leyenda: «La Sortie de l’opéra en l’an 2000»: así imaginaban en 1902 nuestra vida en el pasado año 2000
Fuente: Wikipedia, imagen de dominio público

Yo hallo graciosa la imagen anterior porque nuestros colegas antepasados plasmaron sus obras de ciencia ficción siempre pensando en la movilización física. Ahora, en el siglo XXI, vemos que hemos tenido que afrontar el teletrabajo forzoso, percatándonos de lleno de que no es necesario estar de cuerpo presente para laborar y menos aún en el caso de la monitorización de servidores virtuales (sucesores de los servidores físicos y reales).

No estoy afirmando que el hardware como tal no merece atención; de hecho, al comenzar desde cero con nuestros servidores, nos haremos preguntas importantes como ¿qué montamos, servidores tipo blade o servidores tipo rack? o ¿qué tipo de hipervisor usaremos? ¡Son consideraciones que impactarán en nuestros servidores virtuales, tanto si somos programadores como si somos usuarios!

Por supuesto, después de que hayamos estacionado, conectado y configurado nuestros servidores físicos, que luego albergarán nuestros servidores virtuales, Pandora FMS nos acompañará en nuestra obligatoria monitorización de los mismos, en los denominados Centros de Datos o granjas de servidores.

Monitorización de servidores virtuales

Considero que existen, al menos, dos clases de servidores virtuales que, por supuesto, nacieron de sus contrapartes reales. Por ello simplifico en demasía (si sois expertos tal vez os escandalizaréis con lo que viene a continuación):

• Servidores virtuales completos.
• Servidores virtuales en contenedores.

Monitorización de servidores virtuales completos

Digamos que utilizamos el hipervisor VirtualBox (mi favorito), el cual es un software de código abierto para varias plataformas, Microsoft Windows® y GNU/Linux® incluidos. Para nadie es un secreto que GNU/Linux reina tanto en servidores reales como virtuales (el resto del artículo solo hablo de servidores con GNU/Linux®). Así que ya hemos descargado un fichero enorme que contiene una imagen de instalación de nuestra distribución favorita.

Con todo esto a mano, el proceso de creación y luego la monitorización de servidores virtuales dista poco de lo que hacemos en la vida real con el hardware en mano, es decir, a nuestro alcance físico. Por cierto, esto último se denomina metal al desnudo o, en inglés, «bare metal». A partir de allí, de los hipervisores, se han creado interesantes opciones para su automatización. Esto último es posible porque los hipervisores aceptan órdenes por líneas de comando e incluso por medio de la Interfaz de Programación de Aplicaciones (Application Programming Interface o API) podremos crear, correr, modificar y destruir nuestras máquinas virtuales. ¿Cuál es la diferencia entre instalación manual y la automatizada?

Leyenda: Sextante en Museo Paulista de Brasil (Wikipedia)

Eso que veis arriba es un sextante con brújula: todo buen marinero tiene uno siempre guardado junto a la lista de estrellas más brillantes del firmamento, para que de día o de noche y estando en mar abierto, poder llegar a puerto seguro. Pero en este siglo lo más probable es que se oriente mediante el Sistema de Posicionamiento Global (Global Positioning System o GPS) y hasta los navíos se conducen prácticamente de manera automática. Recalco la palabra prácticamente porque siempre deberemos configurar nuestros servidores virtuales con al menos unas plantillas en lenguajes normalizados para software especializado.

El software ex profeso para estas tareas bien puede ser Vagrant o cualquier otro que permita crear máquinas virtuales con diferentes hipervisores y aquí es donde comienza la automatización. Vagrant mantiene imágenes de instalación de los principales sistemas operativos y puede descargarlas por nosotros siempre y cuando tengamos una muy buena conexión a Internet, porque estamos hablando de varios gigabytes.

También puede -o más bien debe– aprovisionar, es decir, descargar e instalar todo el software que necesitemos y esté en los repositorios oficiales. Aquí volvemos al tema de la monitorización de servidores virtuales, porque bien podemos en este punto el incluir, colocar e instalar Agentes Software de Pandora FMS para que recolecten las métricas (datos de monitorización) y las envíen a nuestro servidor PFMS. También los Agentes Software PFMS pueden ser instalados con ayuda de Ansible o Puppet, entre otros.

Algunas de las ventajas del uso de los Agentes Software PFMS en la monitorización de servidores virtuales son:

• Los empleados que realicen trabajo remoto usan las Redes Privadas Virtuales (Virtual Private Network o VPN) para cifrar y proteger información; PFMS vigila de cerca este tráfico de red y alertará ante cualquier problema (congestión, número de usuarios, etc.).
• Vigilar el espacio en disco en cada servidor virtual y avisar con tiempo para que tomemos nuestras previsiones.
• Aplicaciones que dependen, digamos, de un servidor web virtual podrán ser vigiladas y que permanezcan en línea de manera constante.
• Preguntar de manera directa al sistema operativo acerca de la temperatura del equipo del lado del hipervisor. Acoto esto para que nunca perdamos de vista qué subyace debajo de la monitorización de los servidores virtuales, ya que con un solo Agente Software en el bare metal nos ahorrará las decenas de Agentes Software que necesitaríamos para cada uno de los servidores virtuales que están en un solo servidor real.

Monitorización de servidores virtuales en contenedores

Como ya habrán imaginado, un servidor virtual completo es un entorno aislado que se comporta en una red pública o privada como una máquina más, incluyendo su dirección(es) IP propia en su(s) propia(s) tarjeta(s) de red virtual.

En el caso de los contenedores ahorraremos un componente importante al compartirlo con los servidores virtuales: el kernel del sistema operativo. Esto quiere decir que solamente podremos usar únicamente servidores GNU/Linux®, ya que Docker®, software que reina de facto en los contenedores, solo opera de manera virtual sobre este kernel.

Esto quiere decir que nuestros servidores virtuales en contenedores accederán -con los debidos permisos que otorguemos- a los componentes reales, al bare metal, lo cual redunda en rapidez, ahorro de memoria y uso de la Unidad Central de Procesamiento (Central Process Unit o CPU), etc. ¿Recuerdan los Agentes Software de PFMS? Nuestros servidores PFMS también pueden trabajar sin ellos y revisar periódicamente dichos contenedores. De nuevo traigo el caso de un servidor nginx virtual; una consulta remota con curl debe devolver un código HTTP 200 cada minuto y si en tres consultas seguidas falla obtendremos una alerta por nuestra consola o Metaconsola PFMS.

Todo este panorama y manera de trabajar, lejos de disiparse, más bien se amplía: en el horizonte se atisba a Podman, otro hipervisor para servidores virtuales en contenedores.

Automatización de la monitorización de servidores virtuales en contenedores

A pesar de lo largo -y tal vez atemorizante- del título de esta sección, como os dije PFMS ha hecho su tarea muy bien. Sin embargo, primero debo explicaros algo importante.

Para los contenedores virtuales existen los llamados «directores de orquesta» con los que, por medio de las credenciales y token de nuestras API, podremos administrar cientos o miles de máquinas virtuales que utilizan Docker. En el caso de Docker Swarm Pandora FMS corre en modo virtual para entrar y formar parte del entorno y obtener las métricas necesarias; a su vez podremos unificar en una Metaconsola (versión Enterprise) con otros servidores PFMS.

Pero el más conocido de dichos «orquestadores» es Kubernetes, para el cual, desde la versión 738 de PFMS, contamos con un complemento que nos indicará el porcentaje de uso del CPU de un nodo, cantidad de pods y otras métricas, con todo lo cual podremos realizar nuestra monitorización de servidores virtuales de manera masiva. Como dije, nuestro servidor PFMS puede correr de manera virtual en un contenedor; con Agentes Software u otro servidor PFMS podremos monitorizarlo, pero también existen otras alternativas.

Prometheus y Grafana

Prometheus se ha convertido en pieza clave de la monitorización en Kubernetes, aprovechando que fue escrito de manera nativa para dicho entorno. Es decir, fue programado desde cero siempre pensando y teniendo en cuenta los contenedores de servidores virtuales.

Prometheus, sin extenderme mucho, utiliza tecnología de reciente creación como son los registros de series temporales o series cronológicas, usando bases de datos especializadas para guardar parejas de claves-valores («key-value») y así consultar y resumir de manera gráfica con Grafana.

Una serie cronológica es una serie de puntos de datos recabados e indexados, u organizados en orden temporal. Lo más común es que una serie cronológica sea una secuencia tomada en puntos sucesivos igualmente espaciados en el tiempo. Por lo tanto, es una secuencia de datos temporales discretos. Ejemplos de series temporales son las alturas de las mareas oceánicas, los recuentos de manchas solares o, como en nuestro caso, la monitorización de servidores virtuales.

Ahora bien, expongo que esta automatización tiene un coste: Prometheus utiliza un modelo de datos que implica que sus métricas a recoger deben tener un patrón estricto de nombrado o sustantivo de la métrica. En expresiones regulares o regex debe cumplir con la siguiente fórmula:

[a-zA-Z_:][a-zA-Z0-9_:]*

El consejo popular dicta que si podemos resolver un problema usando regex entonces tenemos dos problemas (os dejo un poco de humor). En PFMS podemos nombrar nuestras métricas como queramos, pues de manera interna utilizan un identificador absoluto. Lo que hace Prometheus es trabajar con metadatos, es decir, el dato se describe a sí mismo; en PFMS los datos están fuertemente tipados (o normalizados, según norma, digo yo). La principal ventaja de las métricas fuertemente explícitas (valga la redundancia) es que nos permite convertir unidades en un posprocesado. Además, permite guardar conceptos abstractos como la protección en cascada, cosa no contemplada en Prometheus. Todo ello está mucho mejor explicado en el capítulo dedicado a la introducción a la monitorización en PFMS; recomiendo en sumo grado su lectura.

Así, PFMS permite declarar de manera explícita que en una métrica que recogeremos su unidad es bits y luego queremos su representación gráfica en bytes, por lo que hay que dividir entre ocho. Prometheus aconseja que las unidades estén en el nombre o en la etiqueta de la métrica (pero no en ambos), como por ejemplo http_request_duration_seconds donde la palabra «seconds» nos indica que el número que acompaña la clave está expresado en segundos. ¿Por qué Prometheus escoge esta vía? Pues para poder consultar y crear gráficas de manera rápida y automatizadas. Aclaro que no doy a entender que Prometheus invente nada nuevo, de hecho se rigen por las normas de la OpenTDBS.

Leyenda: Arquitectura de los servicios y comando en OpenTSDB (http://opentsdb.net/overview.html)

Me permito extenderme un poco en este punto: digamos que en Prometheus queremos ver las métricas que estén en porcentaje (por ejemplo espacio en disco libre); en nuestra consulta deberemos incluir la palabra clave ratio … ¡Es una idea genial! ¿Qué podría salir mal? Que el que creó la métrica no se le haya olvidado colocar la palabra clave en el nombre o etiqueta de la métrica… Y eso sin contar que no todo el mundo habla inglés…

La manera de combatir estas ambigüedades o posibles fallos es que Prometheus trae una abundante cantidad de métricas preconfiguradas; es como si desarrollamos un software que identifique gatos en fotografías y agregamos miles de fotos de gatos para que ayude a su identificación… Este último ejemplo deseo que no lo tomen a mal, no es mi intención ir en contra de la recolección de series temporales: de hecho para la detección de anomalías se utiliza la teoría de series temporales.

También PFMS utiliza LogStash y ElasticSearch para la recolección de registros o logs, con la premisa de tomar datos de cualquier fuente, organizarlos y presentarlos en tiempo real. Pandora FMS toma las riendas en este asunto porque la monitorización de máquinas virtuales ocupa una cantidad muy asombrosa de datos que tienen un coste de tiempo y dinero para su almacenaje y procesamiento, cosa que casi ninguna empresa se puede permitir.

También la flexibilidad de PFMS permite la adición de este tipo de tecnología para la monitorización, y de hecho utiliza Grafana de manera rápida y sencilla en la consola.

Leyenda: Integrar Grafana con la monitorización de Pandora FMS

Antes de finalizar este artículo, recuerda que Pandora FMS es un software de monitorización flexible, capaz de monitorizar dispositivos, infraestructuras, aplicaciones, servicios y procesos de negocio.

¿Quieres conocer mejor qué es lo que Pandora FMS puede ofrecerte? Descúbrelo entrando aquí.

Si tienes que monitorizar más de 100 dispositivos también puedes disfrutar de una DEMO GRATUITA de 30 días de Pandora FMS Enterprise. Consíguela aquí.

Por último, recuerda que si cuentas con un número reducido de dispositivos para monitorizar puedes utilizar la versión OpenSource de Pandora FMS. Encuentra más información aquí.