Peça registos de proxy

As páginas do Cloud Service Mesh fornecem links para dois tipos diferentes de registos no Cloud Logging: Registos de acesso (também conhecidos como registos do Envoy) e Registos de tráfego (também conhecidos como registos de acesso da Google Cloud Observability).

Registos de acesso

Ative os registos de acesso

Os passos necessários para ativar os registos de acesso dependem do tipo de Cloud Service Mesh, quer seja gerido ou no cluster:

Gerido

Siga as instruções para ativar os registos de acesso na malha de serviços na nuvem gerida.

No cluster

Siga as instruções para ativar os registos de acesso na Cloud Service Mesh no cluster.

Veja registos de acesso

Para ver os registos de acesso no Explorador de registos:

1. Navegue para o Explorador de registos:

   Aceda ao Explorador de registos

2. Selecione o Google Cloud projeto adequado.

3. Execute a seguinte consulta:

   resource.type="k8s_container" \
   resource.labels.container_name="istio-proxy"
   resource.labels.cluster_name="CLUSTER_NAME" \
   resource.labels.namespace_name="NAMESPACE_NAME" \
   resource.labels.pod_name="POD_NAME"
   

Registos de tráfego

Ative os registos de tráfego

Os registos de tráfego estão ativados por predefinição, exceto se o Cloud Service Mesh estiver instalado no Google Distributed Cloud com a AC do Istio (anteriormente conhecido como Citadel).

Para ativar os registos de tráfego no Google Distributed Cloud com a CA do Istio quando instalar o Cloud Service Mesh no cluster, use a flag --option stackdriver. Em alternativa, pode ativar os registos de tráfego no Google Distributed Cloud com a AC do Istio depois de instalar o Cloud Service Mesh no cluster.

Veja os registos de tráfego

Veja registos de tráfego no Explorador de registos

Para ver os registos de tráfego no Explorador de registos:

1. Navegue para o Explorador de registos:

   Aceda ao Explorador de registos

2. Selecione o Google Cloud projeto adequado.

3. Execute a seguinte consulta consoante esteja a ver registos de acesso do cliente ou do servidor:

   Registos do servidor

   resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"
   

   Registos do cliente

   resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"
   

Veja registos de tráfego na página do Anthos Service Mesh

Para ver os registos de tráfego na página Cloud Service Mesh de um serviço durante um intervalo de tempo especificado, siga estes passos:

1. Na Google Cloud consola, aceda à página Cloud Service Mesh.

   Aceda à página Cloud Service Mesh

2. Em Serviços, selecione o nome do serviço que quer inspecionar.

3. Aceda à página Métricas.

4. Especifique um período no menu pendente Período ou defina um período personalizado com a cronologia.

5. Clique em Ver registos de tráfego.

O registo de tráfego tem o nome server-accesslog-stackdriver e está anexado ao recurso monitorizado correspondente (k8s_container ou gce_instance) que o seu serviço está a usar. O registo de tráfego contém as seguintes informações:

• Propriedades do pedido HTTP, como ID, URL, tamanho, latência e cabeçalhos comuns.

• Informações da carga de trabalho de origem e destino, como o nome, o espaço de nomes, a identidade e as etiquetas comuns.

• Se a monitorização estiver ativada, são apresentadas informações de rastreio, como a amostragem, o ID de rastreio e o ID de intervalo.

Uma entrada de registo de exemplo tem o seguinte aspeto:

{
  insertId: "1awb4hug5pos2qi"
  httpRequest: {
    requestMethod: "GET"
    requestUrl: "YOUR-INGRESS/productpage"
    requestSize: "952"
    status: 200
    responseSize: "5875"
    remoteIp: "10.8.0.44:0"
    serverIp: "10.56.4.25:9080"
    latency: "1.587232023s"
    protocol: "http"
  }
  resource: {
    type: "k8s_container"
    labels: {
      location: "us-central1-a"
      project_id: "YOUR-PROJECT"
      pod_name: "productpage-v1-76589d9fdc-ptnt9"
      cluster_name: "YOUR-CLUSTER-NAME"
      container_name: "productpage"
      namespace_name: "default"
    }
  }
  timestamp: "2020-04-28T19:55:21.056759Z"
  severity: "INFO"
  labels: {
    destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage"
    response_flag: "-"
    destination_service_host: "productpage.default.svc.cluster.local"
    source_app: "istio-ingressgateway"
    service_authentication_policy: "MUTUAL_TLS"
    source_name: "istio-ingressgateway-5ff85d8dd8-mwplb"
    mesh_uid: "YOUR-MESH-UID"
    request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632"
    destination_namespace: "default"
    source_principal:  "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    destination_workload: "productpage-v1"
    destination_version: "v1"
    source_namespace: "istio-system"
    source_workload: "istio-ingressgateway"
    destination_name: "productpage-v1-76589d9fdc-ptnt9"
    destination_app: "productpage"
  }
  trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536"
  receiveTimestamp: "2020-04-29T03:07:14.362416217Z"
  spanId: "43226343ca2bb2b1"
  traceSampled: true
  logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver"
  receiveTimestamp: "2020-04-28T19:55:32.185229100Z"
}

