O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Solução de problemas de observabilidade

Neste documento, apresentamos procedimentos de solução de problemas e descrições de referência de alertas predefinidos do sistema para ajudar você a identificar falhas de implantação e resolver incidentes operacionais com componentes de geração de registros e monitoramento no dispositivo do Google Distributed Cloud (GDC) com isolamento físico. Use esses procedimentos e definições de alerta para verificar se as pilhas de geração de registros e monitoramento estão em execução, inspecionar as configurações do pipeline e resolver problemas de componentes.

Identificar componentes de observabilidade

A plataforma de observabilidade implanta os componentes no namespace obs-system no cluster de infraestrutura da organização.

A instância do Grafana do operador de infraestrutura (IO, na sigla em inglês) fornece acesso a métricas no nível da organização para monitorar componentes de infraestrutura, como utilização de CPU e consumo de armazenamento. Ele também fornece acesso a registros operacionais e de auditoria. Além disso, ele dá acesso a alertas, registros e métricas dos componentes operáveis do GDC.

As pilhas de monitoramento e geração de registros do GDC usam soluções de código aberto como parte da plataforma de observabilidade. Esses componentes coletam registros e métricas de pods do Kubernetes, máquinas bare metal, trocas de rede, armazenamento e serviços gerenciados.

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

Componente	Descrição
`Prometheus`	O Prometheus é um banco de dados de série temporal para coletar 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 de longo prazo. O Prometheus adiciona rótulos como pares de chave-valor e coleta métricas de nós do Kubernetes, pods, máquinas bare metal, trocas de rede e dispositivos de armazenamento.
`Alertmanager`	O Alertmanager é um sistema de gerenciamento definido pelo usuário que envia alertas quando registros ou métricas indicam que os componentes do sistema falharam ou não estão funcionando normalmente. Ele gerencia o roteamento, o silenciamento e a agregação de alertas do Prometheus.
`Loki`	O Loki é um banco de dados de séries temporais que armazena e agrega registros de várias fontes. Ele indexa registros para consultas eficientes.
`Grafana`	O Grafana fornece uma interface do usuário (UI) para visualizar as métricas coletadas pelo Prometheus e consultar registros de auditoria e operacionais das instâncias correspondentes do Loki. A interface permite visualizar painéis de métricas e alertas.
`Fluent Bit`	O Fluent Bit é um processador que extrai registros de vários componentes ou locais e os envia para o Loki. Ele é executado em todos os nós de todos os clusters.

Identificar falhas de implantação

Se a implantação estiver em execução e íntegra, os componentes vão ser executados no estado READY.

Siga as etapas abaixo para identificar falhas de implantação:

Confirme o estado atual de um componente:
```
kubectl get -n obs-system TYPE/COMPONENT
```
Substitua:
- TYPE: o tipo de componente
- COMPONENT: o nome do componente.
Você verá um resultado parecido com este:
```
NAME       READY  AGE
COMPONENT  1/1    23h
```
Se o componente estiver íntegro, a coluna READY da saída vai mostrar N/N como um valor. Se a coluna READY não mostrar um valor, isso 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.

Você verá um resultado parecido com este:
```
NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h
```
Verifique se a coluna READY mostra N/N como um valor, se a coluna STATUS mostra um valor Running e se o número de RESTARTS não excede um valor de 2.

Um número alto de reinicializações indica os seguintes sintomas:
- Os pods falham e o Kubernetes os reinicia.
- A coluna STATUS mostra o valor CrashLoopBackoff.
Para resolver o status de falha, confira os registros dos pods.

Se um pod estiver no estado PENDING, isso indica um ou mais dos seguintes sintomas:
- O pod está aguardando acesso à rede para fazer o download do contêiner necessário.
- Um problema de configuração impede que o pod seja iniciado. Por exemplo, um valor Secret exigido pelo pod está ausente.
- O cluster do Kubernetes ficou sem recursos para programar o pod, o que ocorre se muitos aplicativos estiverem em execução 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.
Acesse a seção Events da saída para ver uma tabela com os eventos recentes do pod e um resumo da causa do estado PENDING.

A saída a seguir mostra um exemplo de seção Events 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 houver eventos no pod ou em qualquer outro recurso por um período prolongado, você vai receber a seguinte saída:
```
  Events:         <none>
```

Verificar se a pilha de geração de registros de observabilidade está em execução

Siga as etapas abaixo para verificar se a pilha de geração de registros está em execução:

Verifique se todas as instâncias ou pods do Loki têm a injeção de sidecar do Istio. Verifique se todos os pods do Fluent Bit chamados 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 em execução sem erros no cluster de infraestrutura da organização.
Verifique o status dos objetos anthos-audit-logs-forwarder e anthos-log-forwarder DaemonSet para confirmar se todas as instâncias estão em execução em todos os nós sem erros.
Verifique se você recebe os registros operacionais dos contêineres kube-apiserver-SUFFIX e os registros de auditoria do servidor de API Kubernetes dos últimos cinco minutos em todos os clusters. Para fazer isso, execute as seguintes consultas na instância do Grafana:
- Registros operacionais: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
- Registros de auditoria: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)
Você precisa receber valores diferentes de zero para todos os nós do plano de controle no cluster de infraestrutura da organização.

Verificar se a pilha de monitoramento de observabilidade está em execução

Siga as etapas abaixo para verificar se a pilha de monitoramento está em execução:

Verifique se as instâncias do Grafana estão em execução no cluster de infraestrutura da organização. Os pods grafana-0 precisam ser executados sem erros nos seguintes namespaces:
- obs-system
- infra-obs-obs-system
- platform-obs-obs-system
Observação: outros namespaces do PROJECT_NAMESPACE-obs-system podem executar instâncias do Grafana. As instâncias variam de acordo com o cluster.

Verifique se todos os componentes de monitoramento estão na malha de serviço do Istio. Siga as etapas da seção Identificar falhas de implantação. Cada um dos pods a seguir precisa mostrar que todos os contêineres estão prontos na coluna READY. Por exemplo, um valor de 3/3 significa que três contêineres de três estão prontos. Além disso, os pods precisam ter um contêiner istio-proxy. Se os pods não atenderem a essas condições, reinicie-os:

Nome do pod	Número de contêineres 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`

Verifique se o Cortex está sendo executado sem erros.

Recuperar registros de observabilidade

A tabela a seguir contém os comandos que você precisa executar para recuperar os registros de cada um dos componentes que a plataforma de observabilidade implanta.

Componente	Comando de recuperação de registros
`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 registros da instância anterior de um componente, adicione a flag -p ao final de cada comando. Adicionar a flag -p permite que você analise os registros de uma instância anterior com falha em vez da instância em execução atual.

Ver a configuração

A pilha de observabilidade usa recursos personalizados da API Kubernetes para configurar pipelines de monitoramento e geração de registros.

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

Os comandos a seguir mostram as ações disponíveis que podem ser realizadas no pipeline de geração de registros:

Confira a configuração atual da implantação do pipeline de geração de registros:
```
kubectl get loggingpipeline -n obs-system default -o yaml
```
Mude a configuração da implantação do pipeline de geração de registros:
```
kubectl edit loggingpipeline -n obs-system default
```

O GDC usa um operador de geração de registros e monitoramento chamado logmon-operator para gerenciar a implantaçã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 recurso personalizado logmon instrui o logmon-operator sobre como configurar a observabilidade para sua implantação. Essa definição de recurso personalizado inclui as propriedades dos volumes para armazenar as métricas, as regras de alerta para o Alertmanager, as configurações do Prometheus para coletar métricas e as configurações do Grafana para painéis.

Os comandos a seguir mostram as ações disponíveis que podem ser realizadas na definição de recurso personalizado logmon:

Confira a configuração atual da implantação de observabilidade:
```
kubectl get logmon -n obs-system logmon-default -o yaml
```
Mude a configuração da implantação do Observability:
```
kubectl edit logmon -n obs-system logmon-default
```

