Esta página foi traduzida pela API Cloud Translation.

Resolução de problemas de observabilidade

Este documento descreve como identificar falhas de implementação e incidentes operacionais que pode encontrar no dispositivo isolado do Google Distributed Cloud (GDC) e contém descrições de todos os alertas apresentados no sistema para ajudar a resolver problemas comuns com os componentes de registo e monitorização.

Identifique os componentes de observabilidade

A plataforma de observabilidade implementa os respetivos componentes no espaço de nomes obs-system no cluster de infraestrutura da organização.

A instância do Grafana do operador de infraestrutura (IO) fornece acesso a métricas ao nível da organização para monitorizar componentes de infraestrutura, como a utilização da CPU e o consumo de armazenamento. Também fornece acesso a registos de auditoria e operacionais. Além disso, dá acesso a alertas, registos e métricas dos componentes operáveis do GDC.

As stacks de monitorização e registo da GDC usam soluções de código aberto como parte da plataforma de observabilidade. Estes componentes recolhem registos e métricas de pods do Kubernetes, máquinas bare metal, comutadores de rede, armazenamento e serviços geridos.

A tabela seguinte contém uma descrição de todos os componentes que integram a plataforma de observabilidade:

Componente	Descrição
`Prometheus`	O Prometheus é uma base de dados de séries cronológicas para recolher e armazenar métricas e avaliar alertas. O Prometheus armazena métricas na instância do Cortex do cluster de infraestrutura da organização para armazenamento a longo prazo. O Prometheus adiciona etiquetas como pares de chave-valor e recolhe métricas de nós do Kubernetes, pods, máquinas de metal nu, comutadores de rede e dispositivos de armazenamento.
`Alertmanager`	O Alertmanager é um sistema de gestão definido pelo utilizador que envia alertas quando os registos ou as métricas indicam que os componentes do sistema falham ou não funcionam normalmente. Gerem o encaminhamento, o silenciamento e a agregação de alertas do Prometheus.
`Loki`	O Loki é uma base de dados de séries temporais que armazena e agrega registos de várias origens. Indexa os registos para consultas eficientes.
`Grafana`	O Grafana oferece uma interface do utilizador (IU) para ver as métricas que o Prometheus recolhe e consultar os registos de auditoria e operacionais das instâncias do Loki correspondentes. A IU permite-lhe visualizar painéis de controlo de métricas e alertas.
`Fluent Bit`	O Fluent Bit é um processador que extrai registos de vários componentes ou localizações e envia-os para o Loki. É executado em todos os nós de todos os clusters.

Identifique falhas de implementação

Se a implementação estiver em execução e em bom estado, os componentes são executados no estado READY.

Siga os passos abaixo para identificar falhas de implementação:

Confirme o estado atual de um componente:
```
kubectl get -n obs-system TYPE/COMPONENT
```
Substitua o seguinte:
- TYPE: o tipo de componente
- COMPONENT: o nome do componente
Recebe um resultado semelhante ao seguinte:
```
NAME       READY  AGE
COMPONENT  1/1    23h
```
Se o componente estiver em bom estado, a coluna READY do resultado mostra N/N como valor. Se a coluna READY não apresentar um valor, não indica necessariamente uma falha. O serviço pode precisar de mais tempo para processar.
Verifique os pods em cada componente:
```
kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'
```
Substitua COMPONENT pelo nome do componente.

Recebe um resultado semelhante ao seguinte:
```
NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h
```
Verifique se a coluna READY apresenta N/N como valor, a coluna STATUS apresenta um valor Running e o número de RESTARTS não excede o valor de 2.

Um número elevado de reinícios indica os seguintes sintomas:
- Os pods falham e o Kubernetes reinicia-os.
- A coluna STATUS mostra o valor CrashLoopBackoff.
Para resolver o estado de falha, veja os registos dos pods.

Se um pod estiver no estado PENDING, este estado indica um ou mais dos seguintes sintomas:
- O pod está a aguardar o acesso à rede para transferir o contentor necessário.
- Um problema de configuração impede o início do pod. Por exemplo, falta um valor Secret que o pod requer.
- O seu cluster do Kubernetes ficou sem recursos para agendar o pod, o que ocorre se muitas aplicações estiverem a ser executadas no cluster.
Determine a causa de um estado PENDING:
```
kubectl describe -n obs-system pod/POD_NAME
```
Substitua POD_NAME pelo nome do pod que mostra o estado PENDING.