Interprete a telemetria do Anthos Service Mesh

As secções seguintes explicam como verificar o estado da malha e rever as várias telemetrias que contêm detalhes úteis para ajudar na resolução de problemas.

Interprete as métricas do plano de controlo

Quando instala o Cloud Service Mesh com o plano de controlo no cluster, istiod exporta métricas para o Google Cloud Observability para monitorização, por predefinição. istiod prefixa estas métricas com istio.io/control e fornece estatísticas sobre o estado do plano de controlo, como o número de proxies ligados a cada instância do plano de controlo, eventos de configuração, envios e validações.

Observe ou resolva problemas do plano de controlo através dos seguintes passos.

1. Carregue um painel de controlo de exemplo:

   git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh

2. Instale o painel de controlo do Cloud Service Mesh:

   gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json

3. Procure um painel de controlo com o nome Istio Control Plane Dashboard na lista. Para mais informações, consulte o artigo Ver o painel de controlo instalado.

Para ver a lista completa de métricas disponíveis, consulte o artigo Métricas exportadas.

Diagnostique atrasos na configuração

Os passos seguintes explicam como usar a métrica pilot_proxy_convergence_time para diagnosticar um atraso entre uma alteração de configuração e a convergência de todos os proxies.

1. Executar um comando shell num pod:

   kubectl exec -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -c istio-proxy -- curl -s

2. Aceda a localhost:15014 e grep para convergence nas métricas:

   curl http://localhost:15014/metrics | grep convergence

Interprete os registos de acesso da observabilidade do Google Cloud

As informações seguintes explicam como usar os registos de acesso do Google Cloud Observability para resolver problemas de ligação. Os registos de acesso/tráfego do Google Cloud Observability estão ativados por predefinição.

O Cloud Service Mesh exporta dados para os registos de acesso do Google Cloud Observability, que podem ajudar a depurar os seguintes tipos de problemas:

• Fluxo de tráfego e falhas
• Encaminhamento de pedidos ponto a ponto

Os registos de acesso do Google Cloud Observability estão ativados por predefinição para instalações do Cloud Service Mesh no Google Kubernetes Engine. Pode ativar os registos de acesso do Google Cloud Observability executando novamente asmcli install. Use as mesmas opções que instalou originalmente, mas omita a sobreposição personalizada que desativou o Stackdriver.

Existem dois tipos de registos de acesso:

• Os registos de acesso ao servidor dão uma vista do lado do servidor dos pedidos. Estão localizadas em server-accesslog-stackdriver, anexadas ao recurso k8s_container monitorizado. Use a seguinte sintaxe de URL para apresentar registos de acesso do lado do servidor:

  https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID

• Os registos de acesso do cliente oferecem uma vista dos pedidos do lado do cliente. Estão localizadas em client-accesslog-stackdriver, anexadas ao recurso monitorizado k8s_pod. Use a seguinte sintaxe de URL para apresentar registos de acesso do lado do cliente:

  https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID

Os registos de acesso contêm as seguintes informações:

• Propriedades do pedido HTTP, como ID, URL, tamanho, latência e cabeçalhos comuns.
• Informações da carga de trabalho de origem e destino, como o nome, o espaço de nomes, a identidade e as etiquetas comuns.
• Informações canónicas do serviço e da revisão de origem e destino.
• Se a monitorização estiver ativada, os registos contêm informações de rastreio, como amostragem, ID de rastreio e ID de intervalo.

As informações apresentadas nos registos de acesso do Google Cloud Observability têm origem nos registos de acesso do Envoy, quando os ativa na configuração do Istio. Contêm os seguintes cabeçalhos:

• route_name
• upstream_cluster
• X-Envoy-Original-Path
• X-Envoy-Original-Host

Este é um exemplo de uma entrada de registo:

{
  "insertId": "1j84zg8g68vb62z",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "http://35.235.89.201:80/productpage",
    "requestSize": "795",
    "status": 200,
    "responseSize": "7005",
    "remoteIp": "10.168.0.26:0",
    "serverIp": "10.36.3.153:9080",
    "latency": "0.229384205s",
    "protocol": "http"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "cluster_name": "istio-e2e22",
      "namespace_name": "istio-bookinfo-1-68819",
      "container_name": "productpage",
      "project_id": "***",
      "location": "us-west2-a",
      "pod_name": "productpage-v1-64794f5db4-8xbtf"
    }
  },
  "timestamp": "2020-08-13T21:37:42.963881Z",
  "severity": "INFO",
  "labels": {
    "protocol": "http",
    "upstream_host": "127.0.0.1:9080",
    "source_canonical_service": "istio-ingressgateway",
    "source_namespace": "istio-system",
    "x-envoy-original-path": "",
    "source_canonical_revision": "latest",
    "connection_id": "32",
    "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_version": "v1",
    "destination_workload": "productpage-v1",
    "source_workload": "istio-ingressgateway",
    "destination_canonical_revision": "v1",
    "mesh_uid": "cluster.local",
    "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account",
    "x-envoy-original-dst-host": "",
    "service_authentication_policy": "MUTUAL_TLS",
    "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage",
    "response_flag": "-",
    "log_sampled": "false",
    "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_name": "productpage-v1-64794f5db4-8xbtf",
    "destination_canonical_service": "productpage",
    "destination_namespace": "istio-bookinfo-1-68819",
    "source_name": "istio-ingressgateway-6845f6d664-lnfvp",
    "source_app": "istio-ingressgateway",
    "destination_app": "productpage",
    "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4",
    "route_name": "default"
  },
  "logName": "projects/***/logs/server-accesslog-stackdriver",
  "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f",
  "receiveTimestamp": "2020-08-13T21:37:48.758673203Z",
  "spanId": "633831cb1fda4fd5",
  "traceSampled": true
}

Pode usar este registo de várias formas:

• Integre-se com o Cloud Trace, que é uma funcionalidade opcional no Cloud Service Mesh.
• Exporte registos de tráfego para o BigQuery, onde pode executar consultas como selecionar todos os pedidos que demoram mais de 5 segundos.
• Crie métricas baseadas em registos.
• Resolva problemas de erros 404 e 503

Resolva problemas de erros 404 e 503

O exemplo seguinte explica como usar este registo para resolver problemas quando um pedido falha com um código de resposta 404 ou 503.

1. No registo de acesso do cliente, pesquise uma entrada semelhante à seguinte:

   httpRequest: {
   requestMethod: "GET"
   requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php"
   requestSize: "2088"
   status: 404
   responseSize: "75"
   remoteIp: "10.168.0.26:34165"
   serverIp: "10.36.3.149:8080"
   latency: "0.000371440s"
   protocol: "http"
   }

2. Navegue para as etiquetas na entrada do registo de acesso. Encontre o campo response_flag semelhante ao seguinte:

   response_flag: "NR"

   O valor NR é um acrónimo de NoRoute, o que significa que não foi encontrada nenhuma rota para o destino ou que não existia nenhuma cadeia de filtros correspondente para uma ligação a jusante. Da mesma forma, também pode usar a etiqueta response_flag para resolver problemas de erros 503.

3. Se vir erros 503 nos registos de acesso do cliente e do servidor, verifique se os nomes das portas definidos para cada serviço correspondem ao nome do protocolo em utilização entre eles. Por exemplo, se um cliente binário golang se ligar a um servidor golang através de HTTP, mas a porta tiver o nome http2, o protocolo não é negociado automaticamente corretamente.

Para mais informações, consulte as flags de resposta.

Interprete os registos de acesso

Os passos seguintes explicam como usar os registos de acesso (também conhecidos como registos do proxy Envoy) para mostrar o tráfego entre ambas as extremidades de uma ligação para fins de resolução de problemas.

Os registos de acesso são úteis para diagnosticar problemas como:

• Fluxo de tráfego e falhas
• Encaminhamento de pedidos ponto a ponto

Os registos de acesso não estão ativados por predefinição na Cloud Service Mesh e só podem ser ativados globalmente em toda a malha.

Nota: os registos do Google Cloud Observability são os registos preferenciais para a maioria dos cenários de resolução de problemas. No entanto, se o problema persistir, ative os registos de acesso para resolver problemas adicionais.