A saída da execução de qualquer um dos comandos pode fazer referência a vários objetos ConfigMap do Kubernetes para mais configurações. Por exemplo, é possível configurar regras do Alertmanager em um objeto ConfigMap separado, que é referenciado na definição de recurso personalizado logmon por nome. É possível alterar e visualizar a configuração do Alertmanager usando a definição de recurso personalizado logmon chamada gpc-alertmanager-config.

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

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

Problemas comuns

Esta seção contém problemas comuns que podem ser enfrentados ao implantar a plataforma de observabilidade.

Não é possível acessar o Grafana

Por padrão, o Grafana não é exposto a máquinas externas ao cluster do Kubernetes. Para acessar temporariamente a interface do Grafana de fora do cluster de infraestrutura da organização, encaminhe a porta Service para o localhost. Para encaminhar a porta do Service, execute:

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

No navegador da Web, acesse http://localhost:33000 para ver o painel do Grafana da sua implantação. Para encerrar o processo, pressione as teclas Control+C.

O Grafana está lento

O Grafana em execução lenta indica o seguinte:

As consultas ao Prometheus ou ao Loki retornam dados em excesso.
As consultas retornam mais dados do que é razoável exibir em um único gráfico.

Para resolver velocidades lentas no Grafana, verifique as consultas nos painéis personalizados do Grafana. Se as consultas retornarem mais dados do que o razoável para exibição em um único gráfico, considere reduzir a quantidade de dados mostrados para melhorar o desempenho do painel.

O painel do Grafana não mostra métricas ou registros

O Grafana não mostrar métricas ou registros pode ser causado pelos seguintes motivos:

As fontes de dados do Grafana não estão configuradas corretamente.
O sistema tem problemas de conectividade com as fontes de dados de monitoramento ou de geração de registros.
O sistema não está coletando métricas ou registros.

Para conferir os registros e as métricas, siga estas etapas:

Na interface do usuário do Grafana, clique em Configurações do painel.
Selecione Origens de dados.
Na página Fontes de dados, verifique se as seguintes fontes aparecem:

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 ausência dessas fontes de dados indica que a pilha de observabilidade não conseguiu configurar o Grafana corretamente.

Se você configurou as fontes de dados corretamente, mas nenhum dado é exibido, isso pode indicar um problema com os objetos Service que coletam métricas ou registros para alimentar o Prometheus ou o Loki.

À medida que o Prometheus coleta métricas, ele segue um modelo de pull para consultar periodicamente seus objetos Service em busca de métricas e armazenar os valores encontrados. Para que o Prometheus descubra seus objetos Service para coleta de métricas, o seguinte precisa ser verdadeiro:

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

Observação : se o serviço for uma implantação ou um objeto StatefulSet, adicione a anotação ao serviço para que o Kubernetes a propague para os pods.
O formato de métrica do Prometheus expõe as métricas do pod por HTTP. Por padrão, o Prometheus procura essas métricas no endpoint http://POD_NAME:80/metrics. Se necessário, é possível substituir a porta, o endpoint e o esquema usando anotações.

O Fluent Bit coleta registros e é executado em todos os nós dos clusters do Kubernetes. O Fluent Bit envia os registros para o Loki para armazenamento de longo prazo.

Se não houver registros no Grafana, tente as seguintes soluções alternativas:

Verifique os registros das instâncias do Loki para garantir que elas sejam executadas sem erros.
Se as instâncias do Loki estiverem funcionando corretamente, mas os registros não aparecerem, verifique os registros no Fluent Bit para garantir que o serviço funcione como esperado. Para saber como extrair registros, consulte Recuperar registros de observabilidade.

O Alertmanager não está abrindo alertas

Se o Alertmanager não abrir os alertas, siga estas etapas:

