Resolva problemas de painéis de controlo de monitorização

Esta página ajuda a resolver problemas com os painéis de controlo de monitorização do Google Kubernetes Engine (GKE), como painéis de controlo que não aparecem ou dados indisponíveis. Para mais informações sobre como usar estes painéis de controlo para resolver problemas nos seus clusters e cargas de trabalho, consulte o artigo Avalie o estado de funcionamento do cluster e da carga de trabalho na Google Cloud consola.

Por predefinição, a monitorização está ativada quando cria um cluster. Se não vir dashboards do GKE quando estiver a ver dashboards fornecidos Google Cloud no Monitoring, significa que o Monitoring não está ativado para clusters no Google Cloud projeto selecionado. Ative a monitorização para ver estes painéis de controlo.

Não existem recursos do Kubernetes no meu painel de controlo

Se não vir recursos do Kubernetes no painel de controlo do GKE, verifique o seguinte:

Projeto Google Cloud selecionado

Verifique se selecionou o Google Cloud projeto correto na lista pendente na Google Cloud barra de menu da consola para selecionar um projeto. Tem de selecionar o projeto cujos dados quer ver.

Atividade de clusters

Se acabou de criar o cluster, aguarde alguns minutos para que seja preenchido com dados. Consulte o artigo Configurar o registo e a monitorização para o GKE para ver detalhes.

Intervalo de tempo

O intervalo de tempo selecionado pode ser demasiado restrito. Pode usar o menu Hora na barra de ferramentas do painel de controlo para selecionar outros intervalos de tempo ou definir um intervalo Personalizado.

Autorizações para ver o painel de controlo

Se vir uma das seguintes mensagens de erro de acesso negado ao ver os detalhes de implementação de um serviço ou as métricas de um Google Cloud projeto, tem de atualizar a sua função de gestão de identidades e acessos 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, aceda a Funções predefinidas.

Autorizações da conta de serviço do cluster e do nó para escrever dados no Monitoring e Logging

Se vir taxas de erro elevadas na página APIs e serviços ativados na Google Cloud consola, a sua conta de serviço pode não ter as seguintes funções:

  • roles/logging.logWriter: na Google Cloud consola, esta função tem o nome Logs Writer. Para mais informações sobre as funções de registo, consulte o guia de controlo de acesso do registo.

  • roles/monitoring.metricWriter: na Google Cloud consola, esta função tem o nome Monitoring Metric Writer. Para mais informações sobre a monitorização de funções, consulte o guia de controlo de acesso.

  • roles/stackdriver.resourceMetadata.writer: na consola Google Cloud , esta função tem o nome Stackdriver Resource Metadata Writer. Esta função permite o acesso só de escrita aos metadados dos recursos e fornece exatamente as autorizações necessárias aos agentes para enviar metadados. Para mais informações sobre as funções de monitorização, consulte o guia de controlo de acesso da Monitorização.

Para listar as suas contas de serviço, na Google Cloud consola, aceda a IAM e administrador e, de seguida, selecione Contas de serviço.

Não é possível ver registos

Se não vir os seus registos nos painéis de controlo, verifique o seguinte:

O agente está em execução e em bom estado

A versão 1.17 e posteriores do GKE usa o Fluent Bit para capturar registos. O Fluent Bit é o agente de registo que é executado nos nós do Kubernetes. Para verificar se o agente está a ser executado corretamente, siga estes passos:

  1. Verifique se o agente está a ser reiniciado executando o seguinte comando:

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

    Se não existirem reinícios, o resultado é semelhante ao seguinte:

    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 do estado do pod executando o seguinte 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 implementação estiver em bom estado, o resultado é semelhante ao seguinte:

    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 estado do pod, que pode ajudar a determinar se a implementação está em bom estado executando o seguinte comando:

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

    Se a implementação estiver em bom estado, o resultado é semelhante ao seguinte:

    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 resultado, o estado pretendido corresponde ao estado atual.

Se o agente estiver em execução e em bom estado nestes cenários, e continuar a não ver todos os registos, o agente pode estar sobrecarregado e a ignorar registos.

O agente está sobrecarregado e a ignorar registos

Um dos motivos pelos quais não vê todos os seus registos é o volume de registos do nó estar a sobrecarregar o agente. A configuração predefinida do agente de registo no GKE está ajustada para a taxa de 100 kiB por segundo para cada nó, e o agente pode começar a ignorar registos se o volume exceder esse limite.

Para detetar se pode estar a atingir este limite, procure um dos seguintes indicadores:

  • Veja a métrica kubernetes.io/container/cpu/core_usage_time com o filtro container_name=fluentbit-gke para ver se a utilização da CPU do agente de registo está perto ou a 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 verificar alguma destas condições, pode reduzir o volume de registos dos seus nós adicionando mais nós ao cluster. Se todo o volume de registos provém de um único pod, tem de reduzir o volume desse pod.

Para mais informações sobre a investigação e a resolução de problemas relacionados com o registo do GKE, consulte o artigo Resolução de problemas de registo no GKE.

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

Se tiver uma condição de política de alerta que agregue métricas em recursos do GKE distintos, pode ter de editar a condição da política para incluir mais etiquetas da hierarquia do GKE para associar incidentes a entidades específicas.

Por exemplo, pode ter dois clusters do GKE, um para produção e outro para preparação, cada um com a sua própria cópia do serviçolilbuddy-2. Quando a condição da política de alerta agrega uma métrica em contentores em ambos os clusters, o painel de controlo do GKE Monitoring não consegue associar este incidente de forma exclusiva ao serviço de produção ou ao serviço de preparação.

Para resolver esta 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 cartão de evento do alerta, clique no link Atualizar política de alerta para abrir a página Editar política de alerta da política de alerta relevante. A partir daqui, pode atualizar a política de alertas com as informações adicionais para que o painel de controlo possa encontrar o recurso associado.

Depois de atualizar a política de alertas, o painel de controlo do GKE Monitoring consegue associar todos os incidentes futuros a um serviço único num cluster específico, o que lhe dá informações adicionais para diagnosticar o problema.

Consoante o seu exemplo de utilização, pode querer filtrar algumas destas etiquetas, além de as adicionar ao campo Agrupar por. Por exemplo, se só quiser alertas para o cluster de produção, pode filtrar por cluster_name.

O que se segue?