Como resolver problemas de observabilidade e telemetria no Cloud Service Mesh

Nesta seção, explicamos problemas comuns do Cloud Service Mesh e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.

Na telemetria do Cloud Service Mesh, os proxies do Envoy chamam as APIs do Google Cloud Observability periodicamente para relatar dados de telemetria. O tipo de chamada de API determina a frequência dela:

  • Logging: a cada 10 segundos
  • Métricas: a cada 1 minuto ou menos
  • Arestas (API Context/visualização de topologia): relatórios incrementais a cada 1 minuto, com relatórios completos a cada 10 minutos.
  • Traces: determinados pela frequência de amostragem configurada (normalmente, uma de cada 100 solicitações).

Os painéis de telemetria coletam dados do Confluence e do Google Cloud Observability para mostrar os vários painéis focados em serviços.

Verificar se há no máximo uma configuração da API de telemetria do Istio

Esta seção se aplica apenas ao plano de controle gerenciado do Traffic Director.

Se você já tiver um CR da API de telemetria do Istio, inclua-o no novo CR da API de telemetria do Istio para preservar as configurações de personalização anteriores no CR de telemetria do Istio atual.

Para listar as configurações da API de telemetria, execute o comando a seguir. Verifique se há no máximo uma configuração da API de telemetria do Istio.

kubectl -n istio-system get telemetry

O painel de serviços não tem um serviço

O painel exibe apenas serviços HTTP(S)/gRPC. Se o serviço estiver na lista, verifique se a telemetria do Cloud Service Mesh o identifica como um serviço HTTP.

Se o serviço ainda estiver ausente, verifique se uma configuração de serviço do Kubernetes existe no cluster.

  • Veja a lista de todos os serviços do Kubernetes:

    kubectl get services --all-namespaces

  • Revise a lista de serviços do Kubernetes em um namespace específico:

    kubectl get services -n YOUR_NAMESPACE

Métricas ausentes ou incorretas para serviços

Se houver métricas ausentes ou incorretas para os serviços no painel "Serviços", consulte as seções a seguir para possíveis soluções.

Verificar se há proxies sidecar e se eles foram injetados corretamente

O namespace pode não ter um rótulo para injeção automática ou a injeção manual falhou. Confirme se os pods no namespace têm pelo menos dois contêineres e se um deles é o contêiner istio-proxy:

kubectl -n YOUR_NAMESPACE get pods

Verificar se a configuração de telemetria existe

Para confirmar se o filtro do Google Cloud Observability está configurado, colete um despejo de configuração de cada proxy e procure a presença do filtro do Google Cloud Observability:

kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump

Na saída do comando anterior, procure o filtro do Google Cloud Observability, que é semelhante a este:

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

Verificar se o Cloud Service Mesh identifica um serviço HTTP

As métricas não serão mostradas na interface do usuário se a porta do serviço do Kubernetes não tiver o nome http ou qualquer nome com um prefixo http-. Confirme se o serviço tem os nomes corretos das portas.

Verificar se a API Cloud Monitoring está ativada para o projeto

Confirme se a API Cloud Monitoring está ativada no painel de APIs e serviços no Google Cloud console, que é o padrão.

Verificar nenhum relatório de erros para a API Cloud Monitoring

No painel da API e dos serviços do Google Cloud console, abra o URL do gráfico " Tráfego por código de resposta":

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

Se você vir mensagens de erro, isso pode ser um problema que justifica uma investigação mais detalhada. Procure especificamente um grande número de mensagens de erro 429, que indica um possível problema de cota. Veja a próxima seção para ver as etapas de solução de problemas.

Verificar a cota correta para a API Cloud Monitoring

No Google Cloud console, abra o IAM & Admin menu e verifique se há uma Cotas opção. Acesse essa página diretamente usando o URL:

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

Esta página mostra o conjunto completo de cotas do projeto, em que é possível pesquisar Cloud Monitoring API.

Verificar se não há registros de erro em proxies do Envoy

Analise os registros do proxy em questão, procurando instâncias de mensagem de erro:

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

No entanto, ignore as mensagens de aviso como as seguintes, que são normais:

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

Verifique se metric.mesh_uid está definido corretamente

Abra o Metrics Explorer e execute a seguinte consulta MQL:

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

Verifique se todos os serviços esperados são métricas de relatório e se o metric.mesh_uid está no formato proj-<Cloud Service Mesh fleet project number>.

Se metric.mesh_uid tiver qualquer outro valor, o painel do Cloud Service Mesh não vai mostrar métricas. metric.mesh_uid é definido quando o Cloud Service Mesh é instalado no cluster. Portanto, investigue o método de instalação para ver se há uma maneira de definir o valor esperado.

Dados de telemetria ausentes ou incorretos para serviços

Por padrão, o Cloud Monitoring e o Cloud Logging são ativados no seu Google Cloud projeto quando você instala o Cloud Service Mesh. Para relatar dados de telemetria, cada proxy sidecar inserido nos pods de serviço chama a API Cloud Monitoring e a API Cloud Logging. Depois de implantar cargas de trabalho, leva cerca de um ou dois minutos para que os dados de telemetria sejam mostrados no Google Cloud console. O Cloud Service Mesh mantém os painéis de serviço atualizados automaticamente:

  • Para métricas, os proxies sidecar chamam a API Cloud Monitoring aproximadamente a cada minuto.
  • Para atualizar o gráfico da topologia, os proxies sidecar enviam relatórios incrementais aproximadamente a cada minuto e relatórios completos a cada dez minutos.
  • Para a geração de registros, os proxies sidecar chamam a API Cloud Logging aproximadamente a cada dez segundos.
  • Para rastreamento, é necessário ativar o Cloud Trace. Os traces são relatados de acordo com a frequência de amostragem configurada (normalmente, uma de cada 100 solicitações).

As métricas são mostradas apenas para serviços HTTP na página de métricas do Cloud Service Mesh. Se você não encontrar nenhuma métrica, verifique se todos os pods no namespace dos serviços do aplicativo têm proxies sidecar injetados:

kubectl get pod -n YOUR_NAMESPACE --all

No resultado, observe que a coluna READY mostra dois contêineres para cada uma de suas cargas de trabalho: o primário e o contêiner do proxy sidecar.

Além disso, o painel de serviços exibe apenas métricas do servidor. Portanto, é possível que os dados de telemetria não apareçam se o cliente não estiver na malha ou se estiver configurado para relatar apenas métricas do cliente (como gateways de entrada).