Resolver problemas de observabilidade e telemetria na malha de serviço da nuvem
Esta secção explica os problemas comuns do Cloud Service Mesh e como os resolver. Se precisar de assistência adicional, consulte o artigo Receber apoio técnico.
Na telemetria do Cloud Service Mesh, os proxies do Envoy chamam as APIs Google Cloud Observability periodicamente para comunicar dados de telemetria. O tipo de chamada API determina a respetiva frequência:
- Registo: a cada ~10 segundos
- Métricas: a cada ~1 minuto
- Limites (API Context/vista de topologia): relatórios incrementais a cada ~1 minuto, com relatórios completos a cada ~10 minutos.
- Rastreios: determinados pela frequência de amostragem que configurar (normalmente, um em cada 100 pedidos).
Os painéis de controlo de telemetria recolhem dados do Confluence e do Google Cloud Observability para apresentar os vários painéis de controlo focados nos serviços.
O painel de controlo de serviços não tem um serviço
O painel de controlo só apresenta serviços HTTP(S)/gRPC. Se o seu serviço deve estar na lista, verifique se a telemetria do Cloud Service Mesh o identifica como um serviço HTTP.
Se o serviço continuar em falta, verifique se existe uma configuração do serviço Kubernetes no cluster.
Reveja a lista de todos os serviços do Kubernetes:
kubectl get services --all-namespaces
Reveja a lista de serviços do Kubernetes num espaço de nomes específico:
kubectl get services -n YOUR_NAMESPACE
Métricas em falta ou incorretas para serviços
Se existirem métricas em falta ou incorretas para serviços no painel de controlo Serviços, consulte as secções seguintes para possíveis resoluções.
Verifique se existem proxies Sidecar e se foram injetados corretamente
O espaço de nomes pode não ter uma etiqueta para injeção automática ou a injeção manual falhou. Confirme se os pods no espaço de nomes têm, pelo menos, dois contentores e se um desses contentores é o contentor istio-proxy:
kubectl -n YOUR_NAMESPACE get pods
Verifique se existe uma configuração de telemetria
Use EnvoyFilters no espaço de nomes istio-system para configurar a telemetria.
Sem essa configuração, o Cloud Service Mesh não comunica dados ao Google Cloud Observability.
Verifique se a configuração do Google Cloud Observability (e a configuração de troca de metadados) existe:
kubectl -n istio-system get envoyfilter
O resultado esperado é semelhante ao seguinte:
NAME AGE metadata-exchange-1.4 13d metadata-exchange-1.5 13d stackdriver-filter-1.4 13d stackdriver-filter-1.5 13d ...
Para confirmar ainda mais que o filtro do Google Cloud Observability está configurado corretamente, recolha uma exportação da configuração de cada proxy e procure a presença do filtro do Google Cloud Observability:
kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy curl localhost:15000/config_dump
Na saída do comando anterior, procure o filtro Google Cloud Observability, que se assemelha ao seguinte:
"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": "{....}"
}Verifique se o Cloud Service Mesh identifica um serviço HTTP
As métricas não são apresentadas na interface do utilizador se a porta de serviço do serviço Kubernetes não tiver o nome http ou qualquer nome com o prefixo http-.
Confirme que o serviço tem os nomes adequados para as respetivas portas.
Verifique se a API Cloud Monitoring está ativada para o projeto
Confirme que a API Cloud Monitoring está ativada no painel de controlo de APIs e serviços na Google Cloud consola, que é a predefinição.
Verifique se não existem erros a serem comunicados à API Cloud Monitoring
No painel de controlo Google Cloud API e serviços da consola, 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 vir mensagens de erro, pode tratar-se de um problema que requer uma investigação mais aprofundada. Em particular, procure um grande número de mensagens de erro 429, que indicam um potencial problema de quota. Consulte a secção seguinte para ver os passos de resolução de problemas.
Valide a quota correta para a API Cloud Monitoring
Na Google Cloud consola, abra o menu IAM & Admin e verifique se existe uma opção Quotas. Pode aceder diretamente a esta página através do URL:
https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID
Esta página mostra o conjunto completo de quotas para o projeto, onde pode pesquisar
Cloud Monitoring API.
Verifique se não existem registos de erros nos proxies do Envoy
Reveja os registos do proxy em questão, pesquisando instâncias de mensagens 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 Explorador de métricas 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 estão a comunicar métricas e se o respetivo
metric.mesh_uid está no formato proj-<Cloud Service Mesh fleet project number>.
Se metric.mesh_uid tiver qualquer outro valor, o painel de controlo da malha de serviços na nuvem não apresenta métricas. metric.mesh_uid é definido quando o Cloud Service Mesh é instalado no cluster. Por isso, investigue o seu método de instalação para ver se existe uma forma de o definir para o valor esperado.
Dados de telemetria em falta ou incorretos para serviços
Por predefinição, o Cloud Monitoring e o Cloud Logging estão ativados no seu projetoGoogle Cloud quando instala o Cloud Service Mesh. Para comunicar dados de telemetria, cada proxy sidecar injetado nos seus pods de serviço chama a API Cloud Monitoring e a API Cloud Logging. Após a implementação de cargas de trabalho, os dados de telemetria demoram cerca de um ou dois minutos a ser apresentados na consolaGoogle Cloud . O Cloud Service Mesh mantém automaticamente os painéis de controlo dos serviços atualizados:
- Para as métricas, os proxies sidecar chamam a API Cloud Monitoring aproximadamente a cada minuto.
- Para atualizar o gráfico de topologia, os proxies sidecar enviam relatórios incrementais aproximadamente a cada minuto e relatórios completos a cada dez minutos.
- Para o registo, os proxies sidecar chamam a Cloud Logging API aproximadamente a cada dez segundos.
- Para a monitorização, tem de ativar o Cloud Trace. Os rastreios são comunicados de acordo com a frequência de amostragem que configurou (normalmente, um em cada 100 pedidos).
As métricas são apresentadas apenas para serviços HTTP na página Métricas da malha de serviços na nuvem. Se não vir nenhuma métrica, verifique se todos os pods no espaço de nomes dos serviços da sua aplicação têm proxies sidecar injetados:
kubectl get pod -n YOUR_NAMESPACE --all
Na saída, repare que a coluna READY mostra dois contentores para cada uma das suas cargas de trabalho: o contentor principal e o contentor para o proxy sidecar.
Além disso, o painel de controlo dos Serviços só apresenta métricas do servidor, pelo que os dados de telemetria podem não aparecer se o cliente não estiver na malha ou se estiver configurado para comunicar apenas métricas do cliente (como gateways de entrada).