Pode resolver problemas de falhas de ligação/pedido gerando atividade na sua aplicação que aciona um pedido HTTP e, em seguida, inspecionando o pedido associado nos registos de origem ou de destino.

Se for acionado um pedido e este aparecer nos registos do proxy de origem, significa que o redirecionamento de tráfego iptables está a funcionar corretamente e o proxy do Envoy está a processar o tráfego. Se vir erros nos registos, gere um despejo da configuração do Envoy e verifique a configuração do cluster do Envoy para garantir que está correta. Se vir o pedido, mas o registo não tiver erros, verifique os registos do proxy de destino.

Se o pedido aparecer nos registos do proxy de destino, indica que a malha está a funcionar corretamente. Se vir um erro, execute um despejo da configuração do Envoy e verifique os valores corretos para a porta de tráfego definida na configuração do ouvinte.

Se o problema persistir após executar os passos anteriores, o Envoy pode não conseguir negociar automaticamente o protocolo entre o sidecar e o respetivo pod de aplicação. Certifique-se de que o nome da porta do serviço Kubernetes, por exemplo, http-80, corresponde ao protocolo usado pela aplicação.

Use o Explorador de registos para consultar registos

Pode usar a interface do Explorador de registos para consultar registos de acesso específicos. Por exemplo, para consultar todos os pedidos que têm o parâmetro MULTUAL_TLS ativado e usam o protocolo grpc, acrescente o seguinte à consulta dos registos de acesso do servidor:

labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"

Defina uma política de registo de acesso

Para configurar o registo de proxy para a malha de serviços na nuvem gerida, consulte o artigo Registos de acesso do Envoy.

Para definir uma política de registo de acesso para a Cloud Service Mesh com o plano de controlo no cluster:

1. Crie um ficheiro de sobreposição personalizado IstioOperator que inclua os valores AccessLogPolicyConfig aplicáveis ao seu cenário.

2. Transmita este ficheiro ao asmcli através da opção --custom_overlay para atualizar a configuração do plano de controlo no cluster. Para obter informações sobre a execução do asmcli install com um ficheiro de sobreposição personalizado, consulte o artigo Instale com funcionalidades opcionais.

   Atenção: se personalizou a instalação anterior, precisa das mesmas personalizações quando reinstalar o plano de controlo para incluir o ficheiro com as definições AccessLogPolicyConfig. A omissão de um ficheiro de sobreposição resulta numa instalação bem-sucedida. No entanto, a sua malha de serviços tem uma configuração diferente da pretendida, porque os valores omitidos são repostos para os predefinidos quando o plano de controlo é reimplementado.

Veja informações específicas do serviço ou da carga de trabalho

Se tiver um problema com um serviço ou uma carga de trabalho específicos, em vez de um problema em toda a malha, inspecione os proxies Envoy individuais e recolha informações relevantes dos mesmos. Para reunir informações sobre uma carga de trabalho específica e os respetivos proxies, pode usar o pilot-agent:

kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- pilot-agent request GET SCOPE

No exemplo, SCOPE é uma das seguintes opções:

• certs - Certificados na instância do Envoy
• clusters – Clusters com o Envoy configurado
• config_dump: despeja a configuração do Envoy
• listeners – Ouvintes com o Envoy configurado
• logging – Veja e altere as definições de registo
• stats – Estatísticas do Envoy
• stats/prometheus – Estatísticas do Envoy como registos do Prometheus

Nota: config_dump e stats são as opções que têm maior probabilidade de produzir informações acionáveis.

Veja os estados dos sockets de proxy

Pode examinar diretamente o estado das entradas do proxy Envoy através do seguinte processo.

1. Apresente uma lista de sockets estabelecidos, incluindo sockets no estado TIME_WAIT que podem afetar negativamente a escalabilidade se o respetivo número for elevado:

   kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- ss -anopim

2. Apresentar um resumo das estatísticas de sockets:

   kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- ss -s

Para mais informações, consulte o artigo Uma introdução ao comando ss.

istio-proxy e istio-init registos

Além disso, obtenha os registos do istio-proxy e reveja o respetivo conteúdo para verificar se existem erros que possam sugerir a causa do problema:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Pode fazer o mesmo para o contentor init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

O que se segue?

• Faça a integração com o Cloud Trace. O Cloud Trace é uma funcionalidade opcional no Cloud Service Mesh.

• Exporte registos de tráfego para o BigQuery.

• Crie métricas baseadas em registos.