En 2014 uno de los principales problemas que surgió en el proyecto que estuve realizando en Finlandia fue la poco o nada visualización que teníamos de los servidores, la carga de trabajo, los usuarios en cada momento del día, ... Estábamos ciegos. Cuando un sistema se caía, monit se encargaba de levantarlo pero, ¿por qué se caía?, ¿podemos adelantarnos o saber cuándo podría suceder?
La base de la planificación es la medición. Si no podemos medir, no podemos planificar, solo adivinar. La importancia de un sistema de estadísticas es crucial para un sistema en producción. Obtener información en tiempo real del sistema nos ayuda a responder a las preguntas clave que todo jefe se plantea y todo administrador de sistemas necesita para dimensionar su plataforma:
- ¿Cuánta carga tiene nuestro sistema con respecto a días anteriores?
- ¿En qué momento del día se usa más nuestra plataforma?
- ¿Cuántos errores se suceden a lo largo de un día?
Además nos permite saber con cada subida paulatina si estamos ante un posible pico de uso, y desplegar así nuevas máquinas para soportar el pico, o si llegamos a una zona de poco uso (valle) en la que podamos apagar algunas instancias virtuales.
¿Cómo obtener datos desde producción?
Uno de los principales problemas al obtener información de un sistema en producción e incluso de sistemas de misión crítica es agregar un punto más de fallo. Si el sistema de estadísticas cae por un alto grado de uso o saturación de información no debería afectar al sistema en producción.
Por lo tanto, no es aconsejable que una excepción pueda interrumpir el funcionamiento normal de la aplicación debido a que la base de datos de estadísticas no esté disponible o no acepte más peticiones. Por supuesto, el hecho de que la base de datos de estadísticas sea la misma que la base de datos de servicio sería un error aún mayor.
La información sobre el sistema en funcionamiento debe enviarse siempre a un sistema ajeno al sistema en producción que no pueda entorpecer el funcionamiento normal.
Carbon y Whisper
Graphite se divide en varios elementos, uno de ellos es Carbon, un servidor encargado de aceptar los paquetes entrantes con información de los servidores y acumularlos en una base de datos o reenviarlos a otro servidor. La infraestructura a crear con este servidor está repleta de combinaciones y posibilidades. Por mi parte suelo emplear una configuración básica de un solo recolector, pero depende de la cantidad de servicios enviando información y el tipo de máquinas donde se ejecutarán estos servidores.
Otro de los elementos es Whisper, una base de datos basada en ficheros y de series de tiempo. Esto quiere decir que la información la almacena en ficheros dentro de una estructura de directorios creada para ellos y que la duración de la información es limitada. Los nuevos datos entrantes eliminan los más antiguos si exceden del tamaño o tiempo límite configurado. Esto posibilita almacenar estadísticas de las últimas 24 horas únicamente y no saturar la base de datos o el disco donde se almacenan estos ficheros al limitar su almacenamiento.
Enviar los datos hacia carbon es relativamente sencillo gracias a la disponibilidad de muchas librerías que integran el protocolo de graphite y permiten realizar los envíos con solo agregar una línea de código en los puntos donde se sucedan los eventos a registrar y contabilizar.
Además, empleando herramientas como collectd podemos almacenar información del sistema (carga de CPU, procesos, memoria, interfaces de red, ...). Se pueden encontrar más herramientas en este enlace.
Dibujando
Graphite es una aplicación realizada en Djagno. Aunque lo realmente potente es su interfaz REST, también dispone de una interfaz web para configurar gráficos y crear paneles de control de forma simplificada.
Por mi parte prefiero soluciones como Grafana para acceder a los datos. Permite realizar consultas directamente al servidor de Graphite desde el navegador y realiza la presentación de los datos con muchas opciones.
Una solución más elaborada es Kibana. Emplea una interfaz muy parecida a Grafana pero con muchas más opciones y posibilidad de configuración, porque tiene una base en código de servidor desarrollada en Ruby y Sinatra que le permite ofrecer estas opciones al usuario.
Conclusiones
La obtención de información para monitorización y conocimiento del estado es crucial para administradores de sistemas en primer nivel y gerentes de negocio en su nivel más alto. Este conocimiento no solo ayuda a mantener el sistema sano, sino también proporciona información acerca del crecimiento que permite conocer de antemano la capacidad que se requerirá en un futuro e incluso preparar la infraestructura para acciones de márketing que puedan significar picos en la plataforma, así como medir los impactos en sí de estas acciones.
Una ayuda inestimable y unas herramientas muy a tener en cuenta.
¿Y tú?, ¿tomas mediciones de tu sistemas en producción?, ¿qué herramientas usas?, si no lo haces, ¿considerarías implementar graphite u otra herramienta?
