Versão 1.15

Versões disponíveis

1.20 (mais recente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Como resolver problemas de observabilidade e telemetria no Anthos Service Mesh

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 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 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 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-<Anthos Service Mesh fleet project number>.

Se metric.mesh_uid tiver qualquer outro valor, o painel do Anthos Service Mesh não vai exibir métricas. metric.mesh_uid é definido quando o Anthos 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 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.

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).