Como resolver problemas de observabilidade e telemetria no Cloud Service Mesh
Esta seção explica 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
- Edges (API Context/Topologia): relatórios incrementais a cada minuto, com relatórios completos a cada 10 minutos, aproximadamente.
- Traces: determinado pela frequência de amostragem que você configura. Normalmente, um em cada 100 solicitações.
Os painéis de telemetria coletam dados do Confluence e da Observabilidade do Google Cloud para exibir os diversos painéis com foco em serviço.
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 permanecer ausente, verifique se há uma configuração de serviço do Kubernetes 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 está no contêiner istio-proxy:
kubectl -n YOUR_NAMESPACE get pods
Verificar se a configuração de telemetria existe
Use EnvoyFilters no namespace istio-system
para configurar a telemetria.
Sem essa configuração, o Cloud Service Mesh não vai informar dados à Observabilidade do Google Cloud.
Verifique se a configuração da Observabilidade do Google Cloud (e a configuração da troca de metadados) existe:
kubectl -n istio-system get envoyfilter
A saída esperada será semelhante a esta:
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 que o filtro de Observabilidade do Google Cloud esteja configurado corretamente, reúna um despejo de configuração de cada proxy e procure a presença do filtro de Observabilidade do Google Cloud:
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 de Observabilidade do Google Cloud, 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 exibidas 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 Console do Google Cloud, que é o padrão.
Verificar nenhum relatório de erros para a API Cloud Monitoring
No painel da API e dos serviços do Console do Google Cloud, 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 Console do Google Cloud, abra o menu IAM & Admin
e verifique se há uma opção
Cotas. 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 exibir 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 projeto do Google Cloud 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 exibidos no Console do Google Cloud. 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 exibidas apenas para serviços HTTP na página de métricas do Cloud Service Mesh. Se você não vir métricas, verifique se todos os pods no namespace dos serviços do aplicativo têm proxies sidecar:
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).