No objeto configMap dentro do namespace gpc-system, verifique se o rótulo logmon: system_metrics existe.
Verifique se a seção de dados configMap inclui uma chave chamada alertmanager.yml. O valor da chave alertmanager.yml precisa ser as regras de alerta contidas no arquivo de configuração válido do Alertmanager.
Verifique se a definição de recurso personalizado logmon chamada logmon-default no namespace gpc-system contém uma referência ao objeto configMap. A definição de recurso personalizado logmon-default precisa conter o nome do objeto configMap, conforme mostrado no exemplo a seguir:
```
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 objeto configMap.

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

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

Para receber alertas no software externo, siga estas etapas:

Verifique se os valores no arquivo de configuração do Alertmanager estão formatados corretamente. Quando o Alertmanager aciona um alerta, ele consulta um webhook no software externo.
Verifique se os URLs do webhook que se conectam ao software externo estão corretos. Se os URLs estiverem corretos, verifique se o software está configurado para aceitar webhooks. Talvez seja necessário gerar uma chave de API para acessar a API de serviço externa ou sua chave de API atual pode estar expirada e você precisa atualizá-la.
Se o serviço externo estiver fora da implantação do dispositivo GDC com isolamento físico, verifique se o cluster de infraestrutura da organização tem as regras de saída configuradas. Essa configuração permite que o Alertmanager envie solicitações para um serviço fora da rede interna do Kubernetes. Se as regras de saída não forem verificadas, o Alertmanager poderá não encontrar o software externo.

Não é possível ver as métricas da carga de trabalho com escopo de projeto

Siga as etapas abaixo para aplicar uma solução alternativa e receber métricas da sua carga de trabalho:

Verifique se o recurso personalizado MonitoringTarget tem o status Ready.
Para coletar sua carga de trabalho, declare todas as informações de destino especificadas para o MonitoringTarget na especificação do pod de cargas de trabalho. Por exemplo, se você declarar que as métricas estão disponíveis na porta 8080, o pod da carga de trabalho precisará declarar ao Kubernetes que a porta 8080 está aberta. Caso contrário, o Prometheus vai ignorar a carga de trabalho.
O Prometheus executa vários fragmentos, o que significa que nem todos os pods do Prometheus vão coletar dados do seu pod. É possível 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 que você quer coletar de cada fragmento do Prometheus:
1. Encaminhe a porta do pod primary-prometheus-shardSHARD_NUMBER-replica0-0 do Prometheus no namespace obs-system para acessar a interface do Prometheus. Substitua SHARD_NUMBER no nome do pod por números crescentes sempre que você verificar um novo fragmento.
2. Acesse a interface do Prometheus no navegador da Web e siga estas etapas:
  1. Clique em Status > Destinos.
  2. Verifique se o pod que você quer extrair está na lista. Caso contrário, verifique o próximo fragmento. Se não houver mais fragmentos para verificar, confirme se o Prometheus tem informações suficientes para descobri-lo.
3. Verifique se o pod primary-prometheus-shardSHARD_NUMBER-replica0-0 do Prometheus registra erros no namespace obs-system.
Verifique os erros de registros do pod cortex-tenant no namespace obs-system.

Um painel não foi criado

Siga as etapas abaixo para aplicar uma solução alternativa e descobrir por que um painel não foi criado:

Analise o status do recurso personalizado Dashboard para procurar erros. O recurso personalizado precisa ter um status Ready.
Verifique se você está verificando a instância correta do Grafana. Por exemplo, se você implantou o painel no namespace do projeto chamado my-namespace, ele precisa estar na instância do Grafana no endpoint https://GDCH_URL/my-namespace/grafana.
Verifique os registros de fleet-admin-controller no namespace gpc-system. Procure erros relacionados ao painel pesquisando o nome dele nos registros. Se você encontrar erros, o arquivo JSON no objeto configMap tem um formato incorreto e precisa ser corrigido.
Verifique os registros do Grafana no namespace PROJECT_NAME-obs-system para ver se há erros. Os painéis consultam a API REST do Grafana. Portanto, o Grafana precisa estar funcionando para que um painel seja criado.

O alerta não está abrindo

Siga as etapas abaixo para aplicar uma solução alternativa e descobrir por que um alerta não está abrindo:

Verifique se o Cortex e o Loki estão no modo de armazenamento em bucket. As regras só funcionam se o back-end tiver o suporte do armazenamento de bucket.
Verifique se o status 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 você está usando com a documentação Criar regras de alerta para garantir que as regras estejam configuradas como você quer. Verifique se as expressões retornam um valor true ou false.
- Duração: o campo for do recurso personalizado define por quanto tempo uma condição precisa ser verdadeira. O campo interval define a frequência com que a condição é avaliada. Verifique os valores desses campos entre si e garanta que as condições sejam lógicas.
Verifique a interface do Grafana para ver se o alerta está aberto usando a página Alertas.
Se o Grafana mostrar que o alerta está aberto, verifique seus canais de notificação e garanta que o Alertmanager possa entrar em contato com eles para produzir o alerta.

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

Siga as etapas abaixo se você não encontrar registros operacionais do seu componente:

Verifique se o componente está em execução e produzindo registros.
Verifique se os registros do componente precisam ser coletados como uma funcionalidade integrada. Caso contrário, verifique se o recurso personalizado LoggingTarget foi implantado com uma especificação válida e com o status Ready.

Siga as etapas abaixo se você não encontrar registros de auditoria do seu componente:

Se o componente gravar registros em um arquivo, verifique se o arquivo realmente existe no sistema de arquivos 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 componente usa um endpoint de syslog para receber registros, verifique se o recurso personalizado AuditLoggingTarget foi implantado com uma especificação válida e um status Ready.

Identificar regras de alerta predefinidas

Esta seção contém informações sobre as regras de alerta predefinidas que existem nos componentes de observabilidade para notificar você sobre falhas do sistema.

Regras de alerta predefinidas no Loki

A tabela a seguir mostra as regras de alerta pré-instaladas no Loki para falhas de registro de auditoria:

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

Quando um ou mais desses alertas são exibidos, o sistema perdeu pelo menos um registro de auditoria.

Regras de alerta predefinidas no Prometheus

A tabela a seguir mostra 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 destino do Prometheus por 15 minutos.
`KubeClientErrors`	Aviso	A proporção de erros do cliente do servidor de API Kubernetes foi maior que 0,01 por 15 minutos.
`KubeClientErrors`	Crítico	A proporção de erros do cliente do servidor de API do Kubernetes é maior que 0,1 há 15 minutos.
`KubePodCrashLooping`	Aviso	O pod está em um estado de repetição de falha há mais de 15 minutos.
`KubePodNotReady`	Aviso	O pod está em um estado não pronto há mais de 15 minutos.
`KubePersistentVolumeFillingUp`	Crítico	Os bytes livres de um objeto `PersistentVolume` reivindicado são menores que 0,03.
`KubePersistentVolumeFillingUp`	Aviso	Os bytes livres de um objeto `PersistentVolume` reivindicado são menores que 0,15.
`KubePersistentVolumeErrors`	Crítico	O volume permanente está em uma fase `Failed` ou `Pending` há cinco minutos.
`KubeNodeNotReady`	Aviso	O nó não está pronto há mais de 15 minutos.
`KubeNodeCPUUsageHigh`	Crítico	O uso da CPU do nó é maior que 80%.
`KubeNodeMemoryUsageHigh`	Crítico	O uso da memória do nó é maior que 80%.
`NodeFilesystemSpaceFillingUp`	Aviso	O uso do sistema de arquivos do nó é maior que 60%.
`NodeFilesystemSpaceFillingUp`	Crítico	O uso do sistema de arquivos do nó é maior que 85%.
`CertManagerCertExpirySoon`	Aviso	O certificado expira em 21 dias.
`CertManagerCertNotReady`	Crítico	Um certificado não está pronto para disponibilizar tráfego após 10 minutos.
`CertManagerHittingRateLimits`	Crítico	Você atingiu uma limitação de taxa ao criar ou renovar certificados por cinco minutos.
`DeploymentNotReady`	Crítico	Uma implantação no cluster de infraestrutura da organização está em um estado não pronto há mais de 15 minutos.
`StatefulSetNotReady`	Crítico	Um objeto `StatefulSet` no cluster de infraestrutura da organização está em um estado não pronto há mais de 15 minutos.
`AuditLogsForwarderDown`	Crítico	O DaemonSet `anthos-audit-logs-forwarder` está inativo há mais de 15 minutos.
`AuditLogsLokiDown`	Crítico	O StatefulSet `audit-logs-loki` está em um estado não pronto há mais de 15 minutos.