Nuestro camino hacia el almacenamiento centralizado de registros

Un saludo a todos! Trabajo como ingeniero de sistemas en Onlanta . En uno de nuestros proyectos, participé en la implementación y mantenimiento de Elastic Stack. Pasamos de recolectar registros prácticamente a mano a un proceso centralizado y automatizado. Desde hace dos años, prácticamente no hemos cambiado la arquitectura de la solución y planeamos usar una herramienta conveniente en otros proyectos. Comparto con ustedes nuestra historia de su implementación, así como algunas fortalezas y debilidades en esta publicación.

Fuente

A principios de 2016, los registros de nuestros administradores y desarrolladores eran, por así decirlo, "a su alcance", es decir, un ingeniero para trabajar con ellos conectado a través de SSH al host donde estaba interesado el servicio, descubrió el conjunto universal de tail / grep / sed / awk y esperaba que fuera posible encontrar los datos necesarios en este host.

Fuente

También teníamos un servidor separado, donde todos los directorios con registros de todos los servidores se montaron a través de NFS, y que a veces se pensó durante mucho tiempo sobre lo que todos querían hacer con los registros en él. Bueno, tmux con varios paneles en cola en algunos registros actualizados activamente parecía muy impresionante para los extraños en un monitor grande y creó una atmósfera emocionante de participación en los sacramentos de la producción.

Todo esto incluso funcionó, pero exactamente hasta que fue necesario procesar rápidamente una gran cantidad de datos, y esto se requería con mayor frecuencia en los momentos en que algo había caído en el producto.

A veces tomaba un tiempo indecente investigar los incidentes. Una parte importante se gastó en la agregación manual de registros, lanzando muletas de varios scripts en Bash y Python, esperando que los registros se carguen en algún lugar para su análisis, etc.

En una palabra, todo esto fue muy lento, inspirado por el desánimo e inequívocamente insinuó que era hora de atender el almacenamiento centralizado de troncos.

Para ser sincero, no hubo un proceso complicado de selección de candidatos para el papel de la pila tecnológica que nos garantizaría esto: entonces el paquete ELK ya era popular en ese momento, tenía buena documentación, había una gran cantidad de artículos en Internet para todos los componentes. La decisión fue inmediata: debes intentarlo.

Fuente

La primera instalación de la pila se realizó después de ver el seminario web "Logstash: 0-60 en 60" en tres máquinas virtuales, cada una de las cuales lanzó una instancia de Elasticsearch, Logstash y Kibana.

Además, encontramos algunos problemas con la entrega de registros desde los hosts finales a los servidores Logstash. El hecho es que en ese momento Filebeat (una solución de pila estándar para entregar registros de archivos de texto) funcionaba mucho peor con archivos grandes y actualizados rápidamente, se filtraban regularmente en RAM y en nuestro caso en general no podían hacer frente a su tarea.

A esto se agregó la necesidad de encontrar una manera de entregar registros del servidor de aplicaciones desde máquinas que ejecutan IBM AIX: la mayor parte de nuestras aplicaciones se lanzaron en WebSphere Application Server, que funcionaba específicamente en este sistema operativo. Filebeat está escrito en Go, no hubo un compilador Go más o menos eficiente para AIX en 2016, y realmente no quería usar Logstash como agente para la entrega.

Probamos varios agentes de entrega de registros: Filebeat, logstash-forwarder-java, log-courier , python-beaver y NXLog. De los agentes, esperábamos un alto rendimiento, un bajo consumo de recursos del sistema, una fácil integración con Logstash y la capacidad de realizar manipulaciones básicas de datos con las fuerzas del agente (por ejemplo, el ensamblaje de eventos de varias líneas).

Sobre el montaje de eventos multilínea vale la pena mencionar por separado. Efectivamente, solo se puede ejecutar en el lado del agente que lee un archivo específico. A pesar de que Logstash alguna vez tuvo un filtro multilínea y ahora tiene un códec multilínea, todos nuestros intentos de combinar el equilibrio de eventos en varios servidores Logstash con el procesamiento multilínea fallaron. Esta configuración hace que el equilibrio eficiente de eventos sea casi imposible, por lo tanto, para nosotros, el factor más importante al elegir agentes fue el soporte multilínea.

Los ganadores fueron los siguientes: log-courier para máquinas con Linux, NXLog para máquinas con AIX. Con esta configuración, vivimos casi un año sin ningún problema: se entregaron los registros, los agentes no se cayeron (bueno, casi), todos estaban contentos.

