Avaliação de regras e alertas com recolha gerida

Este documento descreve uma configuração para a avaliação de regras e alertas numa implementação do Managed Service for Prometheus que usa a recolha gerida.

O diagrama seguinte ilustra uma implementação que usa vários clusters em dois Google Cloud projetos e usa a avaliação de regras e alertas, bem como o recurso GlobalRules opcional:

Para configurar e usar uma implementação como a do diagrama, tenha em atenção o seguinte:

• O avaliador de regras geridas é implementado automaticamente em qualquer cluster onde a recolha gerida esteja em execução. Estes avaliadores estão configurados da seguinte forma:

  • Use recursos de regras para executar regras em dados num espaço de nomes. Os recursos de regras têm de ser aplicados em todos os espaços de nomes nos quais quer executar a regra.

  • Use recursos ClusterRules para executar regras em dados num cluster. Os recursos ClusterRules devem ser aplicados uma vez por cluster.

• Toda a avaliação de regras é executada em relação ao repositório de dados global, o Monarch.

  • Os recursos de regras filtram automaticamente as regras para o projeto, a localização, o cluster e o espaço de nomes em que estão instalados.
  • Os recursos ClusterRules filtram automaticamente as regras para o projeto, a localização e o cluster em que estão instalados.
  • Todos os resultados das regras são escritos no Monarch após a avaliação.

• Uma instância do Prometheus AlertManager é implementada manualmente em cada cluster. Os avaliadores de regras geridos são configurados editando o recurso OperatorConfig para enviar regras de alerta acionadas para a respetiva instância local do AlertManager. Os silêncios, as confirmações e os fluxos de trabalho de gestão de incidentes são normalmente processados numa ferramenta de terceiros, como o PagerDuty.

  Pode centralizar a gestão de alertas em vários clusters num único AlertManager através de um recurso de pontos finais do Kubernetes.

O diagrama anterior também mostra o recurso GlobalRules opcional. Use GlobalRules com muita moderação para tarefas como calcular SLOs globais em projetos ou para avaliar regras em clusters num único Google Cloud projeto. Recomendamos vivamente que use regras e regras de cluster sempre que possível; estes recursos oferecem uma fiabilidade superior e são mais adequados para mecanismos de implementação e modelos de posse comuns do Kubernetes.

Se usar o recurso GlobalRules, tenha em atenção o seguinte no diagrama anterior:

• Um único cluster em execução no interior Google Cloud é designado como o cluster de avaliação de regras global para um âmbito de métricas. Este avaliador de regras gerido está configurado para usar o scoping_project_A, que contém os projetos 1 e 2. As regras executadas em relação a scoping_project_A são automaticamente distribuídas aos projetos 1 e 2.

  A conta de serviço subjacente tem de ter as autorizações de Visualizador de monitorização para scoping_project_A. Para mais informações sobre como definir estes campos, consulte o artigo Avaliação de regras globais e de vários projetos.

• Tal como em todos os outros clusters, este avaliador de regras está configurado com recursos Rules e ClusterRules que avaliam regras com âmbito num espaço de nomes ou num cluster. Estas regras são filtradas automaticamente para o projeto local, neste caso, o Projeto 1. Uma vez que scoping_project_A contém o projeto 1, as regras configuradas de Rules e ClusterRules são executadas apenas em relação aos dados do projeto local, conforme esperado.

• Este cluster também tem recursos GlobalRules que executam regras em relação a scoping_project_A. As GlobalRules não são filtradas automaticamente e, por isso, são executadas exatamente como escritas em todos os projetos, localizações, clusters e espaços de nomes em scoping_project_A.

• As regras de alerta acionadas são enviadas para o AlertManager alojado por si, conforme esperado.

A utilização de GlobalRules pode ter efeitos inesperados, consoante preserve ou agregue as etiquetas project_id, location, cluster e namespace nas suas regras:

• Se a regra GlobalRules preservar a etiqueta project_id (através da utilização de uma cláusula by(project_id)), os resultados da regra são reescritos para o Monarch através do valor project_id original da série cronológica subjacente.

  Neste cenário, tem de garantir que a conta de serviço subjacente tem as autorizações de Escritor de métricas de monitorização para cada projeto monitorizado em scoping_project_A. Se adicionar um novo projeto monitorizado a scoping_project_A, também tem de adicionar manualmente uma nova autorização à conta de serviço.

• Se a sua regra GlobalRules não preservar a etiqueta project_id (por não usar uma cláusula by(project_id)), os resultados da regra são reescritos no Monarch usando o valor project_id do cluster onde o avaliador de regras globais está a ser executado.

  Neste cenário, não precisa de modificar mais a conta de serviço subjacente.

• Se o seu GlobalRules preservar a etiqueta location (através da utilização de uma cláusula by(location)), os resultados das regras são reescritos para o Monarch através de cada região Google Cloud original a partir da qual a série cronológica subjacente se originou.

  Se o GlobalRules não preservar a etiqueta location, os dados são escritos novamente na localização do cluster onde o avaliador da regra global está a ser executado.

Recomendamos vivamente que preserve as etiquetas cluster e namespace nos resultados da avaliação de regras, a menos que o objetivo da regra seja agregar essas etiquetas. Caso contrário, o desempenho das consultas pode diminuir e pode encontrar limites de cardinalidade. A remoção de ambas as etiquetas é fortemente desaconselhada.