Como o Monitoramento Funciona

O Prometheus Operator observa a criação de ServiceMonitors, PodMonitors e PrometheusRules. Quando os recursos de configuração do Prometheus são criados, o Prometheus Operator chama a API do Prometheus para sincronizar a nova configuração. Como o diagrama no final desta seção mostra, o Prometheus Operator atua como intermediário entre o Prometheus e o Kubernetes, chamando a API do Prometheus para sincronizar o Prometheus com os recursos relacionados a monitoramento no Kubernetes.

ServiceMonitors e PodMonitors especificam de forma declarativa os alvos, como Services e Pods, que precisam ser monitorados.

As PrometheusRules permitem que os usuários definam regras para quais métricas ou consultas ao banco de dados de séries temporais devem resultar em alertas sendo disparados. As regras são avaliadas em um intervalo.

Uma vez que o Prometheus determina que um alerta precisa ser disparado, os alertas são encaminhados para Alertmanager.

Após coletar métricas de exporters, o Prometheus armazena as séries temporais em um banco de dados local de séries temporais em disco. O Prometheus opcionalmente se integra a sistemas remotos, mas rancher-monitoring utiliza armazenamento local para o banco de dados de séries temporais.

Uma vez armazenados, os usuários podem consultar este TSDB usando PromQL, a linguagem de consulta do Prometheus.

As consultas PromQL podem ser visualizadas de duas maneiras:

Regras definem consultas que o Prometheus precisa executar regularmente evaluationInterval para realizar certas ações, como disparar um alerta (regras de alerta) ou pré-computar uma consulta com base em outras existentes em seu TSDB (regras de gravação). Essas regras são codificadas em recursos personalizados PrometheusRules. Quando recursos personalizados PrometheusRule são criados ou atualizados, o Operador Prometheus observa a mudança e chama a API do Prometheus para sincronizar o conjunto de regras que o Prometheus está avaliando atualmente em um intervalo regular.

Um PrometheusRule permite que você defina um ou mais RuleGroups. Cada RuleGroup consiste em um conjunto de objetos Rule que podem representar uma regra de alerta ou uma regra de gravação com os seguintes campos:

Ao avaliar uma regra, o Prometheus executa a consulta PromQL fornecida, adiciona os rótulos fornecidos e executa a ação apropriada para a regra. Se a regra acionar um alerta, o Prometheus também adiciona as anotações fornecidas. Por exemplo, uma regra de alerta que adiciona team: front-end como um rótulo à consulta PromQL fornecida irá anexar esse rótulo ao alerta disparado, o que permitirá que o Alertmanager encaminhe o alerta para o Receptor correto.

O Prometheus não mantém o estado de se os alertas estão ativos. Ele dispara alertas repetidamente a cada intervalo de avaliação, confiando no Alertmanager para agrupar e filtrar os alertas em notificações significativas.

A constante evaluation_interval define com que frequência o Prometheus avalia suas regras de alerta em relação ao banco de dados de séries temporais. Semelhante ao scrape_interval, o evaluation_interval também tem como padrão um minuto.

As regras estão contidas em um conjunto de arquivos de regras. Os arquivos de regras incluem tanto regras de alerta quanto regras de gravação, mas apenas as regras de alerta resultam em alertas sendo disparados após sua avaliação.

Para regras de gravação, o Prometheus executa uma consulta, e então a armazena como uma série temporal. Essa série temporal sintética é útil para armazenar os resultados de uma consulta cara ou demorada, para que possa ser consultada mais rapidamente no futuro.

Regras de alerta são mais comumente usadas. Sempre que uma regra de alerta avalia para um número positivo, o Prometheus dispara um alerta.

O arquivo de regras adiciona rótulos e anotações aos alertas antes de dispará-los, dependendo do caso de uso:

Quando os alertingDrivers estão instalados, isso cria um Service que pode ser usado como a URL do receptor para Teams ou SMS, com base na configuração do alertingDriver. A URL no Receptor aponta para os alertingDrivers; assim, o Alertmanager envia o alerta primeiro para o alertingDriver, e então o alertingDriver encaminha ou envia o alerta para o destino apropriado.

O Alertmanager coordena para onde os alertas são enviados. Ele permite agrupar os alertas com base em rótulos e acioná-los quando certos rótulos corresponderem. Uma rota de nível superior aceita todos os alertas. A partir daí, o Alertmanager continua roteando alertas para receptores com base em se eles correspondem às condições da próxima rota.

Enquanto os formulários da interface do Rancher permitem apenas editar uma árvore de roteamento de dois níveis, você pode configurar estruturas de roteamento mais profundamente aninhadas editando o Secret do Alertmanager.