En octubre de 2016, se lanzó la quinta versión de los componentes de Elastic Stack, incluido Beats 5.0. Se realizó un gran trabajo en todos los agentes de Beats en esta versión, y pudimos reemplazar el log-courier (que en ese momento tenía sus propios problemas) con Filebeat, que todavía utilizamos.

Al migrar a la versión 5.0, comenzamos a recopilar no solo registros, sino también algunas métricas: Packetbeat comenzó a usarse aquí y allá como una alternativa para escribir registros de solicitudes HTTP en archivos, y Metricbeat recopiló métricas y métricas del sistema de algunos servicios.

En este punto, el trabajo de nuestros ingenieros con registros se hizo mucho más simple: ahora no había necesidad de saber a qué servidor ir para ver el registro que le interesa, el intercambio de información encontrada se simplificó para simplemente transferir el enlace a Kibana en salas de chat o correo, e informes que se crearon previamente en pocas horas, comenzó a crearse en unos segundos. Esto no puede decirse que fue solo una cuestión de comodidad: notamos cambios en la calidad de nuestro trabajo, en la cantidad y calidad de las tareas cerradas, en la velocidad de respuesta a los problemas en nuestros stands.

En algún momento, comenzamos a usar la utilidad ElastAlert de Yelp para enviar alertas a los ingenieros. Y luego pensamos: ¿por qué no integrarlo con nuestro Zabbix para que todas las alertas tengan un formato estándar y se envíen centralmente? La solución se encontró con bastante rapidez: ElastAlert le permite ejecutar cualquier comando en lugar de enviar alertas, que usamos.

Ahora, nuestras reglas ElastAlert, cuando se activan, ejecutan un script bash en varias líneas, a las cuales se pasan los datos necesarios en los argumentos del evento que activó la regla, y se llama a zabbix_sender desde el script, que envía los datos a Zabbix para el nodo deseado.

Como toda la información sobre quién generó el evento y dónde está siempre disponible en Elasticsearch, no hubo dificultades con la integración. Por ejemplo, anteriormente teníamos un mecanismo para detectar automáticamente los servidores de aplicaciones WAS, y en los eventos que generan, siempre se escribe el nombre del servidor, el clúster, la celda, etc. Esto nos permitió usar la opción query_key en las reglas de ElastAlert para que las condiciones de las reglas se procesen para cada servidor por separado. El script con zabbix_sender obtiene las "coordenadas" exactas del servidor y los datos se envían a Zabbix para el nodo correspondiente.

Otra solución que realmente nos gusta y que fue posible gracias a la colección centralizada de registros es un script para crear tareas automáticamente en JIRA: una vez al día elimina todos los errores de los registros y, si aún no hay tareas, los inicia. Al mismo tiempo, desde diferentes índices mediante un ID de solicitud único, toda la información que puede ser útil en la investigación se pone en marcha. El resultado es una especie de pieza de trabajo estándar con la información mínima necesaria, que luego los ingenieros pueden complementar si es necesario.

Por supuesto, nos enfrentamos con el problema de monitorear la pila en sí. Esto se implementa parcialmente usando Zabbix, parcialmente usando el mismo ElastAlert, y obtenemos las principales métricas de rendimiento para Elasticsearch, Logstash y Kibana usando el monitoreo estándar integrado en la pila (el componente de Monitoreo en el X-Pack). Además, en los servidores con los propios servicios de pila, hemos instalado netdata de Firehol. Es útil cuando necesita ver qué sucede con un nodo en particular en este momento, en tiempo real y con alta resolución.

Érase una vez, el módulo de monitoreo Elasticsearch estaba ligeramente roto, lo encontramos, lo arreglamos, agregamos todo tipo de métricas útiles e hicimos una solicitud de extracción. Así que ahora netdata puede monitorear las últimas versiones de Elasticsearch, incluidas las métricas básicas de JVM, la indexación, los indicadores de rendimiento de búsqueda, las estadísticas del registro de transacciones, los segmentos de índice, etc. Nos gusta Netdata y nos complace haber podido hacer una pequeña contribución.

Hoy, después de casi tres años, nuestra pila elástica se ve así:


Los ingenieros trabajan con la pila de tres formas principales:

• ver y analizar registros y métricas en Kibana;
• tableros de instrumentos en Grafana y Kibana;
• consultas directas a Elasticsearch usando SQL o la consulta incorporada DSL.

En total, se asignan todos estos recursos: 146 CPU, 484 GB de RAM, 17 TB se asignan para el almacén de datos de Elasticsearch.

