Como criar políticas de alerta

Nesta página, mostramos como criar políticas de alertas para clusters do Google Distributed Cloud.

Antes de começar

Para criar políticas de alertas, é necessário ter as seguintes permissões:

• monitoring.alertPolicies.create
• monitoring.alertPolicies.delete
• monitoring.alertPolicies.update

Você terá essas permissões se tiver um dos seguintes papéis:

• monitoring.alertPolicyEditor
• monitoring.editor
• Editor do projeto
• Proprietário do projeto

Para criar uma política de alertas com base em registros usando a CLI do Google Cloud, o papel serviceusage.serviceUsageConsumer também é necessário.

Para verificar seus papéis, acesse a página do IAM no console do Google Cloud.

Como criar uma política de exemplo: servidor da API indisponível

Neste exercício, crie uma política de alertas para os servidores da API Kubernetes. Com essa política em vigor, é possível ser notificado sempre que o servidor da API de um cluster ficar inativo.

1. Faça o download do arquivo de configuração da política: apiserver-unavailable.json.

2. Crie a política:

   gcloud alpha monitoring policies create --policy-from-file=POLICY_CONFIG
   

   Substitua POLICY_CONFIG pelo caminho do arquivo de configuração que você acabou de receber.

3. Veja suas políticas de alertas:

   Console

   1. No Console do Google Cloud, acesse a página Monitoring.

      Acessar Monitoring

   2. À esquerda, selecione Alertas.

   3. Em Políticas, é possível ver uma lista das suas políticas de alertas.

      Na lista, selecione Servidor da API do cluster do Anthos indisponível (crítico) para conferir detalhes sobre a nova política. Em Condições, você pode ver uma descrição da política. Por exemplo:

      Policy violates when ANY condition is met
      Anthos cluster API server uptime is absent for 5m
      

   gcloud

   gcloud alpha monitoring policies list

   A resposta mostra informações detalhadas sobre a política. Por exemplo:

   combiner: OR
   conditions:
   - conditionAbsent:
       aggregations:
       - alignmentPeriod: 60s
         crossSeriesReducer: REDUCE_MEAN
         groupByFields:
         - resource.label.project_id
         - resource.label.location
         - resource.label.cluster_name
         - resource.label.namespace_name
         - resource.label.container_name
         - resource.label.pod_name
         perSeriesAligner: ALIGN_MAX
       duration: 300s
       filter: resource.type = "k8s_container" AND metric.type = "kubernetes.io/anthos/container/uptime"
         AND resource.label."container_name"=monitoring.regex.full_match("kube-apiserver")
       trigger:
         count: 1
     displayName: Anthos cluster API server uptime is absent for 5m
     name: projects/…/alertPolicies/…/conditions/…
   displayName: Anthos cluster API server unavailable (critical)
   enabled: true
   mutationRecord:
     mutateTime: …
     mutatedBy: …
   name: projects/…/alertPolicies/…
   

Como criar outras políticas de alertas

Nesta seção, fornecemos descrições e arquivos de configuração para um conjunto de políticas de alertas recomendadas.

Para criar uma política, siga as mesmas etapas usadas no exercício anterior:

1. Clique no link na coluna à direita para fazer o download do arquivo de configuração.

2. Também é possível ajustar as condições para atender melhor às suas necessidades específicas. Por exemplo, adicione outros filtros para um subconjunto de clusters ou ajuste os valores de limite para equilibrar o ruído e a criticidade.

3. Execute gcloud alpha monitoring policies create para criar a política.

Disponibilidade dos componentes do plano de controle

Nome do alerta	Descrição	Definição da política de alertas no Cloud Monitoring
Servidor da API indisponível (crítico)	A métrica de tempo de atividade do servidor de API não está disponível	apiserver-unavailable.json
Programador indisponível (crítico)	A métrica de tempo de atividade do programador não está disponível	scheduler-unavailable.json
Gerenciador do controlador indisponível (crítico)	A métrica de tempo de atividade do gerenciador do controlador não está disponível	controller-manager-unavailable.json

Sistema Kubernetes

Nome do alerta	Descrição	Definição da política de alertas no Cloud Monitoring
Repetição de falha do pod (alerta)	O pod continua reiniciando e pode estar com um status de repetição de falha	pod-crash-looping.json
O pod está há mais de uma hora em um estado não pronto (crítico).	O pod leva mais de uma hora para ficar pronto	pod-not-ready-1h.json
O uso da CPU do contêiner excede 80% (alerta)	O uso da CPU do contêiner está 80% acima do limite	container-cpu-usage-high-reaching-limit.json
O uso da memória do contêiner excede 85% (alerta)	O uso da memória do contêiner está 85% acima do limite	container-memory-usage-high-reaching-limit.json
Uso elevado do volume persistente (crítico)	O volume persistente reivindicado tem menos de 3% de espaço livre	persistent-volume-usage-high.json
O uso da CPU do nó excede 80% (alerta)	O uso da CPU do nó é superior a 80% do total alocável por 5 minutos	node-cpu-usage-high.json
O uso do disco do nó excede 85% (alerta)	Menos de 15% está disponível por ponto de montagem de disco por 10 minutos	node-disk-usage-high.json
O uso da memória do nó excede 80% (alerta)	O uso da memória do nó é superior a 80% do total alocável por 5 minutos	node-memory-usage-high.json
O nó não está pronto há mais de uma hora (crítico)	O nó leva mais de uma hora para ficar pronto	node-not-ready-1h.json

Desempenho do Kubernetes

Nome do alerta	Descrição	Definição da política de alertas no Cloud Monitoring
A proporção de erros de servidor da API excede 20% (crítico)	O servidor da API gera erros 5xx ou 429 em mais de 20% de todas as solicitações por verbo por 15 minutos	apiserver-error-ratio-high.json
A mudança de líder do ETCD ou a falha na proposta é muito frequente (alerta)	As mudanças de líder ou falhas de proposta do etcd acontecem com muita frequência	etcd-leader-changes-or-proposal-failures-frequent.json
O servidor ETCD não está no quórum (crítico)	As propostas do servidor etcd não foram confirmadas por 5 minutos, então elas podem ter perdido o quórum	etcd-server-not-in-quorum.yaml
O armazenamento ETCD excede o limite de 90% (alerta)	O uso do armazenamento etcd é superior a 90% do limite	etcd-storage-usage-high.json

Políticas de alertas com o PromQL

As consultas em políticas de alertas também podem ser expressas em PromQL em vez de MQL. Por exemplo, a versão PromQL da política API server error ratio exceeds 20 percent (critical) está disponível para download: apiserver-error-ratio-high-promql.json.

Para mais informações, consulte Usar o serviço gerenciado para Prometheus na documentação do Google Distributed Cloud e Políticas de alertas com PromQL na documentação do Cloud Monitoring.

Como receber notificações

Depois de criar uma política de alertas, é possível definir um ou mais canais de notificação para essa política. Há vários tipos de canais de notificação. Por exemplo, é possível ser notificado por e-mail, um canal do Slack ou um app para dispositivos móveis. Você pode escolher os canais mais adequados.

Para instruções sobre como configurar canais de notificação, consulte Como gerenciar canais de notificação.