Ao editar os formulários na interface do Rancher, você pode configurar um recurso Receptor com todas as informações que o Alertmanager precisa para enviar alertas ao seu sistema de notificação.

Ao editar YAML personalizado na configuração do Alertmanager ou do Receptor, você também pode enviar alertas para múltiplos sistemas de notificação. Para mais informações, consulte a seção sobre configuração de Receptores.

Por padrão, um conjunto de recursos curados pelo projeto kube-prometheus é implantado em seu cluster como parte da instalação do Aplicativo de Monitoramento do Rancher para configurar uma pilha básica de Monitoramento/Alerta.

Os recursos que são implantados em seu cluster para suportar esta solução podem ser encontrados no gráfico Helm rancher-monitoring, que acompanha de perto o gráfico Helm kube-prometheus-stack mantido pela comunidade Prometheus, com certas alterações registradas no CHANGELOG.md.

O Monitoramento V2 implanta três exportadores padrão que fornecem métricas adicionais para o Prometheus armazenar:

ServiceMonitors e PodMonitors irão coletar esses exportadores, conforme definido aqui. O Prometheus armazena essas métricas, e você pode consultar os resultados através da interface do Prometheus ou do Grafana.

Veja a seção arquitetura para mais informações sobre regras de gravação, regras de alerta e Alertmanager.

Quando o aplicativo de monitoramento estiver instalado, você poderá editar os seguintes componentes na interface do Rancher:

PushProx permite que o Prometheus colete métricas através de uma fronteira de rede, o que impede que os usuários precisem expor portas de métricas para componentes internos do Kubernetes em cada nó em um cluster Kubernetes.

Como as métricas para componentes do Kubernetes geralmente são expostas na rede host dos nós no cluster, o PushProx implanta um DaemonSet de clientes que ficam na hostNetwork de cada nó e fazem uma conexão de saída para um único proxy que está na API do Kubernetes. O Prometheus pode ser configurado para encaminhar as solicitações de coleta através do proxy para cada cliente, permitindo assim coletar métricas dos componentes internos do Kubernetes sem a necessidade de abrir portas de entrada nos nós.

Consulte Coletando Métricas com PushProx para mais informações.

ServiceMonitors e PodMonitors definem alvos que são destinados ao Prometheus para coleta. O recurso personalizado do Prometheus informa ao Prometheus quais ServiceMonitors ou PodMonitors ele deve usar para descobrir de onde coletar métricas.

O Operador Prometheus observa os ServiceMonitors e PodMonitors. Quando observa que eles são criados ou atualizados, chama a API do Prometheus para atualizar a configuração de coleta no recurso personalizado do Prometheus e mantê-la sincronizada com a configuração de coleta nos ServiceMonitors ou PodMonitors. Esta configuração de coleta informa ao Prometheus quais endpoints coletar métricas e como ele rotulará as métricas desses endpoints.

O Prometheus coleta todas as métricas definidas em sua configuração de coleta a cada scrape_interval, sendo esse intervalo de um minuto por padrão.

A configuração de coleta pode ser visualizada como parte do recurso personalizado do Prometheus que é exposto na interface do Rancher.

A implantação ou o StatefulSet do Prometheus coleta métricas, e a configuração do Prometheus é controlada pelos recursos personalizados do Prometheus. O Operador Prometheus observa os recursos do Prometheus e do Alertmanager, e quando eles são criados, o Operador Prometheus cria uma implantação ou StatefulSet para o Prometheus ou Alertmanager com a configuração definida pelo usuário.

Quando o Operador Prometheus observa a criação de ServiceMonitors, PodMonitors e PrometheusRules, ele sabe que a configuração de raspagem precisa ser atualizada no Prometheus. Ele atualiza o Prometheus primeiro atualizando os arquivos de configuração e regras nos volumes da implantação ou StatefulSet do Prometheus. Em seguida, ele chama a API do Prometheus para sincronizar a nova configuração, fazendo com que a implantação ou o StatefulSet do Prometheus sejam modificados in loco.

O Prometheus coleta métricas de implantações conhecidas como exporters, que exportam os dados de séries temporais em um formato que o Prometheus pode ingerir. No Prometheus, as séries temporais consistem em fluxos de valores com timestamp pertencentes à mesma métrica e ao mesmo conjunto de dimensões rotuladas.

Certos componentes internos do Kubernetes são coletados via um proxy implantado como parte do Monitoramento V2 chamado PushProx. Para informações detalhadas sobre o PushProx, consulte aqui e a seção arquitetura acima.

Os seguintes componentes do Kubernetes são coletados diretamente pelo Prometheus:

As métricas são coletadas de maneira diferente com base na distribuição do Kubernetes. Para ajuda com a terminologia, consulte aqui. Para detalhes, consulte a tabela abaixo: