Nesta seção, explicamos problemas comuns do Anthos Service Mesh e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.
Na telemetria do Anthos Service Mesh, os proxies do Envoy chamam as APIs de observabilidade do Google Cloud periodicamente para informar 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 mostrar os diversos painéis com foco em serviços.
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 Anthos 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 {: class="external"}
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/incorretas para serviços
Se houver métricas ausentes ou incorretas para os serviços no painel, 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 Anthos Service Mesh não vai relatar dados para a observabilidade do Google Cloud.
Verifique se a configuração de observabilidade do Google Cloud (e a configuração de 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 se o filtro de observabilidade do Google Cloud está configurado corretamente, colete um dump de configuração de cada proxy e procure esse filtro:
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 tem a seguinte aparência:
"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 Anthos 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 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 Google Cloud Console e serviços, abra o gráfico de tráfego por código de resposta.
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
Dados de telemetria ausentes ou incorretos para serviços
Por padrão, o Cloud Monitoring e o Cloud Logging são ativados no projeto do Google Cloud quando você instala o Anthos 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 Anthos 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 Anthos 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.