Algunas configuraciones básicas en Riemann

A últimas fechas estaré hablando mucho de Riemann,un software que como espina dorzal, funciona muy bien en diferentes propósitos de monitoreo. Creo que su competidor, o alternativa, más cercana, es Nagios, solo que por Riemann, no se paga un solo peso.

Riemann es muy flexible, puesto que por si mismo puede ser un agente de monitoreo  muy completo (tiene muchos plugins), pero su verdadero poder reside en los múltiples conexiones que tiene con otros proyectos, como Graphite, Collectd y  Grafana, por nombrar solo algunos. Por esta característica, es muy útil hacerlo funcionar como un event engine, el cual se encargará de dotar de un formato y un ruteo de métricas. En algún punto, también permite tomar decisiones sobre ellas. Es decir, en Riemann pueden recaer todas las  especificidades de alarmado y tomda de decisiones en función de los valores de las métricas.

En este segundo post de Riemann abordaré como ejecutarlo y algunos de los primeros pasos para familiarizarse con la herramienta. Seguramente algunas cosas no se utilizarán, pero de todas maneras es importante conocerlas.

¿Para qué nos sirve ésto?

En primer instancia para homogeneizar la información que se ingresa, se evalúa, y se produce. Ayuda demasiado cuando agregamos nuevas métricas o nuevos hosts, ya que el trabajo es mínimo, comparado con realizarlo manualmente. Podemos administrar más hosts sin tener que hacer cambios en cada uno. Aunque claro, si utilizamos un gestor de cambios como Ansible, Puppet o Chef, sale sobrando la discusión sobre cómo administrar cada host.

A continuación un breve bosquejo de la arquitectura que podemos seguir para un monitoreo. Las métricas pueden llegar o producirse con plugins de Riemann o con software que tenga soporte para éste. Yo uso Collectd. Para la visualización podemos utilizar la solución Graphite/Grafana; misma que nos ayuda a graficar y ver en tiempo (casi) real, lo que sucede. El envío de SMS o Correo, puede ser por medio de otro software, o simplemente con un .clj dentro de Riemann. Los archivos .clj son las extensiones de los archivos Clojure.

Instalación.

En el sitio oficial podemos descargar el binario o el empaquetado que se quiera .

Basta con descomprimir de la manera habitual que se tratan estos paquetes, y que a estas alturas, querido lector, mucha literatura al respecto puedes hallar.

Inicio

Entramos a la carpeta descomprimida. En la ruta bin está el binario. Lo ejecutamos de la manera habitual. Por defecto levanta algunos puertos donde está escuchando. Con ellos podemos interconectar varias instancias en distintos host o incluso en el mismo.

Parado

Interrumpimos el servicio con control+c. 

**Más adelante haremos que inicien como servicios para comodidad de administrar.

Otros paquetes

Podemos instalar otros paquetes con el gestor de Ruby. Ésto es para efectos de pruebas y habrá a alguien que le guste la manera en que trabaja con esta simpleza. Gem es una joya, como su nombre lo indica, para la gestión de módulos en los repositorios específicos de Ruby. Vamos a instara el dashboard y los tools de Riemann.

$ gem install riemann-dash

....

$ gem install rieman-tools

Bien. Hasta aquí todo perfectamente fácil. Lo mejor es que la cosa se mantiene así de fácil todo el tiempo, claro, una vez que se los he explicado bien.

Dentro del directorio etc  encontramos el archivo de configuración. Por ahora solo mantiene uno, pero conforme busquemos implementar más características, podremos agregarlos, al mero estilo de Apache.

; -*- mode: clojure; -*-
; vim: filetype=clojure

(logging/init {:file "riemann.log"})

; Listen on the local interface over TCP (5555), UDP (5555), and websockets
; (5556)
(let [host "127.0.0.1"]
 (tcp-server {:host host})
 (udp-server {:host host})
 (ws-server  {:host host}))

; Expire old events from the index every 5 seconds.
(periodically-expire 5)

(let [index (index)]
 ; Inbound events will be passed to these streams:
 (streams
   (default :ttl 60
     ; Index all events immediately.
     index

     ; Log expired events.
     (expired
       (fn [event] (info "expired" event))))))

Primer prueba

Con esta primer prueba vamos a familiarizarnos con lo que podemos ver, y cómo lo trataremos.

Abramos dos consolas. En la primera ejecutamos riemann por sí mismo; en la segunda, sin importar el path (previa instalación de riemann-tools), ejecutamos la instrucción:

$ riemann-healt


En la consola de riemann observamos después de unos cuantos segundos la siguiente información que se muestra en la imagen. Son algunos de los atributos de nuestro sistema. 

Hasta aquí todo funciona como debiera. En los subsecuentes post, abordaré temas concretos, para al final, hacer una solución que integre todo y cada una de las cosas mencionadas. Sugiero que se empapen un poco de Clojure para poder facilitar las cosas. Hasta la siguiente entrega.