Instalación de Riemann

El tema del monitoreo es por sí solo vasto y exige cierto nivel de especialización y comprensión. Como todas las soluciones de software, el establecimiento de una arquitectura y elección de productos conlleva un conocimiento profundo del las necesidades y las mejores opciones disponibles, no solo en términos de costos, sino de prestaciones y flexibilidad de los productos que están en el mercado. No es cosa fácil establecer un flujo y tratamiento adecuado de las métricas recolectadas.

En lo que mi experiencia acontece, éste rubro de las TI apenas se le da importancia, se mira como un gasto que no tiene retorno. Los profesionales lo entienden como la manera en detectar problemas en los ambientes productivos, pero que si se detectan vía registros, el problema está cuasi resuelto, por tanto, la necesidad de un sistema complejo de monitoreo no es necesario. 

No estoy a favor de acumular datos y sólo mantenerlos por si llegasen a requerirse en algún punto, si las cosas van mal con las aplicaciones y hay que encontrar al culpable. El valor de la información, como bien hacen los mineros de datos, es encontrar las relaciones que les dan sentido, y que por supuesto, nos permiten identificar qué estamos haciendo bien y qué estamos haciendo mal. Todo esto, se refleja en el negocio.

Se habla de tres estadios de madurez en el uso de herramientas y técnicas de monitoreo:

1. Manual (scripts generalmente)
2. Reactivos
3. Proactivos

 

No es posible ser puristas en la implementación de éstos, ya que por lo normal se tienen dos, o si va muy bien la cosa, los 3 estadios en la misma organización. En el peor de los escenarios, no se tiene ninguno, y a la buena de Dios caminan los sistemas.

Yo hasta hace un tiempo había utilizado scripts en bash que me permitían reaccionar ante eventos catastróficos, como la disruptiva baja de un servicio o el acumulado de espacio en un volumen de lvm que acarrearía problemas si llegaba al 100% de ocupación. Teníamos un sistema completo de monitoreo que no siempre funcionaba como debía, y que ante eventualidades detectábamos su pobre funcionamiento, además de una subexplotación de todas sus funcionalidades.

Durante las pruebas de rendimiento que siempre me han fascinado, encontré fórmulas que me permitían "hacer hablar" a los datos, y los casos en los que éstas eran de utilidad. En ese momento me pregunté ¿Si esto puedo hacerlo en un ambiente como QA por qué no llevarlo a Producción? por medio de manejadores de texto, como AWK y SED, exploté de muchas maneras los registros generados, e incluso, las estimaciones que realizábamos de utilización, fallos, correlacionar los eventos que llevaban a un empobrecimiento de los tiempos de respuesta, etcétera. Seguía faltando algo.

Actualmente me encuentro revisando temas de monitoreo y su implementación con un modelo proactivo. Esto quiere decir que vamos dejar de preguntar si el servidor está arriba o abajo, si el servicio web contesta o no, y consultas como esas (polling). El modelo proactivo invierte la manera en que se obtienen las métricas (pushing), los nodos y sus elementos son los que “hablan” y envían información al concentrador de métricas.

Gracias a la lectura de The art of monitoring, un texto obligado para comprender muchos de los beneficios de organizar un monitoreo y su aprovechamiento. Está demás explicar concienzudamente del libro, lo pueden hallar en librerías como Amazon o Google Books en formato digital o impreso. Vale mucho la pena. James Turnbull tiene la cualidad de expresarse claro y con ejemplos que ayudan a dar los primeros pasos.

Riemann. Es una herramienta que se basa en eventos, y su implementación es por pushing. Es muy flexible y cómodo de utilizar, claro, una vez que le dedicaste algunas horas para entender su funcionamiento y ensayar con algunas de las características que buscas de la herramienta.

A groso modo escribiré los pasos de instalación. En otros escritos entraré de lleno en configuraciones con las que he jugado.

Instalación de Riemann

Como es consabido en el mundo del Software Libre, las opciones van desde los genéricos, los empaquetados propios de la distribución, hasta el código fuente. Esta vez usaremos el genérico. 

1. Bajar el empaquetado desde la terminal.
   1. wget https://aphyr.com/riemann/riemann-0.2.11.tar.bz2
2. Deflate el paquete en la línea de comandos.
   1. tar xvjf riemann-0.2.11.tar.bz2

Tenemos una estructura como la siguiente con tres directorios.

1. bin
2. etc
3. lib

bin. Contiene el script de arranque del servidor de Riemann. Es un wrapper que lo único que hace es validar que los parámetros se pasen de manera correcta, de lo contrario despliega el un usage. Establece el classpath y ejecuta el jar que se encuentra en la carpeta lib. Por defecto, en este mismo directorio se escribirá el log.

etc. En este directorio se guarda el archivo de configuración de Riemann. Asimismo, los archivos .clj (Clojure) para la definición de nuevas funciones y namespaces se almacenarán aquí, aunque claro, descendiendo en carpetas (creadas ex profeso).

lib. Ejecutable (jar) de Java para la puesta en funcionamiento del servidor.

Nota: Riemann está desarrollado en Java con Clojure, por lo tanto, requiere un JDK. También requiere una versión actual de Ruby, ya que la instalación de algunos componentes es vía gem.

Instalamos algunos componentes que ocupamos para comenzar a utilizar Riemann como agente.

$ gem install --no-ri --no-rdoc riemann-tools riemann-dash

Software utilizado

[root@uxmal ~]# cat /etc/redhat-release
CentOS release 6.8 (Final)

[root@uxmal ~]# java -version
java version "1.7.0_111" OpenJDK Runtime Environment (rhel-2.6.7.2.el6_8-x86_64 u111-b01)
OpenJDK 64-Bit Server VM (build 24.111-b01, mixed mode)

[root@uxmal ~]# ruby -v
ruby 2.2.5p319 (2016-04-26 revision 54774) [x86_64-linux]

 

Algunas referencias.

[1] Quick start

[2] Download the latest Ruby version

[3] Using diferent versions of Ruby

[4] Riemann site