A saída mostra mais detalhes sobre o pod.

Navegue para a secção Events do resultado para ver uma tabela com os eventos recentes do pod e um resumo sobre a causa do estado PENDING.

A saída seguinte mostra uma secção Events de exemplo para um objeto StatefulSet do Grafana:

Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful

Se não existirem eventos no seu pod ou noutro recurso durante um período prolongado, recebe o seguinte resultado:

  Events:         <none>

Verifique se a pilha de registo de observabilidade está em execução

Siga os passos seguintes para verificar se a pilha de registo está em execução:

Verifique se todas as instâncias ou pods do Loki têm o sidecar do Istio injetado. Verifique se todos os pods do Fluent Bit com os nomes anthos-audit-logs-forwarder-SUFFIX e anthos-log-forwarder-SUFFIX têm o sidecar do Istio injetado.
Verifique se todas as instâncias do Loki estão a ser executadas sem erros no cluster de infraestrutura da organização.
Verifique o estado dos objetos anthos-audit-logs-forwarder e anthos-log-forwarder DaemonSet para confirmar que todas as instâncias estão a ser executadas em todos os nós sem erros.
Verifique se recebe os registos operacionais dos contentores kube-apiserver-SUFFIX e os registos de auditoria do servidor da API Kubernetes nos últimos cinco minutos em todos os clusters. Para o fazer, execute as seguintes consultas na instância do Grafana:
- Registos operacionais: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
- Registos de auditoria: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)
Tem de obter valores diferentes de zero para todos os nós do plano de controlo no cluster de infraestrutura da organização.

Verifique se a pilha de monitorização de observabilidade está em execução

Siga os passos abaixo para verificar se a pilha de monitorização está em execução:

Verifique se as instâncias do Grafana estão a ser executadas no cluster de infraestrutura da organização. Os pods grafana-0 têm de ser executados sem erros nos seguintes espaços de nomes:
- obs-system
- infra-obs-obs-system
- platform-obs-obs-system
Nota: outros espaços de nomes PROJECT_NAMESPACE-obs-system podem executar instâncias do Grafana. As instâncias variam consoante o cluster.

Certifique-se de que todos os componentes de monitorização estão na malha de serviços do Istio. Siga os passos da secção Identifique falhas de implementação. Cada um dos seguintes pods tem de mostrar que todos os contentores estão prontos na coluna READY. Por exemplo, um valor de 3/3 significa que três contentores em três estão prontos. Além disso, os pods têm de ter um contentor istio-proxy. Se os pods não cumprirem estas condições, reinicie o pod:

Nome do agrupamento	Número de contentores prontos
`cortex-`	`2/2`
`cortex-etcd-0`	`2/2`
`cortex-proxy-server-`	`2/2`
`cortex-tenant-`	`2/2`
`meta-blackbox-exporter-`	`2/2`
`meta-grafana-0`	`3/3`
`meta-grafana-proxy-server-`	`2/2`
`meta-prometheus-0`	`4/4`
`cortex-alertmanager-`	`2/2`
`cortex-compactor-`	`2/2`
`cortex-distributor-`	`2/2`
`cortex-etcd-0`	`2/2`
`cortex-ingester-`	`2/2`
`cortex-querier-`	`2/2`
`cortex-query-frontend-`	`2/2`
`cortex-query-scheduler-`	`2/2`
`cortex-ruler-`	`2/2`
`cortex-store-gateway-`	`2/2`
`cortex-tenant-`	`2/2`
`grafana-proxy-server-`	`2/2`
`meta-blackbox-exporter-`	`2/2`
`meta-grafana-0`	`3/3`
`meta-grafana-proxy-server-*`	`2/2`
`meta-prometheus-0`	`4/4`

Certifique-se de que o Cortex está a ser executado sem erros.

Obtenha registos de observabilidade

A tabela seguinte contém os comandos que tem de executar para obter os registos de cada um dos componentes implementados pela plataforma de observabilidade.

Componente	Comando de obtenção de registos
`grafana`	`kubectl logs -n obs-system statefulset/grafana`
`anthos-prometheus-k8s`	`kubectl logs -n obs-system statefulset/anthos-prometheus-k8s`
`alertmanager`	`kubectl logs -n obs-system statefulset/alertmanager`
`ops-logs-loki-io`	`kubectl logs -n obs-system statefulset/ops-logs-loki-io`
`ops-logs-loki-io-read`	`kubectl logs -n obs-system statefulset/ops-logs-loki-io-read`
`ops-logs-loki-all`	`kubectl logs -n obs-system statefulset/ops-logs-loki-all`
`ops-logs-loki-all-read`	`kubectl logs -n obs-system statefulset/ops-logs-loki-all-read`
`audit-logs-loki-io`	`kubectl logs -n obs-system statefulset/audit-logs-loki-io`
`audit-logs-loki-io-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-io-read`
`audit-logs-loki-pa`	`kubectl logs -n obs-system statefulset/audit-logs-loki-pa`
`audit-logs-loki-pa-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read`
`audit-logs-loki-all`	`kubectl logs -n obs-system statefulset/audit-logs-loki-all`
`audit-logs-loki-all-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-all-read`
`anthos-log-forwarder`	`kubectl logs -n obs-system daemonset/anthos-log-forwarder`
`anthos-audit-logs-forwarder`	`kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder`
`oplogs-forwarder`	`kubectl logs -n obs-system daemonset/oplogs-forwarder`
`logmon-operator`	`kubectl logs -n obs-system deployment/logmon-operator`

Para ver os registos da instância anterior de um componente, adicione a flag -p no final de cada comando. A adição da flag -p permite-lhe rever os registos de uma instância com falhas anterior em vez da instância em execução atual.

Veja a configuração

A pilha de observabilidade usa recursos personalizados da API Kubernetes para configurar pipelines de monitorização e registo.

O recurso personalizado LoggingPipeline é implementado no cluster de infraestrutura da organização e configura instâncias do Loki.

Os comandos seguintes mostram as ações disponíveis que pode realizar no pipeline de registo:

Veja a configuração atual da implementação do pipeline de registo:
```
kubectl get loggingpipeline -n obs-system default -o yaml
```
Altere a configuração da implementação do pipeline de registo:
```
kubectl edit loggingpipeline -n obs-system default
```

O GDC usa um operador de registo e monitorização denominado logmon-operator para gerir a implementação de componentes de observabilidade, como o Prometheus e o Fluent Bit. A API para o componente logmon-operator é a definição de recurso personalizado logmon. A definição de recursos personalizados logmon indica ao logmon-operator como configurar a observabilidade para a sua implementação. Esta definição de recurso personalizado inclui as propriedades dos volumes para armazenar as suas métricas, regras de alerta para o Alertmanager, configurações do Prometheus para recolher métricas e configurações do Grafana para painéis de controlo.

Os seguintes comandos mostram as ações disponíveis que pode realizar na definição de recursos personalizados logmon:

Veja a configuração atual da sua implementação da observabilidade:
```
kubectl get logmon -n obs-system logmon-default -o yaml
```
Altere a configuração da implementação da observabilidade:
```
kubectl edit logmon -n obs-system logmon-default
```

O resultado da execução de qualquer um dos comandos pode fazer referência a vários objetos Kubernetes ConfigMap para configuração adicional. Por exemplo, pode configurar regras do Alertmanager num objeto ConfigMap separado, que é referenciado na definição de recursos personalizados logmon pelo nome. Pode alterar e ver a configuração do Alertmanager através da definição de recursos personalizados denominada gpc-alertmanager-config.logmon

Para ver a configuração do Alertmanager, execute:

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

Problemas comuns

Esta secção contém problemas comuns que pode enfrentar ao implementar a plataforma de observabilidade.

Não pode aceder ao Grafana

Por predefinição, o Grafana não está exposto a máquinas externas ao seu cluster do Kubernetes. Para aceder temporariamente à interface do Grafana a partir de fora do cluster de infraestrutura da organização, pode encaminhar a porta Service para localhost. Para encaminhar a porta do Service, execute o seguinte comando:

kubectl port-forward -n gpc-system service/grafana 33000\:3000

No navegador de Internet, navegue para http://localhost:33000 para ver o painel de controlo do Grafana para a sua implementação. Para terminar o processo, prima as teclas Control+C.

O Grafana está lento

O Grafana estar lento indica o seguinte:

As consultas ao Prometheus ou ao Loki devolvem dados excessivos.
As consultas devolvem mais dados do que é razoável apresentar num único gráfico.

Para resolver velocidades lentas no Grafana, verifique as consultas nos seus painéis de controlo personalizados do Grafana. Se as consultas devolverem mais dados do que é razoável apresentar num único gráfico, pondere reduzir a quantidade de dados apresentados para melhorar o desempenho do painel de controlo.

O painel de controlo do Grafana não mostra métricas nem registos

