Avaliação de regras e alertas com coleta gerenciada
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento descreve uma configuração de avaliação de regras e alertas
em uma implantação do Managed Service para Prometheus que usa
coleta gerenciada.
O diagrama a seguir ilustra uma implantação que usa vários clusters
em dois projetos Google Cloud e utiliza a avaliação de regras e alertas, bem como
o recurso opcional GlobalRules:
Para configurar e usar uma implantação como a do diagrama, lembre-se de que:
O avaliador de regras gerenciadas é implantado
automaticamente nos clusters em que a coleta gerenciada está em execução. Esses avaliadores são configurados da seguinte maneira:
Use recursos Rules para executar regras em dados
dentro de um namespace. Os recursos Rules precisam ser aplicados a todos os namespaces em que você quer executar a regra.
Use recursos ClusterRules para executar regras em dados de um cluster. Os recursos ClusterRules precisam ser aplicados
uma vez por cluster.
Toda a avaliação de regras é executada no repositório de dados global,
o Monarch.
Os recursos Rules filtram automaticamente as regras no projeto, no local, no cluster e no namespace em que estão instalados.
Os recursos ClusterRules filtram automaticamente as regras para o projeto, o local e o cluster em que estão instalados.
Todos os resultados de regra são gravados no Monarch após a avaliação.
Uma instância AlertManager do Prometheus é implantada manualmente em cada cluster. Os avaliadores de regras gerenciadas são configurados com a edição do
recurso OperatorConfig para enviar regras de alerta
acionadas para a instância local do AlertManager. Silenciamentos, confirmações e fluxos de trabalho de gerenciamento de incidentes em geral são processados em uma ferramenta de terceiros, como o PagerDuty.
É possível centralizar o gerenciamento de alertas em vários clusters em um único AlertManager com um recurso do Endpoints do Kubernetes.
O diagrama anterior também mostra o recurso opcional
GlobalRules.
Use GlobalRules com moderação, para tarefas como
cálculo de SLOs globais em projetos ou avaliação de regras em
clusters em um projeto Google Cloud .
É altamente recomendável usar Rules e ClusterRules sempre que possível.
Esses recursos oferecem maior confiabilidade e são mais adequados para
mecanismos de implantação e modelos de locação comuns do Kubernetes.
Se você usa o recurso GlobalRules, observe o seguinte no diagrama anterior:
Um único cluster em execução no Google Cloud é designado como o
cluster de avaliação de regra global para um escopo de métricas. Esse avaliador de regras
gerenciadas está configurado para usar scoping_project_A, que contém
os projetos 1 e 2. As regras executadas em scoping_project_A
distribuem dados automaticamente para os projetos 1 e 2.
Assim como em todos os outros clusters, esse avaliador de regras é configurado com recursos
Rules e ClusterRules que avaliam regras com escopo para um namespace
ou cluster. Essas regras são filtradas automaticamente para o projeto local
— Projeto 1, neste caso. Como scoping_project_A
contém o Projeto 1, as regras configuradas por Rules e ClusterRules são executadas
somente com base nos dados do projeto local, conforme o esperado.
Esse cluster também tem recursos GlobalRules que executam regras em
scoping_project_A. GlobalRules não são filtradas automaticamente. Portanto, são executadas exatamente como foram gravadas em todos os projetos, locais, clusters e namespaces em scoping_project_A.
As regras de alertas disparadas serão enviadas ao AlertManager auto-hospedado conforme
esperado.
O uso de GlobalRules pode ter efeitos inesperados, dependendo se você preserva ou agrega os identificadores project_id, location, cluster e namespace nas regras:
Se a regra GlobalRegras preservar o identificador project_id com uma
cláusula by(project_id), os resultados da regra serão gravados no
Monarch usando o valor project_id original da
série temporal subjacente.
Nesse cenário, você precisa garantir que a conta de serviço subjacente tenha as permissões de Gravador de métricas do Monitoring para cada projeto monitorado em scoping_project_A. Se você adicionar um novo
projeto monitorado a scoping_project_A, também precisará adicionar
manualmente uma nova permissão à conta de serviço.
Se a regra GlobalRules não preservar o identificador project_id (sem o uso de
uma cláusula by(project_id)), os resultados da regra são gravados
na Monarch usando o valor project_id do cluster em que o avaliador de regras global está em execução.
Nesse cenário, não é preciso modificar a conta de serviço.
Se a regra GlobalRules preservar o identificador location com uma cláusula by(location), os resultados da regra serão gravados no Monarch usando cada região Google Cloud original de onde a série temporal subjacente se originou.
Se GlobalRules não preservar o identificador location, os dados serão gravados
no local do cluster em que o avaliador de regras global
está em execução.
É altamente recomendável preservar os identificadores cluster e namespace nos resultados da avaliação de regras, a menos que a finalidade da regra seja agregar esses identificadores. Caso contrário, o desempenho da consulta
poderá diminuir e você poderá encontrar limites de cardinalidade. Não é indicado remover os dois rótulos.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["# Evaluation of rules and alerts with managed collection\n\nThis document describes a configuration for rule and alert evaluation\nin a Managed Service for Prometheus deployment that uses\n[managed collection](/stackdriver/docs/managed-prometheus/setup-managed).\n\nThe following diagram illustrates a deployment that uses multiple clusters\nin two Google Cloud projects and uses both rule and alert evaluation, as well\nas the optional GlobalRules resource:\n\nTo set up and use a deployment like the one in the diagram, note the\nfollowing:\n\n- The [managed rule evaluator](/stackdriver/docs/managed-prometheus/rules-managed) is automatically\n deployed in any cluster where managed collection is running. These\n evaluators are configured as follows:\n\n - Use [Rules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#rules) resources to run rules on data\n within a namespace. Rules resources must be applied in every namespace\n in which you want to execute the rule.\n\n - Use [ClusterRules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#clusterrules) resources to run\n rules on data across a cluster. ClusterRules resources should be applied\n once per cluster.\n\n- All rule evaluation executes against the global datastore,\n Monarch.\n\n - Rules resources automatically filter rules to the project, location, cluster, and namespace in which they are installed.\n - ClusterRules resources automatically filter rules to the project, location, and cluster in which they are installed.\n - All rule results are written to Monarch after evaluation.\n- A Prometheus AlertManager instance is manually deployed in every single\n cluster. Managed rule evaluators are configured by [editing the\n OperatorConfig resource](/stackdriver/docs/managed-prometheus/rules-managed#am-config-managed) to send fired alerting\n rules to their local AlertManager instance. Silences, acknowledgements, and\n incident management workflows are typically handled in a third-party tool\n such as PagerDuty.\n\n You can centralize alert management across multiple clusters into a\n single AlertManager by using a Kubernetes\n [Endpoints resource](/stackdriver/docs/managed-prometheus/rules-managed#am-config-managed).\n\nThe preceding diagram also shows the optional\n[GlobalRules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#globalrules) resource.\nUse GlobalRules very sparingly, for tasks like\ncalculating global SLOs across projects or for evaluating rules across\nclusters within a single Google Cloud project.\n**We strongly recommend using Rules and ClusterRules whenever possible**;\nthese resources provide superior reliability and are better fits for\ncommon Kubernetes deployment mechanisms and tenancy models.\n\nIf you use the GlobalRules resource, note the following from the\npreceding diagram:\n\n- One single cluster running inside Google Cloud is designated as the\n global rule-evaluation cluster for a metrics scope. This managed rule\n evaluator is configured to use scoping_project_A, which contains\n Projects 1 and 2. Rules executed against scoping_project_A automatically\n fan out to Projects 1 and 2.\n\n The underlying service account must be given the [Monitoring\n Viewer](/monitoring/access-control#mon_roles_desc) permissions for scoping_project_A.\n For additional information on how to set these fields, see\n [Multi-project and global rule evaluation](/stackdriver/docs/managed-prometheus/rules-managed#multi-project_and_global_rule_evaluation).\n- As in all other clusters, this rule evaluator is set up with Rules\n and ClusterRules resources that evaluate rules scoped to a namespace\n or cluster. These rules are automatically filtered to the *local*\n project---Project 1, in this case. Because scoping_project_A\n contains Project 1, Rules and ClusterRules-configured rules execute\n only against data from the local project as expected.\n\n- This cluster also has GlobalRules resources that execute rules against\n scoping_project_A. GlobalRules are not automatically filtered, and\n therefore GlobalRules execute exactly as written across all projects,\n locations, clusters, and namespaces in scoping_project_A.\n\n- Fired alerting rules will be sent to the self-hosted AlertManager as\n expected.\n\nUsing GlobalRules may have unexpected effects, depending on whether you\npreserve or aggregate the `project_id`, `location`, `cluster`, and\n`namespace` labels in your rules:\n\n- If your GlobalRules rule preserves the `project_id` label (by using\n a `by(project_id)` clause), then rule results are written back to\n Monarch using the original `project_id` value of the underlying\n time series.\n\n In this scenario, you need to ensure the underlying service account\n has the [Monitoring Metric Writer](/monitoring/access-control#mon_roles_desc) permissions for each\n monitored project in scoping_project_A. If you add a new\n monitored project to scoping_project_A, then you must also manually\n add a new permission to the service account.\n- If your GlobalRules rule does not preserve the `project_id` label (by\n not using a `by(project_id)` clause), then rule results are written back\n to Monarch using the `project_id` value of the cluster\n where the global rule evaluator is running.\n\n In this scenario, you do not need to further modify the underlying\n service account.\n- If your GlobalRules preserves the `location` label (by using a\n `by(location)` clause), then rule results are written back to\n Monarch using each original Google Cloud region from which\n the underlying time series originated.\n\n If your GlobalRules does not preserve the `location` label, then data\n is written back to the location of the cluster where the global rule\n evaluator is running.\n\nWe strongly recommend preserving the `cluster` and `namespace` labels in\nrule evaluation results unless the purpose of the rule is to aggregate away\nthose labels. Otherwise, query performance might decline and you might\nencounter cardinality limits. Removing both labels is strongly discouraged."]]
