O Anthos Service Mesh 1.4 chegou ao fim da vida útil e não é mais compatível. Consulte Como fazer upgrade de versões anteriores.

Veja uma mais recente ou selecione outra versão disponível:

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 solucionar problemas de observabilidade

Nesta página, descrevemos como solucionar problemas nas páginas do Anthos Service Mesh no Console do Google Cloud.

A lista de serviços não tem um serviço específico

Se um serviço estiver faltando na lista, confirme se há uma configuração de serviço do Kubernetes no cluster.

Para ver uma lista de todos os serviços do Kubernetes:

 kubectl get services --all-namespaces

Para uma lista de serviços do Kubernetes em um namespace específico:

kubectl get services -n YOUR_NAMESPACE

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 o seguinte:

Verificar se proxies sidecar foram injetados

Verifique se todos os pods no namespace dos serviços do aplicativo têm proxies sidecar injetados:

kubectl get pod -n YOUR_NAMESPACE --all

No exemplo de saída a seguir do comando anterior, observe que a coluna READY indica que há dois contêineres para cada uma de suas cargas de trabalho: o primário e o contêiner do proxy sidecar.

NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...

Se você não vir dois contêineres, verifique se o namespace tem o rótulo istio-injection=enabled, que indica que a injeção automática de sidecar está ativada:

  kubectl get ns --show-labels

Exemplo de saída:

NAME              STATUS   AGE   LABELS
default           Active   35m   istio-injection=enabled
istio-system      Active   34m   istio-injection=disabled,istio-operator-managed=Reconcile

Se você não vir o rótulo istio-injection=enabled, execute o comando a seguir para ativar a injeção automática de sidecar:
```
kubectl label namespace YOUR_NAMESPACE istio-injection=enabled --overwrite
```
Se você vir o rótulo istio-injection=enabled e tiver instalado o Anthos Service Mesh em um cluster atual do Google Kubernetes Engine com cargas de trabalho, reinicie todos os pods em execução para que o proxy sidecar seja injetado ou atualizado com a versão atual Anthos Service Mesh. Consulte Como atualizar sidecars para pods atuais para saber mais.

Verificar os nomes das portas de serviço do Kubernetes

Verifique os nomes de porta do serviço Kubernetes para verificar se o Anthos Service Mesh considera o serviço como um serviço HTTP. Para serem incluídas no Anthos Service Mesh, as portas de serviço precisam ser nomeadas e o nome precisa incluir o protocolo da porta. Por exemplo:

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

O nome da porta do serviço pode incluir um sufixo na seguinte sintaxe: name: protocol[-suffix], em que os colchetes indicam um sufixo opcional que precisa começar com um traço, por exemplo:

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

Para que as métricas sejam exibidas no Console do Google Cloud, as portas de serviço precisam ser nomeadas com um dos seguintes protocolos: http, http2 ou grpc. As portas de serviço nomeadas com o protocolo https são tratadas como tcp e as métricas não são exibidas para esses serviços.

Verificar se as APIs necessárias estão ativadas

O Anthos Service Mesh exige várias APIs para gerar relatórios e exibir a telemetria. Para ver quais APIs estão ativadas para seu projeto, use o comando gcloud services list ou ative todas as APIs necessárias para garantir que todas elas sejam recebidas.

Defina o projeto padrão para a Google Cloud CLI:
```
gcloud config set project YOUR_PROJECT_ID
```

Ative todas as APIs necessárias:

gcloud services enable \
   container.googleapis.com \
   compute.googleapis.com \
   monitoring.googleapis.com \
   logging.googleapis.com \
   meshca.googleapis.com \
   meshtelemetry.googleapis.com \
   meshconfig.googleapis.com \
   iamcredentials.googleapis.com \
   anthos.googleapis.com

Verificar se a conta de serviço do plano de dados do ASM Mesh existe

No Console do Cloud, abra a página do IAM.

Abrir a página do IAM
Selecione o projeto.
Na lista de membros, procure uma conta de serviço com o nome ASM Mesh Data Plane Service Account.

Se a conta de serviço não existir, crie-a:

curl --request POST \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data '' \
  https://meshconfig.googleapis.com/v1alpha1/projects/YOUR_PROJECT_ID:initialize

Verificar se as cargas de trabalho estão em execução

No Console do Google Cloud, abra a página Cargas de trabalho do GKE:

Abra as cargas de trabalho do GKE
Selecione o projeto.
Adicione um filtro ao cluster. Verifique se todas as cargas de trabalho do aplicativo e do Anthos Service Mesh estão funcionando com o status OK. Uma carga de trabalho pode falhar por conta de recursos limitados (CPU, memória etc.). Nesse caso, você precisa fazer upgrade do cluster para ter mais recursos. Consulte Como redimensionar um cluster para mais informações.

Verificar se o aplicativo está veiculando solicitações

Verifique se o aplicativo está disponibilizando as solicitações de modo eficaz. O QPS pode ser baixo, mas deve estar recebendo tráfego.

O gráfico de topologia está vazio

Se o gráfico de topologia não estiver mostrando serviços e exibir a mensagem de erro No data available to graph. Check your filters and try again, verifique o seguinte:

Verificar o ID da malha

Verifique se o cluster tem o rótulo mesh_id correto:

Encontre o número do projeto, que é um número exclusivo gerado automaticamente quando você cria o projeto.
Verifique se o cluster tem um rótulo mesh_id no seguinte formato: mesh_id: proj-PROJECT_NUMBER

Corrija o rótulo mesh_id se ele estiver ausente ou incorreto. Para mais informações, consulte Como adicionar ou atualizar rótulos em clusters atuais.

Configure as variáveis de ambiente a seguir:

Defina o ID do projeto:
```
export PROJECT_ID=YOUR_PROJECT_ID
```

Defina o número do projeto:

export PROJECT_NUMBER=YOUR_PROJECT_NUMBER

Defina o nome do cluster:
```
export CLUSTER_NAME=YOUR_CLUSTER_NAME
```
Defina CLUSTER_LOCATION como a zona ou a região do cluster:
```
export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
```

Defina o pool de carga de trabalho:

export WORKLOAD_POOL=${PROJECT_ID}.svc.id.goog

Defina o ID da malha:
```
export MESH_ID="proj-${PROJECT_NUMBER}"
```

Reimplante o Anthos Service Mesh com as mesmas opções que você usou anteriormente.
Todas as cargas de trabalho em execução no cluster antes da instalação do Anthos Service Mesh precisam ter o proxy sidecar atualizado para que tenham a versão atual do Anthos Service Mesh.
```
kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE
```