O facto de o Grafana não apresentar métricas nem registos pode dever-se aos seguintes motivos:

As origens de dados do Grafana não estão definidas corretamente.
O sistema tem problemas de conetividade com as origens de dados de monitorização ou registo.
O sistema não está a recolher métricas nem registos.

Para ver os registos e as métricas, siga estes passos:

Na interface do utilizador do Grafana, clique em Definições do painel de controlo.
Selecione Origens de dados.
Na página Origens de dados, certifique-se de que vê as seguintes origens:

Nome	Organização	URL
`Audit Logs`	`All`	`http://audit-logs-loki-io-read.obs-system.svc:3100`
`Operational Logs`	`Root`	`http://ops-logs-loki-io-read.obs-system.svc:3100`
`Operational Logs`	`Org`	`http://ops-logs-loki-all-read.obs-system.svc:3100`
`prometheus`		`http://anthos-prometheus-k8s.obs-system.svc:9090`

A falta destas origens de dados indica que a pilha de observabilidade não conseguiu configurar o Grafana corretamente.

Se configurou as origens de dados corretamente, mas não são apresentados dados, isto pode indicar um problema com os objetos Service que recolhem métricas ou registos para introduzir no Prometheus ou no Loki.

À medida que o Prometheus recolhe métricas, segue um modelo de obtenção para consultar periodicamente os seus objetos Service para métricas e armazenar os valores encontrados. Para que o Prometheus descubra os seus objetos Service para a recolha de métricas, tem de se verificar o seguinte:

Todos os pods para objetos Service estão anotados com 'monitoring.gke.io/scrape: "true"'.

Nota: se o seu serviço for uma implementação ou um objeto StatefulSet, adicione a anotação ao serviço para que o Kubernetes a propague para os seus pods.
O formato de métricas do Prometheus expõe as métricas do pod através de HTTP. Por predefinição, o Prometheus procura estas métricas no ponto final http://POD_NAME:80/metrics. Se necessário, pode substituir a porta, o ponto final e o esquema através de anotações.

O Fluent Bit recolhe registos e destina-se a ser executado em todos os nós dos seus clusters do Kubernetes. O Fluent Bit envia os registos para o Loki para armazenamento a longo prazo.

Se não existirem registos no Grafana, experimente as seguintes soluções alternativas:

Verifique os registos das instâncias do Loki para garantir que são executadas sem erros.
Se as instâncias do Loki estiverem a ser executadas corretamente, mas os registos não aparecerem, verifique os registos no Fluent Bit para garantir que o serviço funciona conforme esperado. Para rever como obter registos, consulte o artigo Obtenha registos de observabilidade.

O Alertmanager não está a abrir alertas

Se o Alertmanager não conseguir abrir alertas, siga os passos abaixo:

No objeto configMap no espaço de nomes gpc-system, certifique-se de que a etiqueta logmon: system_metrics existe.
Verifique se a secção de dados configMap inclui uma chave denominada alertmanager.yml. O valor da chave alertmanager.yml tem de ser as regras de alerta contidas no seu ficheiro de configuração do Alertmanager válido.
Certifique-se de que a definição de recurso personalizado logmon denominada logmon-default no espaço de nomes gpc-system contém uma referência ao objeto configMap. A definição de recurso personalizado logmon-default tem de conter o nome do objeto configMap, conforme mostrado no exemplo seguinte:
```
apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config
```
O valor alerts-config no exemplo é o nome do seu objeto configMap.

O Alertmanager não está a enviar alertas para os canais de notificação configurados

Um erro de configuração pode impedir que receba notificações no software externo que configurou como um canal de notificação, como o Slack, mesmo que o Alertmanager gere alertas na instância do Grafana.

Para receber alertas no seu software externo, siga estes passos:

Verifique se os valores no ficheiro de configuração do Alertmanager estão formatados corretamente. Quando o Alertmanager aciona um alerta, consulta um webhook no software externo.
Certifique-se de que os URLs de webhook que se ligam ao software externo estão corretos. Se os URLs estiverem corretos, certifique-se de que o software está configurado para aceitar webhooks. Pode ter de gerar uma chave da API para aceder à API do serviço externo ou a sua chave da API atual pode ter expirado e tem de a atualizar.
Se o serviço externo estiver fora da implementação do dispositivo isolado do GDC, certifique-se de que o cluster de infraestrutura da organização tem as regras de saída configuradas. Esta configuração permite que o Alertmanager envie pedidos para um serviço fora da rede Kubernetes interna. Se não validar as regras de saída, o Alertmanager pode não conseguir encontrar o software externo.

