Me llamo Anton Baderin. Trabajo en el Centro de Alta Tecnología y me dedico a la administración de sistemas. Hace un mes, nuestra conferencia corporativa terminó, donde compartimos nuestra experiencia con la comunidad de TI de nuestra ciudad. Hablé sobre el monitoreo de aplicaciones web. El material estaba destinado a nivel junior o medio, que no construyó este proceso desde cero.
La piedra angular de cualquier sistema de monitoreo es la solución a los problemas comerciales. Monitorear por el monitoreo no es de interés para nadie. ¿Qué quiere el negocio? Para que todo funcione rápidamente y sin errores. Las empresas quieren proactividad, para que nosotros mismos identifiquemos los problemas en el servicio y los eliminemos lo más rápido posible. De hecho, esta es la tarea que he estado resolviendo todo el año pasado en el proyecto de uno de nuestros clientes.
Sobre el proyecto
El proyecto es uno de los programas de fidelización más grandes del país. Ayudamos a los minoristas a aumentar su frecuencia de ventas a través de diversas herramientas de marketing como tarjetas de bonificación. En total, el proyecto incluye 14 aplicaciones que se ejecutan en diez servidores.
En el proceso de realización de entrevistas, me he dado cuenta repetidamente de que los administradores no siempre son los adecuados para monitorear aplicaciones web: hasta ahora, muchos se detienen en las métricas del sistema operativo y ocasionalmente monitorean los servicios.
En mi caso, Icinga fue la base del sistema de monitoreo de clientes antes. Ella no resolvió los problemas anteriores. A menudo, el propio cliente nos informó de los problemas y, al menos, simplemente no teníamos suficientes datos para llegar al fondo de la razón.
Además, había una comprensión clara de la inutilidad de su desarrollo posterior. Creo que los que están familiarizados con Icinga me entenderán. Entonces, decidimos rediseñar completamente el sistema de monitoreo para aplicaciones web en el proyecto.
Prometeo
Elegimos Prometheus en base a tres indicadores clave:
- Una gran cantidad de métricas disponibles. En nuestro caso, hay 60 mil de ellos. Por supuesto, vale la pena señalar que la gran mayoría de ellos no los usamos (probablemente alrededor del 95%). Por otro lado, todos son relativamente baratos. Para nosotros, este es otro extremo en comparación con el Icinga utilizado anteriormente. En él, agregar métricas era un problema particular: las disponibles eran caras (solo mira el código fuente de cualquier complemento). Cualquier complemento era un script Bash o Python, cuyo lanzamiento no es barato en términos de recursos consumidos.
- Este sistema consume una cantidad relativamente pequeña de recursos. Todas nuestras métricas tienen 600 MB de RAM, 15% de un núcleo y un par de docenas de IOPS. Por supuesto, debe ejecutar exportadores de métricas, pero todas están escritas en Go y tampoco difieren en la gula. No creo que en las realidades modernas esto sea un problema.
- Permite cambiar a Kubernetes. Dados los planes del cliente, la elección es obvia.
ELK
Anteriormente, no recopilamos ni procesamos registros. Los defectos son claros para todos. Elegimos ELK, ya que ya teníamos experiencia con este sistema. Almacenamos solo registros de aplicaciones allí. Los principales criterios de selección fueron la búsqueda de texto completo y su velocidad.
Clickhouse
Inicialmente, la elección recayó en InfluxDB. Reconocimos la necesidad de recopilar registros de Nginx, estadísticas de pg_stat_statements y almacenar datos históricos de Prometheus. No nos gustó Influx, ya que periódicamente comenzó a consumir una gran cantidad de memoria y se bloqueó. Además, quería agrupar las solicitudes por remote_addr y agruparlas en este DBMS solo por etiquetas. Etiquetas de la carretera (memoria), su número es condicionalmente limitado.
Comenzamos la búsqueda de nuevo. Necesitábamos una base analítica con un consumo mínimo de recursos, preferiblemente con compresión de datos en disco.
Clickhouse cumple con todos estos criterios, y nunca nos hemos arrepentido de la elección. No escribimos ninguna cantidad pendiente de datos en él (el número de inserciones es solo de aproximadamente cinco mil por minuto).
NewRelic
Históricamente, NewRelic ha estado con nosotros desde que fue la elección del cliente. Lo usamos como un APM.
Zabbix
Utilizamos Zabbix exclusivamente para monitorear el Black Box de varias API.
Definiendo un enfoque de monitoreo
Queríamos descomponer la tarea y, por lo tanto, sistematizar el enfoque de monitoreo.
Para hacer esto, dividí nuestro sistema en los siguientes niveles:
- Hardware y VMS;
- sistema operativo
- servicios de sistema, pila de software;
- aplicación
- lógica de negocios
Lo que hace que este enfoque sea conveniente:
- sabemos quién es responsable del trabajo de cada uno de los niveles y, en base a esto, podemos enviar alertas;
- podemos usar la estructura al suprimir alertas; sería extraño enviar una alerta sobre la inaccesibilidad de la base de datos cuando la máquina virtual es generalmente inaccesible.
Dado que nuestra tarea es detectar irregularidades en el sistema, debemos seleccionar en cada nivel un determinado conjunto de métricas a las que se debe prestar atención al escribir las reglas de la alerta. A continuación, veremos los niveles de "VMS", "Sistema operativo" y "Servicios del sistema, pila de software".
Máquinas virtuales
El alojamiento nos brinda un procesador, disco, memoria y red. Y con los dos primeros tuvimos problemas. Entonces métricas:
Tiempo robado de la CPU: cuando compra una máquina virtual en Amazon (t2.micro, por ejemplo), debe comprender que no se le asigna un núcleo de procesador completo, sino solo una cuota de su tiempo. Y cuando lo agote, le quitarán el procesador.
Esta métrica le permite rastrear esos momentos y tomar decisiones. Por ejemplo, ¿es necesario tomar un arancel más grueso o distribuir el procesamiento de tareas y solicitudes en segundo plano en la API a diferentes servidores?
IOPS + CPU iowait time: por alguna razón, muchas empresas de alojamiento en la nube pecan al no entregar IOPS. Además, un horario con IOPS bajos no es un argumento para ellos. Por lo tanto, vale la pena recopilar CPU iowait. Con este par de gráficos, con bajas IOPS y altas expectativas de E / S, ya puede hablar con el servidor y resolver el problema.
Sistema operativo
Métrica del sistema operativo:
- cantidad de memoria disponible en%;
- actividad mediante el intercambio: vmstat swapin, swapout;
- la cantidad de inodos disponibles y espacio libre en el sistema de archivos en%
- carga media;
- número de conexiones en estado tw;
- relleno de mesa conntrack;
- el rendimiento de la red se puede monitorear utilizando la utilidad ss, paquete iproute2: obtenga el indicador de conexiones RTT de su salida y agrupe por puerto de destino.
También a nivel del sistema operativo, tenemos una entidad como los procesos. Es importante resaltar en el sistema un conjunto de procesos que juegan un papel importante en su trabajo. Si, por ejemplo, tiene varios pgpool, entonces necesita recopilar información para cada uno de ellos.
El conjunto de métricas es el siguiente:
- CPU
- la memoria es principalmente residente;
- IO - preferiblemente en IOPS;
- FileFd: abrir y limitar;
- fallas de página importantes, para que pueda comprender qué proceso está intercambiando.
Toda la supervisión se implementa en Docker, utilizamos advisor para recopilar datos métricos. En otras máquinas, utilizamos proceso-exportador.
Servicios del sistema, pila de software
Cada aplicación tiene sus propios detalles, y es difícil distinguir algún conjunto de métricas.
Conjunto universal son:
- tasa de solicitud;
- número de errores;
- latencia
- saturación
Los ejemplos más llamativos de monitoreo en este nivel son Nginx y PostgreSQL.
El servicio más cargado en nuestro sistema es la base de datos. Solíamos tener problemas con bastante frecuencia para descubrir qué hace la base de datos.
Vimos una gran carga en los discos, pero las consignas realmente no mostraban nada. Resolvimos este problema con pg_stat_statements, una vista que recopila estadísticas sobre las solicitudes.
Esto es todo lo que el administrador necesita.
Trazamos la actividad de las solicitudes de lectura y escritura:
Todo es simple y claro, cada solicitud tiene su propio color.
Un ejemplo igualmente sorprendente son los registros de Nginx. No es sorprendente que pocos los analicen o los mencionen en la lista de los requeridos. El formato estándar no es muy informativo y debe ampliarse.
Personalmente, agregué request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Trazamos el tiempo de respuesta y la cantidad de errores:
Trazamos el tiempo de respuesta y la cantidad de errores. ¿Te acuerdas? ¿Hablé sobre objetivos comerciales? Para rápidamente y sin errores? Ya hemos cerrado estos problemas con dos gráficos. Y en ellos ya puedes llamar a los administradores de turno.
Pero quedaba otro problema: garantizar la rápida eliminación de las causas del incidente.
Gestión de incidentes
Todo el proceso, desde la identificación hasta la resolución de un problema, se puede dividir en varios pasos:
- identificación del problema;
- notificación del administrador de turno;
- reacción al incidente;
- eliminación de las causas.
Es importante que hagamos esto lo más rápido posible. Y si no podemos ganar mucho tiempo en las etapas de identificar un problema y enviar una notificación, en cualquier caso, se irán durante dos minutos, luego los siguientes son solo un campo intacto para mejoras.
Imaginemos que el teléfono sonó de guardia. ¿Qué va a hacer él? Busque respuestas a las preguntas: ¿qué está roto, dónde está roto, cómo reaccionar? Así es como respondemos estas preguntas:
Simplemente incluimos toda esta información en el texto de notificación, le damos un enlace a una página wiki que describe cómo responder a este problema, cómo resolverlo y escalarlo.
Todavía no he dicho nada sobre la capa de aplicación y la lógica empresarial. Desafortunadamente, la recopilación de métricas aún no se ha implementado en nuestras aplicaciones. La única fuente de al menos algo de información de estos niveles son los registros.
Un par de puntos
Primero, escriba registros estructurados. No es necesario incluir contexto en el cuerpo del mensaje. Esto hace que sea difícil agruparlos y analizarlos. Logstash tarda mucho tiempo en normalizar todo esto.
En segundo lugar, use los niveles de gravedad correctamente. Cada idioma tiene su propio estándar. Personalmente, distingo cuatro niveles:
- sin error
- error del lado del cliente;
- un error está de nuestro lado, no perdemos dinero, no corremos riesgos;
- El error está de nuestro lado, estamos perdiendo dinero.
Resumo Es necesario tratar de construir un monitoreo precisamente desde la lógica del negocio. Intente monitorear la aplicación en sí misma y opere con métricas como el número de ventas, el número de nuevos registros de usuarios, el número de usuarios actualmente activos, etc.
Si toda su empresa es un solo botón en su navegador, debe controlar si se está presionando y si funciona correctamente. Todo lo demás no es importante.
Si no tiene esto, puede intentar ponerse al día en los registros de la aplicación, los registros de Nginx, etc., como lo hicimos nosotros. Debe estar lo más cerca posible de la aplicación.
Las métricas del sistema operativo son, por supuesto, importantes, pero no son interesantes para los negocios, no se nos paga por ellas.