En total, tenemos 13 máquinas virtuales que funcionan como parte de Elastic Stack: 4 máquinas para nodos Elasticsearch "calientes", 4 para nodos "calientes", 4 máquinas con Logstash y una máquina equilibradora. En cada nodo activo, Elasticsearch ejecuta una instancia de Kibana. Sucedió desde el principio, y hasta ahora no hemos tenido que mover a Kibana para separar los autos.

Pero la decisión de tomar Logstash para separar las máquinas resultó ser una de las más correctas y eficientes durante la operación de apilamiento: la alta competencia por el tiempo de CPU entre JVM Elasticsearch y Logstash provocó efectos especiales no muy agradables durante las ráfagas de carga. Los recolectores de basura fueron los que más sufrieron.

Fuente

Almacenamos datos de los últimos 30 días en el clúster: ahora son unos 12 mil millones de eventos. Diariamente, los nodos activos escriben en el disco de 400-500 GB nuevos datos con una relación de compresión máxima (incluidos los datos de réplica de fragmentos). Nuestro clúster Elasticsearch tiene una arquitectura caliente / cálida, pero lo cambiamos relativamente recientemente, por lo que aún se almacenan menos datos en los nodos "cálidos" que en los "calientes".

Nuestra carga de trabajo típica:

• indexación: en promedio 13,000 rps con picos de hasta 30,000 (excluyendo la indexación en fragmentos de réplica);
• Búsqueda - 5200 rps.

Intentamos mantener un margen de CPU del 40-50% en los nodos activos de Elasticsearch para que podamos experimentar fácilmente picos repentinos en la cantidad de eventos indexados y solicitudes pesadas de Kibana / Grafana o sistemas de monitoreo externos. Alrededor del 50% de la RAM en hosts con nodos Elasticsearch siempre está disponible para las necesidades de caché de página y fuera de montón de JVM.

Durante el tiempo transcurrido desde el lanzamiento del primer clúster, logramos identificar por nosotros mismos algunos de los lados positivos y negativos de Elastic Stack como un medio para agregar registros y una plataforma analítica y de búsqueda.

Lo que nos gusta especialmente de la pila:

• Un ecosistema único de productos bien integrados entre sí, que tiene casi todo lo que necesita. Los Beats alguna vez no fueron muy buenos, pero ahora no tenemos quejas sobre ellos.
• Logstash, con toda su monstruosidad, es un preprocesador muy flexible y potente y le permite hacer mucho con datos sin procesar (y si algo no lo permite, siempre puede escribir un fragmento en Ruby).
• Elasticsearch con complementos (y más recientemente listo para usar) admite SQL como lenguaje de consulta, lo que simplifica su integración con otro software y las personas que están más cerca de SQL como lenguaje de consulta.
• Documentación de alta calidad que le permite presentar rápidamente a los nuevos empleados al proyecto. La operación de la pila, por lo tanto, no se convierte en el negocio de una persona que tiene alguna experiencia específica y "conocimiento secreto".
• No es necesario saber de antemano acerca de la estructura de los datos recibidos para comenzar a recopilarlos: puede comenzar a agregar eventos tal como están, y luego, a medida que comprenda qué información útil puede extraer de ellos, cambie el enfoque para procesarlos sin perder la "compatibilidad con versiones anteriores". Hay muchas herramientas convenientes en la pila para esto: alias de campo en índices, campos con script, etc.

Fuente

Lo que no nos gusta:

• Los componentes de X-Pack se distribuyen solo de acuerdo con el modelo de suscripción y nada más: si desde Gold, por ejemplo, solo se admiten informes RBAC o PDF, tendrá que pagar todo lo que Gold tiene. Esto es especialmente frustrante cuando, por ejemplo, solo necesita Graph de Platinum, y Machine Learning y otro paquete de otras funcionalidades que realmente no necesita están disponibles para su compra. Nuestros intentos de comunicarnos con el departamento de ventas de Elastic sobre la licencia de componentes individuales de X-Pack hace aproximadamente un año no condujeron a nada, pero tal vez algo ha cambiado desde entonces.
• Lanzamientos bastante frecuentes en los que de alguna manera (cada vez que son nuevos) rompen la compatibilidad con versiones anteriores. Debe leer el registro de cambios con mucho cuidado y prepararse para las actualizaciones de antemano. Cada vez que necesite elegir: manténgase en la versión anterior, que funciona de manera estable, o intente actualizar para obtener nuevas características y ganancias de rendimiento.

En general, estamos muy satisfechos con nuestra elección realizada en 2016, y planeamos transferir la experiencia de operar Elastic Stack a nuestros otros proyectos: las herramientas proporcionadas por la pila están muy estrechamente integradas en nuestro flujo de trabajo y sería muy difícil rechazarlas ahora.