Introducción a la pila ELK

Los productos que construimos a menudo dependen de múltiples servidores web y/o múltiples servidores de bases de datos. En tales casos, a menudo no tenemos herramientas centralizadas para analizar un...

Los productos que construimos a menudo dependen de múltiples servidores web y/o múltiples servidores de bases de datos. En tales casos, a menudo no tenemos herramientas centralizadas para analizar y almacenar registros. En tales circunstancias, identificar diferentes tipos de eventos y correlacionarlos con otros tipos de eventos es una misión casi imposible.

Una sola condición de excepción, en algún punto intermedio del sistema, puede ser desastrosa tanto para el usuario final como para el equipo de desarrollo. Un usuario puede terminar mirando una página en blanco después de enviar el pago por su servicio, o puede ocurrir una gran pérdida de paquetes dentro de su red, lo que puede hacer que un simple trabajo de 10 minutos se convierta en un dolor de cabeza de 10 horas.

Lo lógico sería saber exactamente qué pasó y cómo evitar que vuelva a pasar. Sin embargo, esto significa extraer registros de máquinas individuales, agregarlos para encargarse del sesgo del reloj y unirlos a través de algún tipo de identificación de transacción antes de que pueda comenzar a hacer preguntas.

Todo esto bajo la condición de que los registros que debe verificar estén en la memoria de trabajo de la computadora o cuando cat + grep + xargs no sea suficiente para el análisis.

Hoy en día, la mayoría de las infraestructuras de TI se han trasladado a nubes públicas como Servicios web de Amazon, microsoft azure, océano digital, o Nube de Google.

Las herramientas de seguridad de la nube pública y las plataformas de registro se convirtieron en compañeros necesarios para estos servicios. Aunque son herramientas separadas, fueron construidas para trabajar juntas.

Pila de ELK está creada exactamente para tales situaciones.

¿Qué es la pila ELK?

ELK significa:

  • ElasticSearch - Se utiliza para búsquedas profundas y análisis de datos. Es una base de datos NoSQL distribuida de código abierto, construida en Java y basada en Apache Lucene. Lucene se encarga de almacenar los datos del disco, la indexación y el escaneo de documentos, mientras que ElasticSearch mantiene las actualizaciones de documentos, las API y la distribución de documentos entre las instancias de ElasticSearch en el mismo clúster.
  • Logstash: se utiliza para el registro centralizado, el enriquecimiento de registros y el análisis. Es una herramienta ETL (Extraer, Transferir, Cargar) que transforma y almacena registros dentro de ElasticSearch.
  • kibana - Se utiliza para visualizaciones de datos poderosas y hermosas. Es una herramienta basada en web a través de la cual las bases de datos de ElasticSearch visualizan y analizan datos previamente almacenados.

Estas tres herramientas son necesarias para el análisis y visualización de eventos en el sistema.

Análisis de registro

El aislamiento del rendimiento es difícil de alcanzar, especialmente cuando los sistemas están muy cargados. Cada evento relevante dentro de su sistema debe ser registrado. Es mejor exagerar con el registro que no tener información sobre un evento potencialmente problemático.

Un buen "objetivo" para iniciar sesión a nivel de aplicación es todo lo relacionado con cualquier interacción del usuario con el sistema, ya sea la autorización del usuario al sistema o una solicitud del usuario a alguna URL, un correo electrónico enviado al usuario, etc. Dado que registra una variedad de información, este registro no está estructurado en absoluto, pero debe tener información básica para que pueda acceder a él más fácilmente.

El mejor consejo con respecto al inicio de sesión en sistemas distribuidos es "sellar" cualquier evento relevante en la fuente, que se propaga de alguna manera a través del sistema distribuido, ya sea que toque más partes del sistema o no. En el caso de una solicitud de una página web, por ejemplo, un equilibrador de carga o un servidor web se colocaría en dicho "sello". Este evento sellado se transmite más hasta el final de su vida. Estos "sellos" a menudo se realizan como UUID.

Esto garantiza que no se pierda la linealidad del evento y que pueda agrupar y vincular eventos; por ejemplo, puede vincular esa solicitud de página más adelante con la consulta a la base de datos necesaria para que aparezca la página.

Logstash

Cuando el evento se registra en el archivo de registro, entra en juego Logstash. Logstash garantiza que sus entradas se transformen en uno de los formatos de destino admitidos que luego se enviarán al servidor de ElasticSearch.

Recopila datos de diferentes fuentes y luego transmite los datos en forma de canalización de procesamiento de datos a la instancia de ElasticSearch.

Es seguro imaginar a ElasticSearch como una base de datos y a LogStash como el componente de transmisión que envía los registros o archivos a él.

