Resolver problemas em painéis de monitoramento

Nesta página, mostramos como resolver problemas relacionados aos painéis de monitoramento do Google Kubernetes Engine (GKE).

Por padrão, o Monitoring é ativado quando você cria um cluster. Se você não vir os painéis do GKE quando estiver visualizando os painéis fornecidos do Google Cloud no Monitoring, isso significa que o Monitoring não está ativado para clusters no projeto selecionado do Google Cloud. Ative o monitoramento para visualizar esses painéis.

Não há recursos do Kubernetes no meu painel

Se nenhum recurso do Kubernetes for exibido no painel do GKE, faça estas verificações:

Projeto do Google Cloud selecionado

Verifique se você selecionou o projeto correto do Google Cloud na lista suspensa da barra de menus do console do Google Cloud para selecionar um projeto. Escolha aquele com os dados que você quer ver.

Atividade de clusters

Se você tiver acabado de criar o cluster, aguarde alguns minutos para que ele seja preenchido com dados. Consulte Como configurar a geração de registros e o monitoramento do GKE para ver mais detalhes.

Intervalo de tempo

O intervalo de tempo selecionado pode ser muito curto. Use o menu Time na barra de ferramentas do painel para selecionar intervalos diferentes ou definir um intervalo Personalizado.

Permissões para visualizar o painel

Se uma das mensagens de erro a seguir for exibida ao consultar os detalhes de implantação de um serviço ou as métricas de um projeto do Google Cloud, você precisará atualizar o papel do Identity and Access Management para para incluir roles/monitoring.viewer ou roles/viewer:

  • You do not have sufficient permissions to view this page
  • You don't have permissions to perform the action on the selected resources

Para mais detalhes, acesse Papéis predefinidos.

Permissões de cluster e de conta de serviço de nó para gravar dados no Monitoring e Logging

Se você vir altas taxas de erro na página APIs e serviços ativados no console do Google Cloud, talvez sua conta de serviço esteja sem os seguintes papéis:

  • roles/logging.logWriter: no console do Google Cloud, esse papel é denominado Gravador de registros. Para mais informações sobre papéis do Logging, consulte o Guia de controle de acesso ao Logging.

  • roles/monitoring.metricWriter: no console do Google Cloud, esse papel é denominado Gravador de métricas do Monitoring. Para mais informações sobre os papéis do Monitoring, consulte o Guia de controle de acesso ao Monitoring.

  • roles/stackdriver.resourceMetadata.writer: no console do Google Cloud, esse papel é denominado Gravador de metadados de recursos do Stackdriver. Ele fornece acesso somente de gravação a metadados de recursos e fornece as permissões exatas necessárias para que os agentes enviem metadados. Para mais informações sobre os papéis do Monitoring, consulte o Guia de controle de acesso ao Monitoring.

Para listar as contas de serviço, acesse IAM e administrador no console do Google Cloud e selecione Contas de serviço.

Não é possível visualizar registros

Se não vir registros nos painéis, verifique o seguinte:

O agente está em execução e íntegro

A versão 1.17 do GKE e mais recentes usam o Fluent Bit para capturar registros. O Fluent Bit é o agente do Logging executado nos nós do Kubernetes. Para verificar se o agente está sendo executado corretamente, execute as seguintes etapas:

  1. Verifique se o agente está reiniciando executando este comando:

    kubectl get pods -l k8s-app=fluentbit-gke -n kube-system

    Se não houver reinicializações, a saída será semelhante a esta:

    NAME                  READY   STATUS    RESTARTS   AGE
fluentbit-gke-6zr6g   2/2     Running   0          44d
fluentbit-gke-dzh9l   2/2     Running   0          44d

  2. Verifique as condições de status do pod executando este comando:

    JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};'  \
 && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"

    Se a implantação estiver íntegra, o resultado será semelhante a:

    fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,
fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,

  3. Verifique o status do pod, o que pode ajudar a determinar se a implantação está íntegra executando este comando:

    kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-system

    Se a implantação estiver íntegra, o resultado será semelhante a:

    NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h

    Neste exemplo de saída, o estado desejado corresponde ao estado atual.

Se o agente estiver em execução e íntegro nesses cenários e você ainda não vir todos os registros, talvez ele esteja sobrecarregado e descartando registros.

Agente sobrecarregado e descartando registros

Um possível motivo para você não ver todos os seus registros é que o volume de registros do nó está sobrecarregando o agente. A configuração padrão do agente do Logging no GKE é definida para a taxa de 100 kiB por segundo para cada nó, e o agente pode começar a descartar registros se o volume exceder esse limite.

Para saber se você está atingindo esse limite, procure um dos seguintes indicadores:

  • Visualize a métrica kubernetes.io/container/cpu/core_usage_time com o filtro container_name=fluentbit-gke para ver se o uso de CPU do agente do Logging está próximo ou em 100%.

  • Veja a métrica logging.googleapis.com/byte_count agrupada por metadata.system_labels.node_name para ver se algum nó atinge 100 kiB por segundo.

Se você encontrar alguma dessas condições, reduza o volume de registro dos nós adicionando mais nós ao cluster. Se todo o volume de registro vier de um único pod, será necessário reduzir o volume desse pod.

Se você quiser alterar os parâmetros de ajuste do agente do Logging, consulte o tutorial da comunidade sobre como implantar uma configuração personalizada do agente do Logging.

Para mais informações sobre como investigar e resolver problemas relacionados à geração de registros do GKE, consulte Como solucionar problemas de geração de registros no GKE.

O incidente não corresponde a um recurso do GKE?

Se você tiver uma condição de política de alertas que agregue métricas em recursos distintos do GKE, talvez seja necessário editar a condição da política para incluir mais rótulos de hierarquia do GKE para associar incidentes a entidades específicas.

Por exemplo, é possível ter dois clusters do GKE, um para produção e outro para preparação, cada um com a própria cópia de serviço lilbuddy-2. Quando a condição da política de alertas agregar uma métrica entre os contêineres nos dois clusters, o painel de monitoramento do GKE não poderá associar esse incidente exclusivamente ao serviço de produção ou de teste.

Para resolver essa situação, segmente a política de alertas para um serviço específico adicionando namespace, cluster e location ao campo Agrupar por da política. No card de evento do alerta, clique no link Atualizar política de alertas para abrir a página Editar política de alertas da política de alertas relevante. Nesse local, é possível atualizar a política de alertas com informações adicionais para que o painel possa encontrar o recurso associado.

Depois de atualizar a política de alertas, o painel de monitoramento do GKE pode associar todos os incidentes futuros a um serviço exclusivo em um cluster específico, fornecendo informações adicionais para diagnosticar o problema.

Dependendo do caso de uso, convém filtrar alguns desses rótulos, além de adicioná-los ao campo Agrupar por. Por exemplo, se você quiser apenas alertas para seu cluster de produção, filtre em cluster_name.