Não pode ver as métricas da sua carga de trabalho com âmbito do projeto

Siga os passos seguintes para aplicar uma solução alternativa e obter métricas da sua carga de trabalho:

Certifique-se de que o recurso personalizado MonitoringTarget tem um estado Ready.
Para extrair a sua carga de trabalho, tem de declarar todas as informações de destino especificadas para o MonitoringTarget na especificação do pod de cargas de trabalho. Por exemplo, se declarar que as métricas estão disponíveis na porta 8080, o pod de carga de trabalho tem de declarar ao Kubernetes que a porta 8080 está aberta. Caso contrário, o Prometheus ignora a carga de trabalho.
O Prometheus executa vários fragmentos, o que significa que nem todos os pods do Prometheus devem extrair dados do seu pod. Pode identificar o número do fragmento no nome de cada pod do Prometheus. Por exemplo, primary-prometheus-shard0-replica0-0 faz parte do fragmento 0. Verifique o pod do qual quer extrair dados de cada fragmento do Prometheus:
1. Encaminhe a porta do pod primary-prometheus-shardSHARD_NUMBER-replica0-0 do Prometheus no espaço de nomes obs-system para aceder à IU do Prometheus. Substitua SHARD_NUMBER no nome do pod por números crescentes sempre que verificar um novo fragmento.
2. Aceda à IU do Prometheus no seu navegador de Internet e siga estes passos:
  1. Clique em Estado > Alvos.
  2. Certifique-se de que o pod que quer extrair está na lista. Caso contrário, verifique o fragmento seguinte. Se não existirem mais fragmentos para verificar, valide novamente se o Prometheus tem informações suficientes para o descobrir.
3. Verifique se o pod primary-prometheus-shardSHARD_NUMBER-replica0-0 do Prometheus regista erros no espaço de nomes obs-system.
Verifique se o pod regista erros no espaço de nomes obs-system.cortex-tenant

Não foi criado um painel de controlo

Siga os passos seguintes para aplicar uma solução alternativa e descobrir por que motivo não é criado um painel de controlo:

Reveja o estado do recurso personalizado Dashboard para procurar erros. O recurso personalizado tem de ter um estado Ready.
Certifique-se de que está a verificar a instância do Grafana correta. Por exemplo, se implementou o painel de controlo no espaço de nomes do projeto denominado my-namespace, o painel de controlo tem de estar na instância do Grafana no ponto final https://GDCH_URL/my-namespace/grafana.
Verifique os registos do fleet-admin-controller no espaço de nomes gpc-system. Procure erros relacionados com o painel de controlo pesquisando o nome do painel de controlo nos registos. Se encontrar erros, o ficheiro JSON no seu objeto configMap tem um formato incorreto e tem de o corrigir.
Verifique os registos do Grafana no espaço de nomes PROJECT_NAME-obs-system para procurar erros. Os painéis de controlo consultam a API REST do Grafana, pelo que o Grafana tem de estar a funcionar para que um painel de controlo seja criado.

O seu alerta não está a abrir

Siga os passos abaixo para aplicar uma solução alternativa e descobrir por que motivo um alerta não está a ser aberto:

Certifique-se de que o Cortex e o Loki estão ambos no modo de armazenamento de contentores. As regras não funcionam, a menos que o back-end seja suportado pelo armazenamento de contentores.
Verifique se o estado dos recursos personalizados MonitoringRule e LoggingRule é Ready.
Verifique as seguintes condições de alerta:
- Expressões PromQL e LogQL: compare todas as funções que está a usar com a documentação Crie regras de alerta para garantir que as regras estão configuradas como pretende. Certifique-se de que as expressões devolvem um valor true ou false.
- Duração: o campo for do recurso personalizado define durante quanto tempo uma condição tem de ser verdadeira. O campo interval define a frequência com que a condição é avaliada. Verifique os valores destes campos entre si e certifique-se de que as suas condições são lógicas.
Verifique a IU do Grafana para ver se o alerta está aberto através da página Alertas.
Se o Grafana mostrar que o alerta está aberto, verifique os seus canais de notificação e certifique-se de que o Alertmanager os pode contactar para produzir o alerta.

Os registos esperados não estão disponíveis

Siga os passos seguintes se não vir registos operacionais do seu componente:

