Mi nombre es Antón Baderin. Trabajo en el Centro de Alta Tecnología y hago administración de sistemas. Hace un mes finalizó nuestra conferencia corporativa, donde compartimos nuestra experiencia acumulada con la comunidad TI de nuestra ciudad. Hablé de monitorear aplicaciones web. El material estaba destinado a niveles junior o medio, que no construyeron este proceso desde cero.
La piedra angular de cualquier sistema de seguimiento es la resolución de problemas empresariales. El seguimiento por el seguimiento no interesa a nadie. ¿Qué quieren las empresas? Para que todo funcione rápido y sin errores. Las empresas quieren ser proactivas, para que nosotros mismos identifiquemos los problemas en el servicio y los solucionemos lo más rápido posible. Estos, de hecho, son los problemas que resolví durante todo el año pasado en un proyecto para 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 las cadenas minoristas a aumentar la frecuencia de las ventas a través de diversas herramientas de marketing, como las tarjetas de bonificación. En total, el proyecto incluye 14 aplicaciones que se ejecutan en diez servidores.
Durante el proceso de entrevista, noté repetidamente que los administradores no siempre abordan correctamente el monitoreo de aplicaciones web: muchos todavía se enfocan en las métricas del sistema operativo y ocasionalmente monitorean los servicios.
En mi caso, el sistema de seguimiento del cliente anteriormente estaba basado en Icinga. No resolvió los problemas anteriores de ninguna manera. A menudo, el propio cliente nos informaba sobre los problemas y, en la mayoría de los casos, simplemente no teníamos datos suficientes para llegar al fondo del motivo.
Además, se comprendió claramente la inutilidad de su desarrollo posterior. Creo que los que conocen Icinga me entenderán. Entonces, decidimos rediseñar completamente el sistema de monitoreo de aplicaciones web para el proyecto.
Prometeo
Elegimos Prometheus basándonos en tres indicadores principales:
- Una gran cantidad de métricas disponibles. En nuestro caso son 60 mil. Por supuesto, vale la pena señalar que no utilizamos la gran mayoría de ellos (probablemente alrededor del 95%). Por otro lado, todos son relativamente baratos. Para nosotros, este es el otro extremo en comparación con el Icinga utilizado anteriormente. En él, agregar métricas fue particularmente complicado: las existentes eran costosas (basta con mirar el código fuente de cualquier complemento). Cualquier complemento era un script en Bash o Python, cuyo lanzamiento es costoso en términos de recursos consumidos.
- Este sistema consume una cantidad relativamente pequeña de recursos. 600 MB de RAM, el 15% de un núcleo y un par de docenas de IOPS son suficientes para todas nuestras métricas. Por supuesto, hay que ejecutar exportadores de métricas, pero todos están escritos en Go y tampoco consumen mucha energía. No creo que en las realidades modernas esto sea un problema.
- Proporciona la posibilidad de migrar a Kubernetes. Teniendo en cuenta los planes del cliente, la elección es obvia.
ALCE
Anteriormente, no recopilamos ni procesamos registros. Las deficiencias son claras para todos. Elegimos ELK porque ya teníamos experiencia con este sistema. Allí solo almacenamos registros de aplicaciones. Los principales criterios de selección fueron la búsqueda de texto completo y su velocidad.
Casa de clics
Inicialmente, la elección recayó en InfluxDB. Nos dimos cuenta de la necesidad de recopilar registros de Nginx, estadísticas de pg_stat_statements y almacenar datos históricos de Prometheus. No nos gustó Influx porque periódicamente comenzaba a consumir una gran cantidad de memoria y fallaba. Además, quería agrupar consultas por remote_addr, pero en este DBMS la agrupación es solo por etiquetas. Las etiquetas son caras (memoria), su número es limitado.
Comenzamos nuestra búsqueda nuevamente. Lo que se necesitaba era una base de datos analítica con un consumo mínimo de recursos, preferiblemente con compresión de datos en disco.
Clickhouse cumple todos estos criterios y nunca nos hemos arrepentido de nuestra elección. No escribimos cantidades extraordinarias de datos en él (el número de inserciones es sólo de unas cinco mil por minuto).
NewRelic
NewRelic históricamente ha estado con nosotros porque fue elección del cliente. Lo usamos como APM.
Zabbix
Usamos Zabbix exclusivamente para monitorear la Caja Negra de varias API.
Definición de un enfoque de seguimiento
Queríamos descomponer la tarea y así sistematizar el enfoque del seguimiento.
Para hacer esto, dividí nuestro sistema en los siguientes niveles:
- hardware y VMS;
- Sistema operativo;
- servicios de sistema, pila de software;
- solicitud;
- lógica de negocios.
Por qué este enfoque es conveniente:
- sabemos quién es el responsable del trabajo de cada nivel y, en base a ello, podemos enviar alertas;
- podemos usar la estructura al suprimir alertas; sería extraño enviar una alerta sobre la indisponibilidad de la base de datos cuando la máquina virtual en su conjunto no está disponible.
Dado que nuestra tarea es identificar violaciones en el funcionamiento del sistema, en cada nivel debemos resaltar un cierto conjunto de métricas a las que vale la pena prestar atención al escribir reglas de alerta. A continuación, repasemos los niveles "VMS", "Sistema operativo" y "Servicios del sistema, pila de software".
Maquinas virtuales
El hosting nos asigna procesador, disco, memoria y red. Y tuvimos problemas con los dos primeros. Entonces, las métricas:
Tiempo de CPU robado: cuando compras una máquina virtual en Amazon (t2.micro, por ejemplo), debes comprender que no se te asigna un núcleo de procesador completo, sino solo una cuota de su tiempo. Y cuando lo agotes, te quitarán el procesador.
Esta métrica le permite realizar un seguimiento de esos momentos y tomar decisiones. Por ejemplo, ¿es necesario aceptar una tarifa más alta o distribuir el procesamiento de tareas en segundo plano y solicitudes de API a diferentes servidores?
IOPS + tiempo de espera de CPU: por alguna razón, muchos alojamientos en la nube pecan al no proporcionar suficientes IOPS. Además, un horario con IOPS bajos no es un argumento para ellos. Por lo tanto, vale la pena recolectar CPU iowait. Con este par de gráficas - con IOPS bajos y espera de E/S alta - ya puedes hablar con el hosting y solucionar el problema.
Sistema operativo
Métricas del sistema operativo:
- cantidad de memoria disponible en %;
- actividad de uso de intercambio: vmstat swapin, swapout;
- Número de inodos disponibles y espacio libre en el sistema de archivos en %.
- carga promedio;
- número de conexiones en dos estados;
- plenitud de la mesa de control;
- La calidad de la red se puede monitorear usando la utilidad ss, el paquete iproute2: obtenga un indicador de conexiones RTT de su salida y agrúpelo por puerto de destino.
También a nivel del sistema operativo tenemos entidades como procesos. Es importante identificar en el sistema un conjunto de procesos que juegan un papel importante en su funcionamiento. Si, por ejemplo, tiene varios pgpools, deberá recopilar información para cada uno de ellos.
El conjunto de métricas es el siguiente:
- UPC;
- la memoria es principalmente residente;
- IO - preferiblemente en IOPS;
- FileFd: abrir y limitar;
- Fallos importantes de página: de esta manera podrá comprender qué proceso se está intercambiando.
Implementamos todo el monitoreo en Docker y utilizamos Advisor para recopilar datos de métricas. En otras máquinas utilizamos Process-Exporter.
Servicios del sistema, pila de software.
Cada aplicación tiene sus propias particularidades y es difícil señalar un conjunto específico de métricas.
El conjunto universal es:
- tasa de solicitud;
- número de errores;
- latencia;
- saturación.
Nuestros ejemplos más llamativos de monitorización a este nivel son Nginx y PostgreSQL.
El servicio más cargado en nuestro sistema es la base de datos. En el pasado, a menudo teníamos problemas para saber qué estaba haciendo la base de datos.
Vimos una carga elevada en los discos, pero los registros lentos realmente no mostraron nada. Resolvimos este problema usando pg_stat_statements, una vista que recopila estadísticas de consultas.
Eso es todo lo que necesita el administrador.
Construimos gráficos de la actividad de solicitudes de lectura y escritura:
Todo es sencillo y claro, cada petición tiene su propio color.
Un ejemplo igualmente sorprendente son los registros de Nginx. No es de extrañar que pocas personas los analicen o los mencionen en la lista de imprescindibles. El formato estándar no es muy informativo y es necesario ampliarlo.
Personalmente, agregué request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Trazamos el tiempo de respuesta y la cantidad de errores:
Construimos gráficos de tiempo de respuesta y número de errores. ¿Recordar? ¿Hablé de objetivos comerciales? ¿De forma rápida y sin errores? Ya hemos cubierto estos temas con dos gráficos. Y ya puedes llamar a los administradores de turno usándolos.
Pero aún queda un problema: garantizar la rápida eliminación de las causas del incidente.
Resolución de incidentes
Todo el proceso, desde la identificación hasta la solución de un problema, se puede dividir en varios pasos:
- identificando el problema;
- notificación al administrador de turno;
- respuesta a un incidente;
- eliminación de causas.
Es importante que hagamos esto lo más rápido posible. Y si en las etapas de identificación de un problema y envío de una notificación no podemos ganar mucho tiempo (en cualquier caso, se dedicarán dos minutos a ellas), las siguientes simplemente son un campo sin explorar para mejorar.
Imaginemos que sonó el teléfono del oficial de guardia. ¿Que hará el? Busque respuestas a preguntas: ¿qué se rompió, dónde se rompió, cómo reaccionar? Así es como respondemos estas preguntas:
Simplemente incluimos toda esta información en el texto de la 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. Lamentablemente, nuestras aplicaciones aún no implementan la recopilación de métricas. La única fuente de información de estos niveles son los registros.
Un par de puntos.
Primero, escriba registros estructurados. No es necesario incluir contexto en el texto del mensaje. Esto los hace difíciles de agrupar y analizar. Logstash tarda mucho en normalizar todo esto.
En segundo lugar, utilice los niveles de gravedad correctamente. Cada idioma tiene su propio estándar. Personalmente distingo cuatro niveles:
- No hay error;
- error del lado del cliente;
- el error está de nuestro lado, no perdemos dinero, no asumimos riesgos;
- El error está de nuestro lado, perdemos dinero.
Déjame resumir. Debe intentar crear un seguimiento basado en la lógica empresarial. Intente monitorear la aplicación en sí y opere con métricas como la cantidad de ventas, la cantidad de registros de nuevos usuarios, la cantidad de usuarios activos actualmente, etc.
Si todo su negocio es un botón en el navegador, debe controlar si hace clic y funciona correctamente. Todo lo demás no importa.
Si no lo tiene, puede intentar actualizarlo en los registros de la aplicación, los registros de Nginx, etc., como lo hicimos nosotros. Debes estar lo más cerca posible de la aplicación.
Las métricas del sistema operativo son, por supuesto, importantes, pero a las empresas no les interesan, no nos pagan por ellas.
Fuente: habr.com