Meu nome é Anton Baderin. Trabalho no Centro de Alta Tecnologia e faço administração de sistemas. Há um mês terminou nossa conferência corporativa, onde compartilhamos nossa experiência acumulada com a comunidade de TI de nossa cidade. Falei sobre monitoramento de aplicações web. O material foi destinado ao nível júnior ou médio, que não construiu esse processo do zero.
A pedra angular de qualquer sistema de monitoramento é a solução de problemas de negócios. Monitorar por monitorar não interessa a ninguém. O que as empresas querem? Para que tudo funcione com rapidez e sem erros. As empresas querem ser proativas, para que nós próprios identifiquemos problemas no serviço e os resolvamos o mais rapidamente possível. Esses, na verdade, são os problemas que resolvi durante todo o ano passado em um projeto para um de nossos clientes.
Sobre o projeto
O projeto é um dos maiores programas de fidelidade do país. Ajudamos as redes de varejo a aumentar a frequência das vendas por meio de diversas ferramentas de marketing, como cartões de bônus. No total, o projeto inclui 14 aplicações que rodam em dez servidores.
Durante o processo de entrevista, percebi repetidamente que os administradores nem sempre abordam o monitoramento de aplicativos da web corretamente: muitos ainda se concentram nas métricas do sistema operacional e ocasionalmente monitoram os serviços.
No meu caso, o sistema de monitoramento do cliente era anteriormente baseado no Icinga. Não resolveu de forma alguma os problemas acima. Muitas vezes o próprio cliente nos informava sobre os problemas e, na maioria das vezes, simplesmente não tínhamos dados suficientes para descobrir o motivo.
Além disso, havia uma compreensão clara da futilidade de seu desenvolvimento posterior. Acho que quem conhece Icinga vai me entender. Então, decidimos redesenhar completamente o sistema de monitoramento de aplicações web do projeto.
Prometeu
Escolhemos o Prometheus com base em três indicadores principais:
- Um grande número de métricas disponíveis. No nosso caso são 60 mil. Claro, vale a pena notar que não usamos a grande maioria deles (provavelmente cerca de 95%). Por outro lado, são todos relativamente baratos. Para nós, este é o outro extremo em relação ao Icinga utilizado anteriormente. Nele, adicionar métricas era uma dor especial: as existentes eram caras (basta olhar o código-fonte de qualquer plugin). Qualquer plugin era um script em Bash ou Python, cujo lançamento é caro em termos de recursos consumidos.
- Este sistema consome uma quantidade relativamente pequena de recursos. 600 MB de RAM, 15% de um núcleo e algumas dezenas de IOPS são suficientes para todas as nossas métricas. Claro, você precisa executar exportadores de métricas, mas todos eles são escritos em Go e também não consomem muita energia. Não creio que nas realidades modernas isso seja um problema.
- Fornece a capacidade de migrar para Kubernetes. Considerando os planos do cliente, a escolha é óbvia.
ELK
Anteriormente, não coletávamos nem processávamos logs. As deficiências são claras para todos. Escolhemos o ELK porque já tínhamos experiência com este sistema. Armazenamos apenas logs de aplicativos lá. Os principais critérios de seleção foram a busca de texto completo e sua rapidez.
Clickhouse
Inicialmente, a escolha recaiu sobre o InfluxDB. Percebemos a necessidade de coletar logs Nginx, estatísticas de pg_stat_statements e armazenar dados históricos do Prometheus. Não gostamos do Influx porque ele periodicamente começava a consumir uma grande quantidade de memória e travava. Além disso, eu queria agrupar as consultas por remote_addr, mas o agrupamento neste SGBD é apenas por tags. As tags são caras (memória), seu número é limitado condicionalmente.
Iniciamos nossa busca novamente. O que era necessário era um banco de dados analítico com consumo mínimo de recursos, preferencialmente com compactação de dados em disco.
Clickhouse atende a todos esses critérios e nunca nos arrependemos de nossa escolha. Não escrevemos nele nenhuma quantidade extraordinária de dados (o número de inserções é de apenas cinco mil por minuto).
NewRelic
A NewRelic está historicamente conosco porque foi a escolha do cliente. Nós o usamos como um APM.
Zabbix
Usamos o Zabbix exclusivamente para monitorar a Black Box de diversas APIs.
Definindo uma abordagem de monitoramento
Queríamos decompor a tarefa e assim sistematizar a abordagem à monitorização.
Para fazer isso, dividi nosso sistema nos seguintes níveis:
- hardware e VMS;
- sistema operacional;
- serviços de sistema, pilha de software;
- aplicativo;
- logíca de negócios.
Por que esta abordagem é conveniente:
- sabemos quem é o responsável pelo trabalho de cada nível e, a partir disso, podemos enviar alertas;
- podemos usar a estrutura ao suprimir alertas - seria estranho enviar um alerta sobre indisponibilidade do banco de dados quando a máquina virtual como um todo estiver indisponível.
Como nossa tarefa é identificar violações na operação do sistema, devemos destacar em cada nível um determinado conjunto de métricas às quais vale a pena prestar atenção ao escrever regras de alerta. A seguir, passaremos pelos níveis “VMS”, “Sistema operacional” e “Serviços do sistema, pilha de software”.
Máquinas virtuais
A hospedagem nos aloca processador, disco, memória e rede. E tivemos problemas com os dois primeiros. Então, as métricas:
Tempo roubado de CPU - ao comprar uma máquina virtual na Amazon (t2.micro, por exemplo), você deve entender que não recebe um núcleo de processador inteiro, mas apenas uma cota de seu tempo. E quando você esgotá-lo, o processador será tirado de você.
Essa métrica permite acompanhar esses momentos e tomar decisões. Por exemplo, é necessário adotar uma tarifa mais gorda ou distribuir o processamento de tarefas em segundo plano e solicitações de API para diferentes servidores?
Tempo de espera de IOPS + CPU - por algum motivo, muitas hospedagens em nuvem pecam por não fornecer IOPS suficientes. Além disso, um cronograma com IOPS baixo não é um argumento para eles. Portanto, vale a pena coletar CPU iowait. Com esse par de gráficos - com baixo IOPS e alta espera de I/O - você já consegue conversar com a hospedagem e resolver o problema.
Sistema operacional
Métricas do sistema operacional:
- quantidade de memória disponível em %;
- atividade de uso de swap: vmstat swapin, swapout;
- número de inodes disponíveis e espaço livre no sistema de arquivos em%
- carga média;
- número de conexões no estado tw;
- plenitude da tabela conntrack;
- A qualidade da rede pode ser monitorada usando o utilitário ss, o pacote iproute2 - obtenha um indicador de conexões RTT de sua saída e agrupe-o por porta de destino.
Também no nível do sistema operacional temos entidades como processos. É importante identificar no sistema um conjunto de processos que desempenham um papel importante no seu funcionamento. Se, por exemplo, você tiver vários pgpools, será necessário coletar informações para cada um deles.
O conjunto de métricas é o seguinte:
- CPUs;
- a memória é principalmente residente;
- IO – preferencialmente em IOPS;
- FileFd - abrir e limitar;
- falhas significativas de página - desta forma você pode entender qual processo está sendo trocado.
Implantamos todo o monitoramento no Docker e usamos o Advisor para coletar dados de métricas. Em outras máquinas usamos o process-exporter.
Serviços do sistema, pilha de software
Cada aplicação tem suas especificidades e é difícil destacar um conjunto específico de métricas.
O conjunto universal é:
- taxa de solicitação;
- número de erros;
- latência;
- saturação.
Nossos exemplos mais marcantes de monitoramento nesse nível são Nginx e PostgreSQL.
O serviço mais carregado em nosso sistema é o banco de dados. No passado, muitas vezes tínhamos problemas para descobrir o que o banco de dados estava fazendo.
Vimos uma carga alta nos discos, mas os logs lentos não mostraram nada. Resolvemos esse problema usando pg_stat_statements, uma visualização que coleta estatísticas de consulta.
Isso é tudo que o administrador precisa.
Construímos gráficos da atividade de solicitações de leitura e gravação:
Tudo é simples e claro, cada pedido tem sua cor.
Um exemplo igualmente impressionante são os logs do Nginx. Não é de surpreender que poucas pessoas os analisem ou os mencionem na lista de itens essenciais. O formato padrão não é muito informativo e precisa ser ampliado.
Pessoalmente, adicionei request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Plotamos o tempo de resposta e o número de erros:
Construímos gráficos de tempo de resposta e número de erros. Lembrar? Eu falei sobre objetivos de negócios? De forma rápida e sem erros? Já cobrimos essas questões com dois gráficos. E você já pode chamar os administradores de plantão por meio deles.
Mas resta mais um problema - garantir a rápida eliminação das causas do incidente.
Resolução de incidentes
Todo o processo, desde a identificação até a solução de um problema, pode ser dividido em várias etapas:
- identificar o problema;
- notificação ao administrador de plantão;
- resposta a um incidente;
- eliminação das causas.
É importante que o façamos o mais rapidamente possível. E se nas fases de identificação de um problema e envio de uma notificação não conseguimos ganhar muito tempo - em qualquer caso serão gastos dois minutos, então as subsequentes são simplesmente um campo não arado para melhorias.
Vamos imaginar que o telefone do oficial de plantão tocou. O que ele fará? Procure respostas para perguntas - o que quebrou, onde quebrou, como reagir? Veja como respondemos a essas perguntas:
Simplesmente incluímos todas essas informações no texto da notificação, fornecemos um link para uma página wiki que descreve como responder a este problema, como resolvê-lo e escaloná-lo.
Ainda não falei nada sobre a camada de aplicação e a lógica de negócios. Infelizmente, nossos aplicativos ainda não implementam a coleta de métricas. A única fonte de qualquer informação desses níveis são os logs.
Alguns pontos.
Primeiro, escreva logs estruturados. Não há necessidade de incluir contexto no texto da mensagem. Isso os torna difíceis de agrupar e analisar. O Logstash leva muito tempo para normalizar tudo isso.
Em segundo lugar, use os níveis de severidade corretamente. Cada idioma tem seu próprio padrão. Pessoalmente, distingo quatro níveis:
- nenhum erro;
- erro do lado do cliente;
- o erro está do nosso lado, não perdemos dinheiro, não assumimos riscos;
- O erro está do nosso lado, perdemos dinheiro.
Deixe-me resumir. Você precisa tentar construir um monitoramento baseado na lógica de negócios. Tente monitorar o próprio aplicativo e operar com métricas como o número de vendas, o número de registros de novos usuários, o número de usuários ativos no momento e assim por diante.
Se todo o seu negócio consiste em um botão no navegador, você precisa monitorar se ele clica e funciona corretamente. Todo o resto não importa.
Se você não tiver isso, você pode tentar atualizá-lo nos logs de aplicativos, logs Nginx e assim por diante, como fizemos. Você deve estar o mais próximo possível do aplicativo.
É claro que as métricas do sistema operacional são importantes, mas as empresas não estão interessadas nelas e não somos pagos por elas.
Fonte: habr.com