Este artículo presenta principalmente cómo usar ELK Stack para ayudarnos a construir un sistema de monitoreo de registros que admita el nivel de TB de Nissan. Mucho conocimiento detallado, un artículo no es suficiente, este artículo presenta principalmente los puntos de conocimiento básicos.
En un entorno de microservicios de nivel empresarial, ejecutar cientos de servicios se considera una escala relativamente pequeña. En el entorno de producción, los registros juegan un papel muy importante. Los registros son necesarios para solucionar problemas de excepciones, los registros son necesarios para la optimización del rendimiento y los servicios son necesarios para la resolución de problemas comerciales. Sin embargo, hay cientos de servicios que se ejecutan en producción, y cada servicio simplemente se localiza y almacena.Cuando se necesitan registros para ayudar a solucionar problemas, es difícil encontrar el nodo donde se ubican los registros. También es difícil extraer el valor de los datos de los registros comerciales. Luego, la salida unificada de los registros a un lugar para la administración centralizada, y luego el procesamiento de los registros y la salida de los resultados en datos disponibles para operación y mantenimiento, investigación y desarrollo, es una solución factible para la administración de registros y asistencia en la operación y mantenimiento, y también es una necesidad urgente que las empresas resuelvan el registro.
Nuestra solución
Con base en los requisitos anteriores, lanzamos un sistema de monitoreo de registros, como se muestra en la figura anterior:
- Los troncos se recolectan, filtran y limpian de manera uniforme.
- Genere interfaz visual, monitoreo, alarma, búsqueda de registros.
Una descripción general del proceso funcional se muestra arriba:
- Entierre puntos en cada nodo de servicio y recopile registros relevantes en tiempo real.
- Después del servicio unificado de recopilación de registros, filtrado y limpieza de registros, se generan una interfaz visual y una función de alarma.
Nuestra arquitectura
①Utilizamos FileBeat para el terminal de recolección de archivos de registro. La operación y el mantenimiento se configuran a través de nuestra interfaz de administración de back-end. Cada máquina corresponde a un FileBeat. El tema correspondiente a cada registro de FileBeat puede ser uno a uno o muchos a uno, según la configuración diaria del volumen de registro Diferentes estrategias.
Además de recopilar registros de servicios comerciales, también recopilamos registros de consultas lentas y registros de errores de MySQL, así como otros registros de servicios de terceros, como Nginx.
Finalmente, combinado con nuestra plataforma de publicación automatizada, publique e inicie automáticamente cada proceso FileBeat.
②El método proxy que usamos para los indicadores de seguimiento de procesos, enlaces y pila de llamadas: Elastic APM, de modo que no hay necesidad de cambiar el programa en el lado comercial.
Para un sistema empresarial que ya está en funcionamiento, es indeseable e inaceptable cambiar el código para unirse al monitoreo.
Elastic APM puede ayudarnos a recopilar enlaces de llamadas de interfaz HTTP, pilas de llamadas de métodos internos, SQL usado, CPU de proceso, indicadores de uso de memoria, etc.
Algunas personas pueden tener preguntas. Con Elastic APM, básicamente se pueden recopilar otros registros. ¿Por qué utilizar FileBeat?
Sí, la información recopilada por Elastic APM puede ayudarnos a localizar más del 80% de los problemas, pero no es compatible con todos los lenguajes como C.
En segundo lugar, no puede ayudarlo a recopilar los registros sin errores y los llamados registros críticos que desea, como: se produjo un error cuando se llamó a una interfaz y desea ver los registros antes y después del tiempo del error; también hay negocios de impresión relacionados para facilitar el análisis Iniciar sesión.
En tercer lugar, las excepciones comerciales personalizadas, que no son excepciones del sistema y pertenecen a la categoría comercial. APM informará dichas excepciones como excepciones del sistema.
Si advierte sobre anomalías del sistema más adelante, estas anomalías interferirán con la precisión de la alarma y no podrá filtrar las excepciones comerciales porque existen muchos tipos de excepciones comerciales personalizadas.
③Al mismo tiempo, abrimos el Agente dos veces. Recopile información más detallada de GC, pila, memoria y subprocesos.
④Utilizamos Prometheus para la colección de servidores.
⑤Dado que estamos orientados al servicio Saas, hay muchos servicios y muchos registros de servicio no se pueden unificar y estandarizar. Esto también está relacionado con problemas históricos. Un sistema que no tiene nada que ver con los sistemas comerciales se conecta directa o indirectamente con los sistemas comerciales existentes. Si deja que cambie el código para adaptarse a usted mismo, no se puede presionar.
El increíble diseño es permitirte ser compatible con los demás y tratar a la otra parte como un objeto de ataque. Muchos registros no tienen sentido. Por ejemplo, en el proceso de desarrollo, para facilitar la resolución de problemas y el seguimiento de problemas, imprimir if else es solo un registro de firma, que representa si el bloque de código if o el bloque de código else se ha ido.
Algunos servicios incluso imprimen registros de nivel de depuración. Bajo las limitadas condiciones de costo y recursos, todos los registros son poco realistas, incluso si los recursos lo permiten, será un gran gasto en un año.
Por lo tanto, adoptamos soluciones como el filtrado, la limpieza y el ajuste dinámico de la recopilación de prioridad de registros. Primero, recopile todos los registros en el clúster de Kafka y establezca un período de validez breve.
Actualmente establecemos un volumen de datos de una hora, una hora y nuestros recursos siguen siendo aceptables por el momento.
⑥ Log Streams es nuestro servicio de procesamiento de flujos para filtrado y limpieza de registros. ¿Por qué necesitamos filtros ETL?
Debido a que nuestro servicio de registro tiene recursos limitados, no es correcto. Los registros originales están dispersos en los medios de almacenamiento locales de cada servicio, lo que también requiere recursos.
Ahora solo lo estamos recopilando. Después de recopilarlo, los recursos originales de cada servicio pueden liberar parte de los recursos ocupados por el registro.
Así es, este cálculo realmente divide la asignación de recursos de los servicios originales en los recursos del servicio de registro y no aumenta los recursos.
Sin embargo, esto es solo teórico. Con los servicios en línea, los recursos son fáciles de expandir, pero la reducción no es tan fácil. Es extremadamente difícil de implementar.
Por lo tanto, es imposible asignar los recursos de registro utilizados en cada servicio al servicio de registro en poco tiempo. En este caso, el recurso del servicio de registro es la cantidad de recursos que utilizan todos los registros de servicio actuales.
Cuanto mayor sea el tiempo de almacenamiento, mayor será el consumo de recursos. Si el costo de resolver un problema no comercial o indispensable es mayor que los beneficios de resolver el problema actual en poco tiempo, creo que con fondos limitados, ningún líder o empresa está dispuesta a adoptar una solución.
Por lo tanto, desde la perspectiva del costo, hemos introducido filtros en el servicio Log Streams para filtrar los datos de registro que no tienen valor, reduciendo así el costo de los recursos utilizados por el servicio de registro.
Tecnología Usamos Kafka Streams como procesamiento de flujo ETL. Realice el filtrado dinámico y las reglas de limpieza mediante la configuración de la interfaz.
Las reglas generales son las siguientes:
- Recopilación de registros de configuración basada en interfaz. Se recopilan todos los registros del nivel de error predeterminado.
- Tome el tiempo de error como el centro, abra una ventana en el procesamiento de la transmisión y recopile registros que no sean de nivel de error en N puntos de tiempo que se pueden configurar hacia arriba y hacia abajo. De forma predeterminada, solo se usa el nivel de información.
- Cada servicio puede estar equipado con 100 registros de claves, y todos los registros de claves se recopilan de forma predeterminada.
- Sobre la base de SQL lento, configure diferentes filtros que consumen mucho tiempo de acuerdo con la clasificación empresarial.
- Estadísticas en tiempo real de SQL comercial de acuerdo con las necesidades comerciales, tales como: durante el período pico, estadísticas de la frecuencia de consulta de SQL comercial similar en una hora. Puede proporcionar al DBA una base para optimizar la base de datos, como crear un índice basado en la consulta SQL.
- Durante las horas pico, los registros se limpian y filtran dinámicamente de acuerdo con el índice de peso del tipo de negocio, el índice de nivel de registro, el índice de límite de registro máximo de cada servicio en un período de tiempo y el índice de período de tiempo.
- Reduzca dinámicamente la ventana de tiempo de acuerdo con diferentes períodos de tiempo.
- Reglas de generación del índice de registro: genere el índice correspondiente de acuerdo con las reglas del archivo de registro generadas por el servicio, por ejemplo: un registro de servicio se divide en: debug, info, error, xx_keyword, luego el índice generado también es debug, info, error, xx_keyword más fecha como sufijo . El propósito de esto es usar los registros habitualmente para investigación y desarrollo.
⑦Interfaz de visualización Usamos principalmente Grafana. Entre las muchas fuentes de datos que admite, están Prometheus y Elasticsearch, que se pueden describir como un acoplamiento perfecto con Prometheus. Utilizamos principalmente Kibana para el análisis visual de APM.
Visualización de registros
Nuestra visualización de registros es la siguiente:
