Considere o conceito de monitoramento do Kubernetes, conheça a ferramenta Prometheus e fale sobre alertas.
O tema monitoramento é volumoso, não pode ser desmontado em um artigo. O objetivo deste texto é fornecer uma visão geral das ferramentas, conceitos e abordagens.
O material do artigo é um aperto de . Se você quiser fazer um curso completo - inscreva-se em um curso em .
O que é monitorado em um cluster Kubernetes
servidores físicos. Se o cluster Kubernetes estiver implantado em seus servidores, será necessário monitorar sua integridade. O Zabbix cuida dessa tarefa; se você trabalha com ele, não precisa recusar, não haverá conflitos. É o Zabbix quem monitora o estado dos nossos servidores.
Vamos prosseguir para o monitoramento no nível do cluster.
Componentes do plano de controle: API, Agendador e outros. No mínimo, você precisa ter certeza de que a API dos servidores ou etcd é maior que 0. O Etcd pode retornar muitas métricas: pelos discos nos quais está girando, pela integridade de seu cluster etcd e outros.
Estivador apareceu há muito tempo e todos conhecem seus problemas: muitos contêineres geram congelamentos e outros problemas. Portanto, o próprio Docker, como sistema, também deve ser controlado, pelo menos quanto à disponibilidade.
DNS Se o DNS falhar no cluster, todo o serviço Discovery irá falhar depois disso, as chamadas de pods para pods deixarão de funcionar. Na minha prática, não houve tais problemas, mas isso não significa que o estado do DNS não precise ser monitorado. A latência da solicitação e algumas outras métricas podem ser rastreadas no CoreDNS.
Ingress. É necessário controlar a disponibilidade de ingressos (incluindo o Controlador de ingresso) como pontos de entrada para o projeto.
Os principais componentes do cluster foram desmontados - agora vamos descer ao nível das abstrações.
Parece que os aplicativos são executados em pods, o que significa que precisam ser controlados, mas na realidade não são. Os pods são efêmeros: hoje rodam em um servidor, amanhã em outro; hoje são 10, amanhã 2. Portanto, ninguém monitora os pods. Dentro de uma arquitetura de microsserviços, é mais importante controlar a disponibilidade da aplicação como um todo. Em particular, verifique a disponibilidade dos terminais de serviço: alguma coisa funciona? Se o aplicativo estiver disponível, o que acontece por trás dele, quantas réplicas existem agora são questões de segunda ordem. Não há necessidade de monitorar instâncias individuais.
No último nível, você precisa controlar o funcionamento do próprio aplicativo, obter métricas de negócios: número de pedidos, comportamento do usuário e assim por diante.
Prometeu
O melhor sistema para monitorar um cluster é . Não conheço nenhuma ferramenta que se compare ao Prometheus em termos de qualidade e facilidade de uso. É ótimo para infraestrutura flexível, então quando dizem “monitoramento Kubernetes”, geralmente se referem ao Prometheus.
Existem algumas opções para começar a usar o Prometheus: usando o Helm, você pode instalar um Prometheus ou um Operador Prometheus normal.
- Prometeu normal. Está tudo bem com ele, mas você precisa configurar o ConfigMap - na verdade, escrever arquivos de configuração baseados em texto, como fizemos antes, antes da arquitetura de microsserviços.
- O Operador Prometheus é um pouco mais espalhado, um pouco mais complicado em termos de lógica interna, mas é mais fácil de trabalhar: existem objetos separados, abstrações são adicionadas ao cluster, por isso são muito mais convenientes de controlar e configurar.
Para entender o produto, recomendo instalar primeiro o Prometheus normal. Você terá que configurar tudo através da configuração, mas isso será benéfico: você descobrirá o que pertence e como está configurado. No Operador Prometheus, você sobe imediatamente para uma abstração superior, embora também possa mergulhar nas profundezas, se desejar.
O Prometheus está bem integrado ao Kubernetes: ele pode acessar e interagir com o API Server.
O Prometheus é popular, e é por isso que um grande número de aplicativos e linguagens de programação o suportam. É necessário suporte, pois o Prometheus possui formato de métricas próprio e, para transferi-lo, é necessária uma biblioteca dentro do aplicativo ou um exportador pronto. E existem alguns desses exportadores. Por exemplo, existe o PostgreSQL Exporter: ele pega dados do PostgreSQL e os converte para o formato Prometheus para que o Prometheus possa trabalhar com eles.
Arquitetura Prometeu
Servidor Prometheus é o back-end, o cérebro de Prometheus. As métricas são armazenadas e processadas aqui.
As métricas são armazenadas no banco de dados de série temporal (TSDB). TSDB não é um banco de dados separado, mas um pacote na linguagem Go integrado ao Prometheus. Grosso modo, tudo está em um binário.
Não armazene dados no TSDB por muito tempo
A infraestrutura do Prometheus não é adequada para armazenamento de métricas a longo prazo. O período de retenção padrão é de 15 dias. Você pode ultrapassar esse limite, mas lembre-se: quanto mais dados você armazenar no TSDB e quanto mais tempo fizer isso, mais recursos ele consumirá. Armazenar dados históricos no Prometheus é considerado uma má prática.
Se você tiver um tráfego enorme, o número de métricas é de centenas de milhares por segundo, então é melhor limitar seu armazenamento por espaço em disco ou por período. Normalmente, “dados importantes” são armazenados no TSDB, métricas em apenas algumas horas. Para armazenamento mais longo, o armazenamento externo é usado nos bancos de dados realmente adequados para isso, por exemplo, InfluxDB, ClickHouse e assim por diante. Vi mais críticas boas sobre o ClickHouse.
O Prometheus Server funciona no modelo puxar: ele busca métricas para os endpoints que fornecemos a ele. Eles disseram: “vá para o servidor API”, e ele vai lá a cada enésimo número de segundos e pega as métricas.
Para objetos com vida útil curta (job ou cron job) que podem aparecer entre períodos de scraping, existe um componente Pushgateway. Métricas de objetos de curto prazo são inseridas nele: o trabalho foi criado, executou uma ação, enviou métricas ao Pushgateway e foi concluído. Depois de um tempo, o Prometheus seguirá seu próprio ritmo e obterá essas métricas do Pushgateway.
Para configurar notificações no Prometheus existe um componente separado - Gerenciador de alertas. E as regras de alerta. Por exemplo, será necessário criar um alerta se a API do servidor for 0. Quando o evento é acionado, o alerta é passado ao gerenciador de alertas para envio posterior. O gerenciador de alertas possui configurações de roteamento bastante flexíveis: um grupo de alertas pode ser enviado para o chat de telegrama dos administradores, outro para o chat dos desenvolvedores e um terceiro para o chat dos trabalhadores de infraestrutura. As notificações podem ser enviadas para Slack, Telegram, email e outros canais.
E, finalmente, falarei sobre o recurso assassino do Prometheus - Descobrindo. Ao trabalhar com o Prometheus, não é necessário especificar endereços específicos de objetos para monitoramento, basta definir seu tipo. Ou seja, você não precisa escrever “aqui está o endereço IP, aqui está a porta - monitor”, em vez disso, você precisa determinar por quais princípios encontrar esses objetos (tem como alvo - metas). O próprio Prometheus, dependendo de quais objetos estão ativos no momento, seleciona os necessários e os adiciona ao monitoramento.
Essa abordagem se encaixa bem na estrutura do Kubernetes, onde tudo também flutua: hoje são 10 servidores, amanhã 3. Para não especificar o endereço IP do servidor todas as vezes, escreveram uma vez como encontrá-lo - e o Discovering fará isso .
A linguagem Prometheus é chamada PromQL. Usando esta linguagem, você pode obter os valores de métricas específicas e depois convertê-los, construir cálculos analíticos com base neles.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Interface web do Prometheus
O Prometheus possui sua própria interface web bastante minimalista. Adequado apenas para depuração ou demonstração.
Na linha Expressão, você pode escrever uma consulta na linguagem PromQL.
A guia Alertas contém regras de alerta e têm três status:
- inativo - se o alerta não estiver ativo no momento, ou seja, está tudo bem com ele e não funcionou;
- pendente - isto é, se o alerta funcionou, mas o envio ainda não foi aprovado. O atraso é definido para compensar a intermitência da rede: se o serviço especificado aumentar dentro de um minuto, o alarme ainda não deverá soar;
- disparar é o terceiro status quando o alerta acende e envia mensagens.
No menu Status você encontrará acesso a informações sobre o que é o Prometheus. Há também uma transição para metas (metas), das quais falamos acima.
Para uma visão geral mais detalhada da interface do Prometheus, consulte .
Integração com Grafana
Na interface web do Prometheus, você não encontrará gráficos bonitos e compreensíveis dos quais possa tirar uma conclusão sobre o estado do cluster. Para construí-los, o Prometheus está integrado ao Grafana. Temos esses painéis.
Configurar a integração do Prometheus e Grafana não é nada difícil, você encontra instruções na documentação: Bem, vou terminar com isso.
Nos artigos a seguir daremos continuidade ao tema monitoramento: falaremos sobre coleta e análise de logs utilizando Grafana Loki e ferramentas alternativas.
Autor: Marcel Ibraev, administrador certificado do Kubernetes, engenheiro praticante na empresa , palestrante e desenvolvedor do curso Slurm.
Fonte: habr.com