Avaliação de regras e alertas com recolha implementada automaticamente

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 implementada automaticamente.

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:

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

• As regras são instaladas em cada servidor de recolha do Managed Service for Prometheus, tal como acontece quando usa o Prometheus padrão. A avaliação de regras é executada com base nos dados armazenados localmente em cada servidor. Os servidores estão configurados para reter dados durante tempo suficiente para abranger o período de análise de todas as regras, que normalmente não excede 1 hora. 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 servidores Prometheus são configurados editando o campo alertmanager_config do ficheiro de configuração para enviar regras de alerta acionadas para a respetiva instância do AlertManager local. 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.

• Um único cluster em execução no Google Cloud é designado como o cluster de avaliação de regras global para um âmbito de métricas. O avaliador de regras autónomo é implementado nesse cluster e as regras são instaladas através do formato de ficheiro de regras padrão do Prometheus.

  O avaliador de regras autónomo está configurado para usar 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. É necessário conceder à conta de serviço subjacente as autorizações de Leitor de monitorização para scoping_project_A.

  O avaliador de regras está configurado para enviar alertas para o Alertmanager do Prometheus local através do campo alertmanager_config do ficheiro de configuração.

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

• Se as suas regras preservarem a etiqueta project_id (através de uma cláusula by(project_id)), os resultados das regras são reescritos no Monarch com o 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 as suas regras não preservarem a etiqueta project_id (por não usarem uma cláusula by(project_id)), os resultados das regras são reescritos no Monarch através do valor project_id do cluster onde o avaliador de regras global está a ser executado.

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

• Se as suas regras preservarem a etiqueta location (através de uma cláusula by(location)), os resultados das regras são reescritos no Monarch usando cada região Google Cloud original de onde a série cronológica subjacente se originou.

  Se as suas regras não preservarem a etiqueta location, os dados são escritos novamente na localização do cluster onde o avaliador de regras global está a ser executado.

Recomendamos vivamente que preserve as etiquetas cluster e namespace nos resultados da avaliação de regras sempre que possível. Caso contrário, o desempenho das consultas pode diminuir e pode encontrar limites de cardinalidade. Desaconselhamos vivamente a remoção de ambas as etiquetas.