Meu nome é Anton Baderin. Trabalho no Center for High Technologies e estou envolvido na administração de sistemas. Há um mês, nossa conferência corporativa terminou, onde compartilhamos nossa experiência com a comunidade de TI de nossa cidade. Eu falei sobre o monitoramento de aplicativos da web. O material foi destinado ao nível júnior ou médio, que não construiu esse processo a partir do zero.
A pedra angular subjacente a qualquer sistema de monitoramento é a solução para os problemas de negócios. O monitoramento para fins de monitoramento não interessa a ninguém. O que a empresa quer? Para que tudo funcione rapidamente e sem erros. Os negócios desejam proatividade, para que nós mesmos identifiquemos problemas no serviço e os eliminemos o mais rápido possível. De fato, essas são as tarefas que venho resolvendo no ano passado no projeto de um de nossos clientes.
Sobre o projeto
O projeto é um dos maiores programas de fidelidade do país. Ajudamos os varejistas a aumentar sua frequência de vendas por meio de várias ferramentas de marketing, como cartões de bônus. No total, o projeto inclui 14 aplicativos que são executados em dez servidores.
No processo de realização de entrevistas, notei repetidamente que os administradores nem sempre são os corretos para monitorar aplicativos da Web: até agora, muitos se preocupam com as métricas do sistema operacional e, ocasionalmente, monitoram os serviços.
No meu caso, Icinga era a base do sistema de monitoramento de clientes antes. Ela não resolveu os problemas acima. Frequentemente, o próprio cliente nos informava sobre os problemas e pelo menos simplesmente não tínhamos dados suficientes para entender o motivo.
Além disso, havia um entendimento claro da futilidade de seu desenvolvimento posterior. Eu acho que aqueles que estão familiarizados com Icinga vão me entender. Por isso, decidimos reprojetar completamente o sistema de monitoramento de aplicativos da web no projeto.
Prometeu
Escolhemos o Prometheus com base em três indicadores principais:
- Um grande número de métricas disponíveis. No nosso caso, existem 60 mil deles. Obviamente, vale a pena notar que a grande maioria deles não usamos (provavelmente cerca de 95%). Por outro lado, todos são relativamente baratos. Para nós, esse é outro extremo comparado ao Icinga usado anteriormente. Nele, adicionar métricas era uma dor particular: as disponíveis eram caras (basta olhar o código fonte de qualquer plug-in). Qualquer plug-in era um script Bash ou Python, cujo lançamento não é barato em termos de recursos consumidos.
- Este sistema consome uma quantidade relativamente pequena de recursos. Todas as nossas métricas têm 600 MB de RAM, 15% de um núcleo e algumas dezenas de IOPS. Obviamente, você precisa executar exportadores de métricas, mas todas elas estão escritas em Go e também não diferem em gula. Eu não acho que nas realidades modernas isso seja um problema.
- Torna possível mudar para o Kubernetes. Dados os planos do cliente, a escolha é óbvia.
ELK
Anteriormente, não coletávamos ou processávamos logs. As falhas são claras para todos. Escolhemos o ELK, pois já tínhamos experiência com este sistema. Armazenamos apenas logs de aplicativos lá. Os principais critérios de seleção foram a pesquisa de texto completo e sua velocidade.
Clickhouse
Inicialmente, a escolha caiu no InfluxDB. Reconhecemos a necessidade de coletar logs do Nginx, estatísticas de pg_stat_statements e armazenar dados históricos do Prometheus. Não gostamos do Influx, pois periodicamente começava a consumir uma grande quantidade de memória e travava. Além disso, eu queria agrupar solicitações por remote_addr e agrupar neste DBMS apenas por tags. Tags da estrada (memória), seu número é limitado condicionalmente.
Iniciamos a pesquisa novamente. Precisávamos de uma base analítica com consumo mínimo de recursos, de preferência com compactação de dados em disco.
A Clickhouse atende a todos esses critérios e nunca lamentamos a escolha. Não gravamos nenhuma quantidade pendente de dados nele (o número de inserções é de apenas cerca de cinco mil por minuto).
NewRelic
A NewRelic está historicamente conosco desde que foi a escolha do cliente. Nós o usamos como um APM.
Zabbix
Usamos o Zabbix exclusivamente para monitorar a caixa preta de várias APIs.
Definindo uma abordagem de monitoramento
Queríamos decompor a tarefa e, assim, sistematizar a abordagem de monitoramento.
Para fazer isso, dividi nosso sistema nos seguintes níveis:
- Hardware e VMS;
- sistema operacional
- serviços de sistema, pilha de software;
- aplicação
- lógica de negócios.
O que torna essa abordagem conveniente:
- sabemos quem é o responsável pelo trabalho de cada um dos níveis e, com base nisso, podemos enviar alertas;
- podemos usar a estrutura ao suprimir alertas - seria estranho enviar um alerta sobre a inacessibilidade do banco de dados quando a máquina virtual é geralmente inacessível.
Como nossa tarefa é detectar irregularidades no sistema, em cada nível devemos selecionar um determinado conjunto de métricas que devem ser prestadas atenção ao escrever as regras do alerta. A seguir, passaremos pelos níveis de "VMS", "Sistema operacional" e "Serviços do sistema, pilha de software".
Máquinas virtuais
A hospedagem nos fornece um processador, disco, memória e rede. E nos dois primeiros tivemos problemas. Então métricas:
Tempo roubado da CPU - quando você compra uma máquina virtual na Amazon (t2.micro, por exemplo), deve entender que não está alocado um núcleo de processador inteiro, mas apenas uma cota de seu tempo. E quando você esgotar, o processador será retirado de você.
Essa métrica permite rastrear esses momentos e tomar decisões. Por exemplo, é necessário aumentar a tarifa ou distribuir o processamento de tarefas e solicitações em segundo plano na API para diferentes servidores.
IOPS + tempo de iowait da CPU - por algum motivo, muitas empresas de hospedagem em nuvem pecam por não fornecer IOPS. Além disso, uma programação com IOPS baixo não é um argumento para eles. Portanto, vale a pena coletar a CPU iowait. Com esse par de gráficos - com baixas IOPS e altas expectativas de E / S - você já pode conversar com a hospedagem e resolver o problema.
Sistema operacional
Métricas do sistema operacional:
- quantidade de memória disponível em%;
- atividade usando swap: vmstat swapin, swapout;
- o 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;
- o desempenho da rede pode ser monitorado usando o utilitário ss, pacote iproute2 - obtenha o indicador de conexões RTT de sua saída e agrupe por porta de destino.
Também no nível do sistema operacional, temos uma entidade como processos. É importante destacar no sistema um conjunto de processos que desempenham um papel importante em seu trabalho. Se, por exemplo, você tiver vários pgpool, precisará coletar informações para cada um deles.
O conjunto de métricas é o seguinte:
- CPU
- a memória é principalmente residente;
- IO - preferencialmente em IOPS;
- FileFd - aberto e limite;
- falhas significativas de página - para que você possa entender qual processo está sendo trocado.
Todo o monitoramento é implantado no Docker, usamos o TripAdvisor para coletar dados métricos. Em outras máquinas, usamos exportador de processos.
Serviços de sistema, pilha de software
Cada aplicativo tem suas próprias especificidades e é difícil distinguir algum conjunto de métricas.
O conjunto universal é:
- taxa de solicitação;
- número de erros;
- latência
- saturação.
Os exemplos mais impressionantes de monitoramento nesse nível são o Nginx e o PostgreSQL.
O serviço mais carregado em nosso sistema é o banco de dados. Costumávamos ter problemas frequentemente para descobrir o que o banco de dados faz.
Vimos uma carga alta nos discos, mas os slogans realmente não mostraram nada. Resolvemos esse problema com pg_stat_statements, uma visão que coleta estatísticas sobre solicitações.
Isso é tudo o que o administrador precisa.
Traçamos a atividade de solicitações de leitura e gravação:
Tudo é simples e claro, cada solicitação tem sua própria cor.
Um exemplo igualmente impressionante são os logs do Nginx. Não surpreendentemente, poucos os analisam ou os mencionam na lista dos necessários. O formato padrão não é muito informativo e precisa ser expandido.
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:
Plotamos o tempo de resposta e o número de erros. Você se lembra? Eu falei sobre objetivos de negócios? Para rapidamente e sem erros? Já fechamos esses problemas com dois gráficos. E sobre eles você já pode chamar os administradores de serviço.
Mas outro problema permaneceu - para garantir a rápida eliminação das causas do incidente.
Gerenciamento de incidentes
Todo o processo, da identificação à solução de um problema, pode ser dividido em várias etapas:
- identificação de problemas;
- notificação do administrador de plantão;
- reação ao incidente;
- eliminação das causas.
É importante que façamos isso o mais rápido possível. E se não pudermos ganhar muito tempo nos estágios de identificação de um problema e envio de uma notificação - em qualquer caso, restarão dois minutos para eles, então os próximos serão apenas um campo não planejado para melhorias.
Vamos imaginar que o telefone tocou em serviço. O que ele vai fazer? Procure respostas para as perguntas - o que está quebrado, onde está quebrado, como reagir? Veja como respondemos a estas perguntas:
Simplesmente incluímos todas essas informações no texto da notificação, fornecemos um link para uma página da wiki que descreve como responder a esse problema, como resolvê-lo e escalá-lo.
Ainda não falei nada sobre a camada de aplicativos e a lógica de negócios. Infelizmente, a coleta de métricas ainda não foi implementada em nossos aplicativos. A única fonte de pelo menos algumas informações desses níveis são os logs.
Alguns pontos.
Primeiro, escreva logs estruturados. Não é necessário incluir o contexto no corpo da mensagem. Isso torna difícil agrupá-los e analisá-los. O Logstash leva muito tempo para normalizar tudo isso.
Em segundo lugar, use os níveis de gravidade corretamente. Cada idioma tem seu próprio padrão. Pessoalmente, distingo quatro níveis:
- sem erro;
- erro do lado do cliente;
- um erro está do nosso lado, não perdemos dinheiro, não corremos riscos;
- o erro está do nosso lado, estamos perdendo dinheiro.
Eu resumo. É necessário tentar construir o monitoramento precisamente a partir da 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 novos registros de usuários, o número de usuários ativos no momento e assim por diante.
Se toda a sua empresa for um único botão no seu navegador, você precisará monitorar se ela está sendo compactada e funcionando corretamente. Tudo o resto não é importante.
Se você não tiver isso, tente alcançá-lo nos logs do aplicativo, do Nginx e assim por diante, como fizemos. Você deve estar o mais próximo possível do aplicativo.
As métricas do sistema operacional são obviamente importantes, mas não são interessantes para os negócios, não somos pagos por elas.