El procesamiento de Logstash se lleva a cabo en tres etapas:

  • Entrada - La entrada, además de un archivo, también puede ser un syslog, redis, o [Leñador](https://github.com/elastic/logstash -forwarder/blob/master/PROTOCOL.md) (ahora logstash-forwarder). Redis se utiliza a menudo como agente de publicación/suscripción en una infraestructura centralizada de Logstash, donde los productores de Logstash envían sus mensajes y una de las instancias los procesa más.
  • Transformación y Filtrado - Esta etapa se realiza de acuerdo al conjunto de reglas previamente definidas, donde además de, por ejemplo, una transformación de formato de fecha, la información de la dirección IP (ciudad/país de la IP) puede ser registrada como bien. La base de datos gratuita MaxMind se utiliza para este propósito.
  • Salida - La salida se puede transformar a través de complementos a casi cualquier formato, en nuestro caso, será ElasticSearch.

Echemos un vistazo a un archivo de configuración de Logstash y un ejemplo de un registro de aplicación:

logstash.conf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
input {
    file {
        path => ["/var/log/myapp/*.log"]
    }
}

filter {
    // Collect or process some data (e.g. 'time') as timestamp and
    // store them into @timestamp data.
    // That data will later be used by Kibana.
        
    date {
        match => [ "time" ]
    }

     // Adds geolocation data based on the IP address.
    geoip {
        source => "ip"
    }
}

output {
    elasticsearch {
       hosts => ["localhost:9200"]
    }
    stdout { codec => rubydebug }
}

Registro de aplicaciones::

1
2
3
4
5
6
7
{
    "action": "action log",
    "user": "John",
    "time": 12:12:2012,
    "ip": "192.168....",
    "transaction-id": "r5e1244-32432-1465-q346-6ahsms57081x4"
}

Búsqueda elástica

En el momento en que Logstash termina su trabajo y reenvía los registros, ElasticSearch ya puede procesar los datos.

Con el simple comando curl curl -XGET 'http://192.168.(host ip):9200/_search' puede ver "documentos" en la base de datos.

192.168.(host ip) es, en este caso, la dirección de máquina virtual boot2docker, y 9200 es el puerto expuesto por defecto.

Dado que el resultado está en formato JSON, sus resultados están listos para su posterior procesamiento. curl -XGET 'http: //192.168.(host ip):9200/_search?hello' devuelve una versión más legible del documento para una inspección rápida. Según el desarrollo, es una práctica común registrar la solicitud/respuesta de la carga útil, el ID de correlación, etc., para que pueda rastrear el error a través del panel de la interfaz de usuario de Kibana más tarde.

Kibana

Kibana es básicamente un cliente de interfaz de usuario estática (HTML + CSS + JS) que muestra los datos de la forma que desea en la instancia de ElasticSearch donde ve diferentes informes y análisis. Excepto que a través de Kibana puede realizar consultas fácilmente sobre los índices de ElasticSearch, la principal ventaja es que para esas consultas, sin importar cuán complicadas puedan ser, puede "arreglarlas" en un "panel de control" muy transparente y eso \ “panel de control" para guardar y compartir con otros.

Kibana viene con un conjunto muy potente de herramientas de visualización y, por ejemplo, puede ver con qué frecuencia se repite un evento similar a lo largo del tiempo, puede agregar eventos de acuerdo con varios criterios (por ejemplo, cuántas solicitudes provienen de una dirección IP en particular en la última hora, si ha aumentado el número de errores en un servidor en particular, o incluso notar un aumento en el número de solicitudes para una página en particular). Además, esta es una gran herramienta para detectar anomalías causadas por cambios en su sistema.

Kibana{.img-responsive}

Probando la pila ELK {#probando la pila del ELK}

Para poder probar la pila ELK y probar algunos de los comandos que estamos a punto de cubrir, deberá instalar ELK y Docker, o boot2docker, localmente.

Estibador es una herramienta diseñada para facilitar la creación, despliegue y ejecución de aplicaciones mediante el uso de contenedores.

Los contenedores permiten a un desarrollador empaquetar una aplicación con todas las partes que necesita, como bibliotecas y otras dependencias, y enviarlo todo como un solo paquete. Este artículo no cubrirá Docker y boot2docker en detalle; los recursos oficiales son más que excelentes y es muy fácil configurar esta combinación.

A los efectos de esta prueba, utilizaremos Imagen acoplable ELK:

1
2
3
4
5
6
7
$ docker pull sebp/elk
$ docker run -p 5601:5601 -p 9200:9200 -p 5000:5000 -it --name elk sebp/elk
$ docker exec -it elk /bin/bash
$ /logstash/bin/logstash -e 'input { stdin { } } output { elasticsearch { host => localhost } }'
# Now write the message e.g.
This is a test message.
CTRL-C

Desde la máquina host, usaremos curl:

1
$ curl -s -XGET 'http://192.168.(host ip):9200/_search?hello&q=message'

El resultado se verá así:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
{
    "took" : 3,
    "timed_out" : false,
    "_shards" : {
        "total" : 6,
        "successful" : 6,
        "failed" : 0
    },
    "hits" : {
        "total" : 1,
        "max_score" : 0.4790727,
        "hits" : [ {
        "_index" : "logstash-2018.08.26",
        "_type" : "logs",
        "_id" : "Z8kCtFYHOWWinjAN6pHUqE",
        "_score" : 0.5720636,
        "_source":{"message":"This is a test message.","@version":"1","@timestamp":"2018-08-26T09:41:17.634Z","host":"5136b631e113"}
        } ]
    }
}

Como puede ver, nuestra búsqueda resultó en 1 instancia de registro que se nos devolvió en formato JSON.

ElasticSearch y pérdida de datos en particiones de red

Al igual que con todas las demás herramientas, ELK Stack viene con su propio conjunto de problemas. Durante el año anterior y este año, se han escrito numerosos artículos sobre cómo ElasticSearch pierde datos debido a la partición de la red, incluso si las condiciones de partición de la red duran solo unos segundos.

Aquí puede encontrar más información sobre cómo se comporta ElasticSearch durante una partición de red transitiva, sin tránsito, como así como en la partición del nodo singular.

Lo que es interesante es que incluso las microparticiones pueden causar un retraso de 90 segundos dentro del cual funciona el nuevo líder dentro del clúster y todo lo que se insertó durante ese clúster puede potencialmente descartarse, por lo que es una buena idea mantener sus registros el formato original y no depender al 100 % de ElasticSearch, incluso para registros de "misión crítica".

Conclusión

Con esto, solo arañamos la superficie y presentamos un conjunto muy pequeño de posibilidades del ELK Stack.

Los problemas resueltos en este artículo son el análisis rápido y sencillo de los registros y la visualización de eventos en el sistema, utilizando una interfaz monolítica que puede servir como base para una mayor instrumentación.

¡Feliz registro!