Esta página foi traduzida pela API Cloud Translation.

Solução de problemas de observabilidade

Neste documento, descrevemos como identificar falhas de implantação e incidentes operacionais que podem ocorrer no appliance isolado do Google Distributed Cloud (GDC). Ele também contém descrições de todos os alertas exibidos no sistema para ajudar você a resolver problemas comuns com componentes de geração de registros e monitoramento.

Identificar componentes do Observability

A plataforma de observabilidade implanta os componentes dela 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 da CPU e consumo de armazenamento. Ele também dá 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 stacks 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, switches 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 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, pods, máquinas bare metal, switches de rede e dispositivos de armazenamento do Kubernetes.
`Alertmanager`	O Alertmanager é um sistema gerenciador definido pelo usuário que envia alertas quando os registros ou as 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 oferece 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 serão executados no estado READY.

Siga estas etapas 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 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 o valor 2.

Um grande número 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, veja os registros dos pods.

Se um pod estiver no estado PENDING, isso indica um ou mais dos seguintes sintomas:
- O pod está aguardando o 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 de Secret necessário para o pod está faltando.
- O cluster do Kubernetes ficou sem recursos para programar o pod, o que acontece 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.

Navegue até a seção Events da saída para ver uma tabela com os eventos recentes do pod e um resumo sobre a causa do estado PENDING.

A saída a seguir mostra uma seçã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 houver eventos no seu pod ou em qualquer outro recurso por um longo período, você vai receber a seguinte saída:

  Events:         <none>

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

Siga estas etapas 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 o sidecar do Istio injetado. 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 sendo executadas sem erros no cluster de infraestrutura da organização.
Verifique o status dos objetos anthos-audit-logs-forwarder e anthos-log-forwarder DaemonSet para verificar se todas as instâncias estão sendo executadas 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 da API Kubernetes nos últimos cinco minutos em todos os clusters. Para 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.

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

Siga estas etapas 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 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 o pod:

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 implantados pela plataforma de observabilidade.

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 conferir os registros da instância anterior de um componente, adicione a flag -p ao final de cada comando. Adicionar a flag -p permite analisar os registros de uma instância com falha anterior 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 Prometheus e 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 capacidade de observação para sua implantação. Essa definição de recurso personalizado inclui as propriedades de volumes para armazenar suas métricas, regras de alerta para o Alertmanager, configurações do Prometheus para coletar métricas e 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 da observabilidade:
```
kubectl get logmon -n obs-system logmon-default -o yaml
```
Mude a configuração da implantação de observabilidade:
```
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 mudar e conferir a configuração do Alertmanager usando a definição de recurso personalizado logmon chamada gpc-alertmanager-config.

Para conferir 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 você pode enfrentar 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 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

A lentidão do Grafana indica o seguinte:

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

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

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

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

As fontes de dados do Grafana não estão definidas corretamente.
O sistema tem problemas de conectividade com fontes de dados de monitoramento ou de geração de registros.
O sistema não está coletando métricas nem 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 configurou o Grafana corretamente.

Se você configurou as fontes de dados corretamente, mas nenhum dado aparece, isso pode indicar um problema com 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 aos pods.
O formato de métricas 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 foi projetado para ser 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 sendo executadas 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 alertas, siga estas etapas:

No objeto configMap no 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 seu 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 de 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 do serviço externo ou sua chave de API atual pode ter expirado, e você precisa atualizar.
Se o serviço externo estiver fora da implantação do appliance isolado do GDC, 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 não poderá encontrar o software externo.

Não é possível ver as métricas da carga de trabalho no escopo do 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 fazer o scraping da 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 de 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 shards, o que significa que nem todos os pods do Prometheus devem fazer raspagem 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 extrair 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 > Targets.
  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, revalide se o Prometheus tem informações suficientes para descobrir.
3. Verifique se o pod primary-prometheus-shardSHARD_NUMBER-replica0-0 do Prometheus registra erros no namespace obs-system.
Verifique os erros nos registros do pod cortex-tenant no namespace obs-system.

Um painel não foi criado

Siga estas etapas 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á conferindo 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 do 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 está com um formato incorreto, e você precisa corrigir isso.
Verifique os registros do Grafana no namespace PROJECT_NAME-obs-system para procurar 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 não funcionam a menos que o back-end seja apoiado pelo 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 e confira se as condições são lógicas.
Verifique na interface do Grafana 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 confirme se o Alertmanager pode entrar em contato com eles para gerar o alerta.

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

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

Verifique se o componente está em execução e gerando registros.
Verifique se os registros de componentes 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 um status Ready.

Siga estas etapas se não encontrar registros de auditoria do seu componente:

Se o componente gravar registros em um arquivo, verifique se ele 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 syslog para receber registros, verifique se você implantou o recurso personalizado AuditLoggingTarget 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 nos componentes de observabilidade para notificar você sobre falhas do sistema.

Regras de alerta predefinidas no Loki

A tabela a seguir oferece 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 encaminhou 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 da API Kubernetes foi maior que 0,01 por 15 minutos.
`KubeClientErrors`	Crítico	A proporção de erros do cliente do servidor da API Kubernetes é maior que 0,1 há 15 minutos.
`KubePodCrashLooping`	Aviso	O pod está em um estado de loop de falha há mais de 15 minutos.
`KubePodNotReady`	Aviso	O pod está em 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á na 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ó é superior a 80%.
`KubeNodeMemoryUsageHigh`	Crítico	O uso da memória do nó é superior a 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ó é superior a 85%.
`CertManagerCertExpirySoon`	Aviso	O certificado expira em 21 dias.
`CertManagerCertNotReady`	Crítico	Um certificado não está pronto para veicular tráfego após 10 minutos.
`CertManagerHittingRateLimits`	Crítico	Você atingiu um limite 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 estado não pronto há mais de 15 minutos.
`StatefulSetNotReady`	Crítico	Um objeto `StatefulSet` no cluster de infraestrutura da organização está em 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 estado não pronto há mais de 15 minutos.