Verifique se o componente está em execução e a produzir registos.
Verifique se os registos de componentes devem ser recolhidos como uma funcionalidade integrada. Caso contrário, certifique-se de que tem o recurso personalizado LoggingTarget implementado com uma especificação válida e com um estado Ready.

Siga os passos seguintes se não vir registos de auditoria do seu componente:

Se o seu componente escrever registos num ficheiro, certifique-se de que o ficheiro existe realmente no sistema de ficheiros do nó no caminho /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log.
Verifique se o pod anthos-audit-logs-forwarder-SUFFIX no mesmo nó não tem erros.
Se o seu componente usar um ponto final syslog para receber registos, certifique-se de que tem o recurso personalizado AuditLoggingTarget implementado com uma especificação válida e com um estado Ready.

Identifique regras de alerta predefinidas

Esta secção contém informações sobre as regras de alerta predefinidas existentes nos componentes de observabilidade para lhe enviar notificações sobre falhas do sistema.

Regras de alerta predefinidas no Loki

A tabela seguinte apresenta as regras de alerta pré-instaladas no Loki para falhas de registo de auditoria:

Regras de alerta pré-instaladas no Loki para falhas de registo de auditoria
Nome	Tipo	Descrição
`FluentBitAuditLoggingWriteFailure`	Crítico	O Fluent Bit não encaminhou registos de auditoria nos últimos cinco minutos.
`LokiAuditLoggingWriteFailure`	Crítico	O Loki não conseguiu escrever registos de auditoria no armazenamento de back-end.

Quando um ou mais destes alertas são apresentados, o sistema perdeu, pelo menos, um registo de auditoria.

Regras de alerta predefinidas no Prometheus

A tabela seguinte fornece as regras de alerta pré-instaladas no Prometheus para componentes do Kubernetes:

Regras de alerta pré-instaladas no Prometheus
Nome	Tipo	Descrição
`KubeAPIDown`	Crítico	A API Kube desapareceu da descoberta de alvos do Prometheus durante 15 minutos.
`KubeClientErrors`	Aviso	A taxa de erros do cliente do servidor da API Kubernetes foi superior a 0,01 durante 15 minutos.
`KubeClientErrors`	Crítico	A relação de erros do cliente do servidor da API Kubernetes foi superior a 0,1 durante 15 minutos.
`KubePodCrashLooping`	Aviso	O pod está num estado de repetição de falhas há mais de 15 minutos.
`KubePodNotReady`	Aviso	O pod está num estado não pronto há mais de 15 minutos.
`KubePersistentVolumeFillingUp`	Crítico	Os bytes livres de um objeto `PersistentVolume` reivindicado são inferiores a 0,03.
`KubePersistentVolumeFillingUp`	Aviso	Os bytes livres de um objeto `PersistentVolume` reivindicado são inferiores a 0,15.
`KubePersistentVolumeErrors`	Crítico	O volume persistente está numa fase `Failed` ou `Pending` há cinco minutos.
`KubeNodeNotReady`	Aviso	O nó não está pronto há mais de 15 minutos.
`KubeNodeCPUUsageHigh`	Crítico	A utilização da CPU do nó é superior a 80%.
`KubeNodeMemoryUsageHigh`	Crítico	A utilização de memória do nó é superior a 80%.
`NodeFilesystemSpaceFillingUp`	Aviso	A utilização do sistema de ficheiros do nó é superior a 60%.
`NodeFilesystemSpaceFillingUp`	Crítico	A utilização do sistema de ficheiros do nó é superior a 85%.
`CertManagerCertExpirySoon`	Aviso	Um certificado expira dentro de 21 dias.
`CertManagerCertNotReady`	Crítico	Um certificado não está pronto para apresentar tráfego após 10 minutos.
`CertManagerHittingRateLimits`	Crítico	Atingiu um limite de taxa ao criar ou renovar certificados durante cinco minutos.
`DeploymentNotReady`	Crítico	Uma implementação no cluster de infraestrutura da organização está num estado não pronto há mais de 15 minutos.
`StatefulSetNotReady`	Crítico	Um objeto `StatefulSet` no cluster de infraestrutura da organização está num estado não pronto há mais de 15 minutos.
`AuditLogsForwarderDown`	Crítico	O `anthos-audit-logs-forwarder` DaemonSet está inativo há mais de 15 minutos.
`AuditLogsLokiDown`	Crítico	O `audit-logs-loki` StatefulSet está num estado não pronto há mais de 15 minutos.