Nesta página, mostramos como criar políticas de alertas com base em métricas para clusters do Google Distributed Cloud. Fornecemos vários exemplos para download para ajudar você a configurar políticas de alerta para cenários comuns. Para mais informações sobre políticas de alertas baseadas em métricas, consulte Criar políticas de alertas de limite de métrica na documentação da Observabilidade do Google 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
Se você quiser criar políticas de alertas com base em registros usando a
CLI do Google Cloud, também precisará ter o papel serviceusage.serviceUsageConsumer
. Para instruções sobre como configurar políticas de alertas com base em registros, consulte
Configurar alertas com base em registros
na documentação do Google Cloud Observability.
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, você cria uma política de alertas para os servidores da API Kubernetes dos clusters. Com essa política em vigor, é possível ser notificado sempre que o servidor da API de um cluster ficar inativo.
Faça o download do arquivo de configuração da política: apiserver-unavailable.json.
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.
Veja suas políticas de alertas:
Console
No Console do Google Cloud, acesse a página Monitoring.
À esquerda, selecione Alertas.
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:
Para fazer o download do arquivo de configuração, clique no link na coluna da direita.
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.
Para criar a política, execute
gcloud alpha monitoring policies create
.
É possível fazer o download e instalar todos os exemplos de política de alertas descritos neste documento com o seguinte script:
# 1. Create a directory named alert_samples:
mkdir alert_samples && cd alert_samples
declare -a alerts=("apiserver-unavailable.json" "controller-manager-unavailable.json" "scheduler-unavailable.json" \
"pod-crash-looping.json" "pod-not-ready-1h.json" "container-cpu-usage-high-reaching-limit.json" \
"container-memory-usage-high-reaching-limit.json" "persistent-volume-usage-high.json" "node-cpu-usage-high.json" \
"node-disk-usage-high.json" "node-memory-usage-high.json" "node-not-ready-1h.json" "apiserver-error-ratio-high.json" \
"etcd-leader-changes-or-proposal-failures-frequent.json" "etcd-server-not-in-quorum.yaml" "etcd-storage-usage-high.json")
# 2. Download all alert samples into the alert_samples/ directory:
for x in "${alerts[@]}"
do
wget https://cloud.google.com/kubernetes-engine/distributed-cloud/bare-metal/docs/samples/${x}
done
# 3. (optional) Uncomment and provide your project ID to set the default project
# for gcloud commands:
# gcloud config set project <PROJECT_ID>
# 4. Create alert policies for each of the downloaded samples:
for x in "${alerts[@]}"
do
gcloud alpha monitoring policies create --policy-from-file=${x}
done
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.