O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

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.
Rastreamento: determinado pela frequência de amostragem que você configura (normalmente, um a 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ço.

Verifique 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 Cloud Service Mesh.

Para listar as configurações da API de telemetria, execute o seguinte comando. 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 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

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

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 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 aparecerão na interface do usuário se a porta de serviço do O serviço do Kubernetes não se chama http ou qualquer nome com o 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á Cotas é a melhor 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 seu método de instalação para ver se há uma maneira de defini-lo com 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 no Cloud Service Mesh página "Métricas". Se nenhuma métrica aparecer, verifique se todos os pods na dos serviços do seu 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).