Monitoramento Multifacetado do Angie, um Fork do Servidor Web nginx#
Uma visão geral detalhada das capacidades de monitoramento do Angie: API integrada para estatísticas, Console Light para visualização em tempo real e integração com Prometheus sem módulos de terceiros.
Uma bela demonstração ao vivo é melhor que qualquer imagem: https://console.angie.software/#
Olá, caro leitor. Meu nome é Dmitry. Sou engenheiro de sistemas na empresa Web Server. Ao longo da minha experiência prestando serviços de suporte técnico, primeiro na empresa Nginx, e agora na empresa que desenvolve o servidor web russo Angie, respondemos a uma pergunta muito popular: "Como organizo o monitoramento do estado do servidor web?" Aqui está como.
Monitoramento. "Por que se preocupar? Está tudo bem nos logs!"
Servidor Web Angie. "Por quê? Quando existe *." Como instalar. "Existe uma build para **?"
API. "Estou dizendo, existem logs! Só um segundo, deixe-me habilitá-los em produção." O que ela fornece. "Qual é a diferença dos logs?" Como configurar. "Não funciona automaticamente?" Obtendo configuração do servidor web. "Mas existe angie -T."
Console Light – interface web. "Mais um sistema de monitoramento?!1?1!!!" O que mostra. "Como assim tempo real?" Como instalar. "Realmente apenas algumas linhas de configuração?"
API para Prometheus. "Mas eu já estou usando! Bem, sim, analisamos logs..." Como configurar o Angie para integração. "Como isso sem njs?" Comparação com Console Light. "Os valores realmente coincidem?"
Conclusão. "Então é isso que multifacetado significa!"
1. Monitoramento. "Por que se preocupar? Está tudo bem nos logs!"#
Então, superamos a situação em que reagimos a incidentes na operação do sistema de informação com base em uma ligação de um usuário. Agora temos sistemas de monitoramento completos em nossa infraestrutura, com coleta de dados, um sistema de alertas e um botão "consertar tudo".
Ao responder perguntas de gerentes, arquitetos ou especialistas em segurança da informação sobre como garantimos a observabilidade de um dos componentes-chave no processo de tratamento de requisições de rede para a infraestrutura, mais frequentemente listamos o seguinte. Temos métricas de sistema para o processo do servidor web (quanto de CPU ou RAM ele consome, há quanto tempo está em execução), temos dados de logs e, menos comumente, temos a capacidade de exportar métricas do servidor web usando extensões de terceiros.
Obter métricas de sistema para um processo é prática comum, o mínimo para qualquer infraestrutura. Mas às vezes isso é extremamente insuficiente. Vemos consumo mínimo de CPU, mas o site mostra um erro 502 Bad Gateway, e está tudo terrível.
Obter dados de logs é simples. Mas os arquitetos observam que essencialmente, estamos seguindo retrospectivamente requisições que já foram processadas naquele momento. No caso de um ataque DoS, só veremos nos logs quando algumas requisições já foram processadas como "falha ao processar". Mas precisamos ver no monitoramento do servidor web requisições que já chegaram mas ainda não foram processadas pelo servidor upstream. O monitoramento deve, entre outras coisas, mostrar a preparação para um soco, não mostrar o hematoma no rosto.
Configurar exportação de métricas do seu servidor web usando soluções de terceiros é uma opção bastante viável. A única questão é o seu tempo para entender a configuração, compilá-la para o seu sistema operacional e aceitar o risco de que amanhã a versão do seu servidor web possa ser incompatível com um módulo que ainda não foi atualizado. E lembre-se, especialistas em segurança da informação nunca dormem.
Os recursos integrados do nosso produto, que discutiremos adiante, permitem monitoramento completo da carga do servidor Web/Proxy em tempo real, e também têm uma série de capacidades avançadas de integração com o sistema de monitoramento na infraestrutura do cliente.
2. Servidor Web Angie. "Por quê? Quando existe *"#
Para aqueles que não sabem, direi, e para outros lembrarei, que existe um produto chamado Angie, criado como um fork do nginx, desenvolvido pela empresa Web Server. A empresa reúne ex-engenheiros líderes da empresa NGINX. É distribuído sob a licença BSD, é legal, foi o que nos disseram.
A base de código do servidor web Angie foi bifurcada do Nginx 1.23.1. Desde então, estamos adicionando novas funcionalidades que não existem na versão de código aberto do nginx. Ao mesmo tempo, tentamos portar atualizações do nginx para o nosso servidor web, garantindo a possibilidade de migração perfeita para usuários do nginx para o Angie.
Desde o primeiro lançamento, que foi em outubro de 2022, o Angie inclui um módulo de API que implementa uma interface HTTP RESTful para obter informações básicas sobre o servidor web em formato JSON, bem como estatísticas sobre:
conexões de clientes
zonas de memória compartilhada
consultas DNS
requisições HTTP
cache de resposta HTTP
sessões do módulo stream
zonas dos módulos limit_conn http, limit_conn stream e limit_req
A lista completa de métricas pode ser encontrada na documentação.
Recentemente, foi lançada uma nova versão Angie 1.3.0, que implementa suporte para saída de métricas no formato Prometheus. Preparamos uma interface web para visualizar métricas em tempo real de uma instância selecionada. E é hora de fazer um pequeno teste comparativo das capacidades de monitoramento do servidor web.
Entre as funcionalidades distintivas do Angie estão:
Suporte de API para coleta de estatísticas, configuração e muito mais.
DNS dinâmico com suporte para transformação de registro DNS SRV.
Vinculação de sessão de cliente usando método sticky session ou route.
2.1. Como instalar. "Existe uma build para **?"#
Instruções detalhadas sobre como instalar o Angie são apresentadas no site oficial em russo e inglês.
Embora suportemos 11 distribuições de várias versões nas arquiteturas x86-64 e arm64, neste artigo fornecerei apenas os passos necessários para ilustrar as capacidades de monitoramento do servidor web. Realizarei todas as instalações no SO Debian.
Instalar o Angie não é diferente de instalar qualquer outro pacote de um repositório. Primeiro, adicione a chave e o repositório:
sudo apt-get update && \
sudo apt-get install --no-install-recommends --no-install-suggests --yes \
ca-certificates curl lsb-release && \
sudo curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg \
https://angie.software/keys/angie-signing.gpg && \
echo "deb https://download.angie.software/angie/debian/ `lsb_release -cs` main" \
| sudo tee /etc/apt/sources.list.d/angie.list >/dev/null
E instale o Angie:
sudo apt-get update && \
sudo apt-get install --no-install-recommends --no-install-suggests --yes \
angie
Pronto. O servidor web está em execução e a página de boas-vindas está disponível na porta 80.
curl -I localhost HTTP/1.1 200 OK Server: Angie/1.3.0 ....
3. API. "Estou dizendo, existem logs! Só um segundo, deixe-me habilitá-los em produção"#
Quando um cliente entra em contato com o suporte técnico, frequentemente é solicitado que forneça logs para diagnóstico. Uma das situações frequentemente encontradas é que os logs do servidor web em produção estão desabilitados. Simplesmente para economizar recursos. A questão de analisar logs e enviá-los para o sistema de monitoramento simplesmente não surge. Sem logs – sem problemas. Mas e se ainda fizermos análise de logs e construirmos um sistema de monitoramento baseado nesses dados? Qual é a diferença de usar métricas através da API? Existem várias nuances. Primeiro, os logs são gravados após a requisição ter sido processada. Em outras palavras, quando o último byte foi enviado ao cliente. O que devemos fazer neste caso com conexões de longa duração ou clientes lentos? A API vem ao resgate aqui. A métrica "processing" em "requests" dentro de "server_zones" ajuda você a descobrir quantas requisições o servidor está processando atualmente. Segundo, os logs não podem te dizer nada sobre zonas de memória compartilhada ou zonas de cache usadas pelo seu servidor. No entanto, o estouro delas devido a tráfego enorme ou em vários casos de ataques ao servidor pode levar a resultados desastrosos, segfaults e, consequentemente, quedas de conexão e até indisponibilidade do serviço. Aqui a API vem ao nosso resgate novamente. Você pode visualizar e calcular a ocupação da zona e responder a situações imprevistas a tempo. Terceiro, ao obter métricas do runtime através da API, você simplesmente obtém valores mais precisos no momento. E há simplesmente mais delas do que você pode extrair dos logs. Você pode visualizar a árvore completa de métricas no site oficial. Voltando à questão de soluções de terceiros, o leitor pode perguntar: "Por que eu deveria mudar alguma coisa? Eu tenho usado uma solução abrangente baseada no módulo vts há muito tempo." Aqui vale a pena notar que soluções como o módulo vts não fornecem realmente estatísticas em tempo real, já que elas trabalham na fase de log e os contadores são calculados apenas após o processamento da requisição estar completo. Em outras palavras, este tipo de solução tem as mesmas desvantagens que o monitoramento baseado em logs. Para habilitar a API, é suficiente adicionar a diretiva "api" ao config. Vamos comentar as diretivas "allow" e "deny" em "location /status/" no arquivo de configuração "/etc/angie/http.d/default.conf" para que possamos ver imediatamente a página da API no navegador. (Em produção, você ainda deve configurar adequadamente essas diretivas por motivos de segurança. Isso também se aplica às seguintes partes deste artigo): Vamos adicionar algumas zonas e upstream ao config para maior clareza: Reinicie o Angie para aplicar a configuração: e na página /status/ do seu servidor você já verá JSON com métricas da API. Falando sobre trabalhar com a configuração do servidor web. Como um bônus adicional, a API agora tem a capacidade de exibir a configuração do seu servidor. Especificamente aquela na qual o Angie está executando atualmente. Isso pode ser útil em vários casos, por exemplo, se por algum motivo incrível você deletou todos os configs do servidor e quer restaurá-los. Aqui a saída do comando "angie -T" não vai te ajudar, já que o comando "angie -T" realiza uma verificação de sintaxe e exibe a configuração do disco. O arquivo binário "angie" tentará analisar o arquivo de configuração especificado por padrão ao iniciar. Agora, para entender se a configuração atualizada foi aplicada, você pode comparar as saídas da API e "sudo angie -T". Ou você pode fazer ainda mais simples e rastrear a geração da configuração. O Angie rastreia a geração de configuração de cada um de seus processos; a numeração começa de um quando o servidor inicia, e os números crescem com cada recarga de configuração e são indicados nos nomes dos processos. Após uma recarga de configuração bem-sucedida (independentemente de haver mudanças), os números de geração para processos que receberam a nova configuração aumentarão, e se quaisquer processos worker de gerações anteriores continuarem a trabalhar, isso será imediatamente perceptível na saída do comando "ps aux | grep angie". A saída da API na seção /status/angie/ também mostrará a geração da configuração. Mas ao contrário da saída do ps, a saída da API mostrará apenas a nova geração de config.3.1. O que ele fornece. "Qual é a diferença dos logs?"#
3.2. Como configurar. "Não funciona automaticamente?"#
location /status/ {
api /status/;
# allow 127.0.0.1;
# deny all;
}
upstream foo {
zone http-upstream-foo 256k;
server 127.0.0.2 max_conns=10 max_fails=10;
server 127.0.0.3 max_conns=10 max_fails=10;
server 127.0.0.4 max_conns=10 max_fails=10;
}
server {
#...
status_zone example;
#...
location / {
#...
status_zone location_zone;
}
#...
}
sudo angie -t && sudo service angie reload
3.3. Obtendo a configuração do servidor web. "Mas existe o angie -T"#
4. Console Light – interface web. "Mais um sistema de monitoramento?!1?1!!!"#
A partir da versão 1.3.0 do Angie, foi adicionado o recurso Console Light—um console visual leve para monitoramento de atividade em tempo real que exibe indicadores-chave de carga e desempenho do servidor. E em geral, facilita para o administrador rastrear a viabilidade e o estado do servidor. A característica desta página web simples é a exibição de métricas em tempo real para uma instância específica do servidor web. A página atualiza com alguma periodicidade (isso pode ser configurado). Note que se você tem um cluster de vários servidores web, então cada instância no cluster tem seu próprio console visual separado configurado. Na verdade, todas as métricas mencionadas anteriormente estão agrupadas aqui em abas recomendadas para rastreamento. Por exemplo, você pode encontrar a métrica "processing" em "requests" na aba HTTP Zones. Aqui ela será chamada de Current. E você pode visualizar a ocupação da zona nas abas Shared Zones e Caches. Você pode visualizar nossa versão demo do Console Light em https://console.angie.software/, e uma descrição detalhada das abas e métricas coletadas lá pode ser encontrada na seção de documentação. Esta funcionalidade é fornecida como um pacote separado; não deixe este fato te confundir, meu leitor. O Console Light está totalmente integrado com o Angie e a API. Vamos instalar o pacote Console Light para visualizar as estatísticas atuais do servidor. Para fazer isso, simplesmente execute: Então conecte o Console Light colocando "location /console" no contexto "server" do arquivo de configuração do Angie ("/etc/angie/http.d/default.conf"). Assim: Informações mais detalhadas podem ser encontradas no site oficial. Vamos reiniciar o Angie: E, indo para /console, veremos uma página com métricas. Aqui você verá imediatamente como as métricas Requests e Responses são preenchidas. Como estamos configurando nosso console no mesmo "server" onde o "status_zone" está localizado, vemos como o próprio console, ao acessar a API, gera estatísticas para nós. Vou notar novamente que em produção você não deveria fazer tal configuração. É melhor usar um bloco "server" separado usado apenas para monitoramento.
4.1. O que ele permite ver. "O que significa tempo real?"#
4.2. Como instalar. "Realmente apenas algumas linhas de config?"#
sudo apt-get install angie-console-light
location /console {
alias /usr/share/angie-console-light/html;
index index.html;
location /console/api/ {
api /status/;
}
}
sudo angie -t && sudo service angie reload
5. API para Prometheus. "Mas eu já estou usando! Bem sim, analisamos logs..."#
Uma solução bastante popular para construir um sistema de monitoramento é usar o Prometheus para coletar métricas. Assumimos que você já tem este serviço instalado. Muito provavelmente, você o preenche através de análise de logs ou usa exportadores de terceiros.
No nosso caso, fizemos uma solução integrada para exportar métricas no formato Prometheus. Vou notar que temos templates flexivelmente configuráveis para que você possa adicionar seu próprio toque à sua coleta de métricas. A lista completa de métricas disponíveis está coletada no template all. O novo pacote já inclui um template com todas as métricas disponíveis, então será suficiente simplesmente habilitar a entrega dessas métricas em um local conveniente adicionando a diretiva "prometheus". Reinicie o Angie: E ao requisitar o endereço /metrics/, veremos o formato familiar do Prometheus. Você pode encontrar exemplos online de exportação de métricas do nginx usando njs. No nosso caso, nenhum runtime js é usado; o cálculo e a entrega ocorrem no runtime do servidor web com sobrecarga mínima. Como engenheiro, fiquei interessado em ver se havia alguma diferença entre visualizar métricas através do Prometheus+Grafana ou através do Console Light. Configurei um ambiente de teste simples, configurei o servidor web, integrações com Prometheus e Console Light. Criei carga artificial no servidor web usando wrk e scripts. Nas capturas de tela abaixo, você pode comparar as métricas correspondentes. Ficou bastante interessante. No geral, as métricas são semelhantes em tudo; as diferenças começam quando você aumenta o intervalo de coleta de métricas. Se o Console Light busca métricas a cada segundo, então no Grafana um intervalo de 2 minutos mostra métricas com atraso e com alguma diferença. E, como resultado, há diferenças nas capturas de tela. No momento em que o uso de disco começou a crescer de forma alarmante, o Grafana ainda estava mostrando que tudo estava bem. Claro, eventualmente os indicadores se alinharam. A situação com os indicadores de requisições em tempo de execução também é similar. Muito depende das configurações do próprio Grafana e Prometheus; você precisará escolher intervalos que sejam adequados para você. Mas esteja preparado que com intervalos mais curtos, os serviços precisarão armazenar mais dados em disco.5.1. Como Configurar o Angie para Integração. "Como Isso Funciona Sem o njs?"#
location /metrics/ {
prometheus all;
}
sudo angie -t && sudo service angie reload
5.2. Comparação com o Console Light. "Os Valores Realmente Coincidem?"#
6. Conclusão. "Então É Isso Que Significa Multifacetado!"#
Não se pode dizer que existe uma única maneira correta de organizar um sistema de monitoramento de servidor web. Mas tentamos fornecer flexibilidade no servidor web Angie para configurar uma solução que se adeque a você.
Como engenheiro, frequentemente encontro situações em que os usuários pedem ajuda quando tudo já aconteceu e as configurações ainda não foram definidas. Portanto, permita-me aproveitar um momento para lembrá-lo: é melhor fazer todas as configurações necessárias com antecedência para estar preparado para situações imprevistas. Felizmente, existem instruções detalhadas para isso.
Então, sobre a abordagem de monitoramento versátil. A natureza multifacetada se expressa no fato de que você pode continuar a analisar logs, pode usar o servidor web Angie, que fornece uma API com métricas estendidas. Você pode dar uma olhada no status do servidor web em uma página web simples, o Console Light. E finalmente, você pode fazer uma integração completa das informações de status do servidor web em seu sistema de coleta de métricas baseado em Prometheus.
Por favor, use! Foi um prazer ajudá-lo!
