Chámome Anton Baderin. Traballo no Centro de Alta Tecnoloxía e fago administración de sistemas. Hai un mes rematou a nosa conferencia corporativa, onde compartimos a nosa experiencia acumulada coa comunidade informática da nosa cidade. Falei sobre a vixilancia de aplicacións web. O material estaba destinado a nivel júnior ou medio, que non construíu este proceso desde cero.
A pedra angular subxacente a calquera sistema de vixilancia é resolver os problemas empresariais. O seguimento en aras da vixilancia non interesa a ninguén. Que quere o negocio? Para que todo funcione rapidamente e sen erros. As empresas queren ser proactivas, para que nós mesmos identifiquemos os problemas no servizo e solucionalos o máis rápido posible. Estes, de feito, son os problemas que resolvín todo o ano pasado nun proxecto para un dos nosos clientes.
Sobre o proxecto
O proxecto é un dos maiores programas de fidelización do país. Axudamos ás cadeas de venda polo miúdo a aumentar a frecuencia das vendas a través de varias ferramentas de mercadotecnia, como tarxetas de bonificación. En total, o proxecto inclúe 14 aplicacións que se executan en dez servidores.
Durante o proceso de entrevista, notei varias veces que os administradores non sempre abordan correctamente as aplicacións web de seguimento: moitos aínda se centran nas métricas do sistema operativo e, ocasionalmente, supervisan os servizos.
No meu caso, o sistema de seguimento do cliente baseábase anteriormente en Icinga. Non resolveu os problemas anteriores de ningún xeito. Moitas veces, o propio cliente nos informou sobre os problemas e, a maioría das veces, simplemente non tiñamos datos suficientes para chegar ao fondo da razón.
Ademais, había unha clara comprensión da inutilidade do seu posterior desenvolvemento. Creo que os que están familiarizados con Icinga me entenderán. Entón, decidimos redeseñar completamente o sistema de seguimento da aplicación web para o proxecto.
Prometeu
Escollemos Prometheus en función de tres indicadores principais:
- Un gran número de métricas dispoñibles. No noso caso son 60 mil. Por suposto, cómpre sinalar que non utilizamos a gran maioría deles (probablemente un 95%). Por outra banda, todos son relativamente baratos. Para nós, este é o outro extremo en comparación co Icinga usado anteriormente. Nel, engadir métricas era unha dor particular: as existentes eran caras (basta mirar o código fonte de calquera complemento). Calquera complemento era un script en Bash ou Python, cuxo lanzamento é caro en termos de recursos consumidos.
- Este sistema consome unha cantidade relativamente pequena de recursos. 600 MB de RAM, 15% dun núcleo e un par de ducias de IOPS son suficientes para todas as nosas métricas. Por suposto, tes que executar exportadores de métricas, pero todos están escritos en Go e tampouco teñen moita enerxía. Non creo que nas realidades modernas isto sexa un problema.
- Ofrece a posibilidade de migrar a Kubernetes. Tendo en conta os plans do cliente, a elección é obvia.
ELK
Anteriormente, non recompilabamos nin procesabamos rexistros. As carencias están claras para todos. Escollemos ELK porque xa tiñamos experiencia con este sistema. Só almacenamos alí os rexistros das aplicacións. Os principais criterios de selección foron a busca de texto completo e a súa velocidade.
Сlickhouse
Inicialmente, a elección recaeu en InfluxDB. Démonos conta da necesidade de recoller rexistros de Nginx, estatísticas de pg_stat_statements e almacenar datos históricos de Prometheus. Non nos gustou Influx porque periódicamente comezaba a consumir unha gran cantidade de memoria e fallaba. Ademais, quería agrupar as consultas por remote_addr, pero a agrupación neste DBMS é só por etiquetas. As etiquetas son caras (memoria), o seu número é limitado condicionalmente.
Comezamos de novo a nosa busca. O que se necesitaba era unha base de datos analítica cun consumo mínimo de recursos, preferentemente con compresión de datos en disco.
Clickhouse cumpre con todos estes criterios e nunca nos arrepentimos da nosa elección. Non escribimos cantidades extraordinarias de datos nel (o número de insercións é de só cinco mil por minuto).
Nova reliquia
NewRelic estivo historicamente connosco porque foi a elección do cliente. Usámolo como APM.
Zabbix
Usamos Zabbix exclusivamente para supervisar a caixa negra de varias API.
Definición dun enfoque de seguimento
Queriamos descompoñer a tarefa e sistematizar así o enfoque do seguimento.
Para iso, dividín o noso sistema nos seguintes niveis:
- hardware e VMS;
- sistema operativo;
- servizos do sistema, pila de software;
- aplicación;
- lóxica empresarial.
Por que este enfoque é conveniente:
- sabemos quen é o responsable do traballo de cada nivel e, en función diso, podemos enviar alertas;
- podemos usar a estrutura ao suprimir alertas; sería estraño enviar unha alerta sobre a non dispoñibilidade da base de datos cando a máquina virtual no seu conxunto non está dispoñible.
Dado que a nosa tarefa é identificar infraccións no funcionamento do sistema, debemos destacar en cada nivel un determinado conxunto de métricas ás que paga a pena prestar atención ao escribir regras de alerta. A continuación, imos pasar polos niveis "VMS", "Sistema operativo" e "Servizos do sistema, pila de software".
Máquinas virtuais
O aloxamento atribúenos un procesador, disco, memoria e rede. E tivemos problemas cos dous primeiros. Entón, as métricas:
Tempo roubado da CPU: cando compras unha máquina virtual en Amazon (t2.micro, por exemplo), debes entender que non se lle asigna un núcleo de procesador completo, senón só unha cota do seu tempo. E cando o esgotes, quitaráche o procesador.
Esta métrica permítelle facer un seguimento destes momentos e tomar decisións. Por exemplo, é necesario levar unha tarifa máis gorda ou distribuír o procesamento de tarefas en segundo plano e solicitudes de API a distintos servidores?
IOPS + CPU iowait time - por algún motivo, moitos hospedaxes na nube pecan ao non proporcionar suficientes IOPS. Ademais, unha programación con baixo IOPS non é un argumento para eles. Polo tanto, paga a pena recoller CPU iowait. Con este par de gráficos, con baixos IOPS e alta espera de E/S, xa podes falar co hospedador e resolver o problema.
Sistema operativo
Métricas do sistema operativo:
- cantidade de memoria dispoñible en %;
- actividade de uso de intercambio: vmstat swapin, swapout;
- número de inodos dispoñibles e espazo libre no sistema de ficheiros en %
- carga media;
- número de conexións en dous estados;
- cheo da táboa conttrack;
- A calidade da rede pódese supervisar mediante a utilidade ss, o paquete iproute2: obtén un indicador das conexións RTT da súa saída e agrúpao por porto dest.
Tamén a nivel de sistema operativo temos unha entidade como os procesos. É importante identificar no sistema un conxunto de procesos que desempeñan un papel importante no seu funcionamento. Se, por exemplo, tes varios pgpools, entón tes que recompilar información para cada un deles.
O conxunto de métricas é o seguinte:
- CPUs;
- a memoria é principalmente residente;
- IO - preferiblemente en IOPS;
- FileFd - abrir e limitar;
- erros significativos da páxina: deste xeito pode entender que proceso se está a intercambiar.
Implementamos toda a supervisión en Docker e usamos Advisor para recoller datos de métricas. Noutras máquinas usamos proceso-exportador.
Servizos do sistema, pila de software
Cada aplicación ten as súas propias características específicas e é difícil sinalar un conxunto específico de métricas.
O conxunto universal é:
- taxa de solicitude;
- número de erros;
- latencia;
- saturación.
Os nosos exemplos máis rechamantes de seguimento a este nivel son Nginx e PostgreSQL.
O servizo máis cargado do noso sistema é a base de datos. No pasado, moitas veces tiñamos problemas para descubrir o que facía a base de datos.
Vimos unha gran carga nos discos, pero os rexistros lentos non mostraban nada. Resolvemos este problema mediante pg_stat_statements, unha vista que recolle estatísticas de consulta.
Iso é todo o que necesita o administrador.
Elaboramos gráficas da actividade de solicitudes de lectura e escritura:
Todo é sinxelo e claro, cada solicitude ten a súa propia cor.
Un exemplo igualmente sorprendente son os rexistros de Nginx. Non é de estrañar que pouca xente os analice ou os mencione na lista de imprescindibles. O formato estándar non é moi informativo e cómpre ampliar.
Persoalmente, engadín request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Trazamos o tempo de resposta e o número de erros:
Construímos gráficos de tempo de resposta e número de erros. Lembras? Falei de tarefas empresariais? Para rapidamente e sen erros? Xa cubrimos estas cuestións con dous gráficos. E xa podes chamar aos administradores de garda usándoas.
Pero queda un problema máis: garantir a rápida eliminación das causas do incidente.
Resolución de incidencias
Todo o proceso desde a identificación ata a resolución dun problema pódese dividir en varias etapas:
- identificar o problema;
- notificación ao administrador de funcións;
- resposta a un incidente;
- eliminación de causas.
É importante que debemos facelo o máis rápido posible. E se nas fases de identificación dun problema e envío dunha notificación non podemos gañar moito tempo, en calquera caso dedicaranse dous minutos, entón os seguintes son simplemente un campo sen arar para mellorar.
Imaxinemos que soou o teléfono do oficial de servizo. Que fará? Busca respostas ás preguntas: que se rompeu, onde se rompeu, como reaccionar? Así é como respondemos a estas preguntas:
Simplemente incluímos toda esta información no texto da notificación, dámoslle unha ligazón a unha páxina wiki que describe como responder a este problema, como resolvelo e escalalo.
Aínda non dixen nada sobre a capa de aplicación e a lóxica empresarial. Desafortunadamente, as nosas aplicacións aínda non implementan a recollida de métricas. A única fonte de información destes niveis son os rexistros.
Un par de puntos.
En primeiro lugar, escriba rexistros estruturados. Non é necesario incluír contexto no texto da mensaxe. Isto dificulta a súa agrupación e análise. Logstash leva moito tempo normalizar todo isto.
En segundo lugar, use os niveis de gravidade correctamente. Cada lingua ten o seu propio estándar. Persoalmente, distingo catro niveis:
- sen erro;
- erro do lado do cliente;
- o erro está da nosa parte, non perdemos cartos, non corremos riscos;
- O erro está da nosa parte, perdemos cartos.
Permíteme resumir. Debe tentar construír un seguimento baseado na lóxica empresarial. Intente supervisar a propia aplicación e operar con métricas como o número de vendas, o número de rexistros de novos usuarios, o número de usuarios activos actualmente, etc.
Se toda a túa empresa é un botón do navegador, debes controlar se fai clic e funciona correctamente. Todo o resto non importa.
Se non tes isto, podes tentar poñerte ao día nos rexistros de aplicacións, rexistros de Nginx, etc., como fixemos nós. Debería estar o máis preto posible da aplicación.
Por suposto, as métricas do sistema operativo son importantes, pero as empresas non están interesadas nelas, non se nos paga por elas.
Fonte: www.habr.com