Esta é a documentação da malha de serviço v1.21.

Versões disponíveis

Cloud Service Mesh
1.22 archive
1.21 archive
1.20 archive
1.19 archive
1.18 archive

Esta página foi traduzida pela API Cloud Translation.

Solicitar registros do proxy

O Cloud Service Mesh oferece suporte a dois tipos diferentes de registros de acesso no Cloud Logging: Registros de tráfego (também conhecidos como registros de acesso da Observabilidade do Google Cloud) e Registros de acesso do Envoy. Nesta página, mostramos como ativar, desativar, visualizar e interpretar esses registros. Os registros de tráfego são ativados por padrão.

Como ativar e desativar registros de acesso

Cloud Service Mesh gerenciado

Registros de acesso do Envoy

Execute o comando a seguir para ativar os registros de acesso do Envoy e desativar os registros de tráfego:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-disable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
  - providers:
      - name: stackdriver
    disabled: true
EOF

O nome do provedor do registro de tráfego é stackdriver.

Registros de tráfego

Por padrão, os registros de tráfego estão ativados e os registros de acesso do Envoy estão desativados. Se você ativou anteriormente os registros de acesso do Envoy e quer ativar os registros de tráfego e desativar os registros de acesso do Envoy, execute o seguinte comando:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-enable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
EOF

Ambos

Para ativar os registros de acesso e de tráfego do Envoy, execute o seguinte comando:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-and-sd-access-log
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
      - name: stackdriver
EOF

Para desativar os registros de acesso e de tráfego do Envoy, execute o seguinte comando:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-and-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
    disabled: true
EOF

Gerenciado `istiod`

Registros de acesso do Envoy

Execute os seguintes comandos para ativar a geração de registros de acesso do Envoy:

Execute o seguinte comando para adicionar accessLogFile: /dev/stdout:

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

em que release-channel é o canal de lançamento (asm-managed, asm-managed-stable ou asm-managed-rapid).

Execute este comando para ver o configmap:

 kubectl get configmap istio-release-channel -n istio-system -o yaml

Para verificar se a geração de registros de acesso está ativada, verifique se a linha accessLogFile: /dev/stdout aparece na seção mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

Registros de tráfego

Os registros de tráfego são ativados por padrão.

No cluster

Registros de acesso do Envoy

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Para mais informações, consulte Ativar a geração de registros de acesso do Envoy.

Registros de tráfego

Os registros de tráfego são ativados por padrão, a menos que o Cloud Service Mesh esteja instalado no Google Distributed Cloud com a CA do Istio (anteriormente conhecida como Citadel).

Para ativar os registros de tráfego no Google Distributed Cloud com a CA do Istio ao instalar o Cloud Service Mesh no cluster, use a flag --option stackdriver. Como alternativa, é possível ativar os registros de tráfego no Google Distributed Cloud com a CA do Istio depois de instalar o Cloud Service Mesh no cluster.

Como conferir os registros de acesso

Registros de acesso do Envoy

Linha de comando

Para conferir os registros de acesso do Envoy no registro istio-proxy, execute o seguinte comando:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Explorador de registros

Para conferir os registros de acesso do Envoy no Explorador de registros:

Acesse o Explorador de registros:

Acesse o Explorador de registros
Selecione o projeto do Google Cloud apropriado.
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"

Registros de tráfego

Para ver registros de tráfego no Explorador de registros:

Acesse o Explorador de registros:

Acesse o Explorador de registros
Selecione o projeto do Google Cloud apropriado.

Execute a consulta a seguir, a depender de se você está visualizando os registros de acesso do cliente ou do servidor:

Registros do servidor

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

Registros do cliente

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

Para conferir os registros de tráfego na página do Cloud Service Mesh para um serviço durante um período especificado, siga estas etapas:

No console do Google Cloud, acesse a página Cloud Service Mesh.

Acessar a página do Cloud Service Mesh
Em Serviços, selecione o nome do serviço que você quer inspecionar.
Acesse a página Métricas.
Especifique um período no menu suspenso Período ou defina um período personalizado com a linha do tempo.
Em Selecionar uma opção de filtro, clique em Visualizar registros de tráfego.

O registro de tráfego é nomeado como server-accesslog-stackdriver e é anexado ao recurso monitorado correspondente (k8s_container ou gce_instance) que o serviço está usando. O registro de tráfego contém as seguintes informações:

Propriedades da solicitação HTTP, como ID, URL, tamanho, latência e cabeçalhos comuns.
Informações da carga de trabalho de origem e destino, como nome, namespace, identidade e rótulos comuns.
Se o rastreamento estiver ativado, informações de rastreamento, como amostragem, ID de rastreamento e ID de período.

Veja um exemplo de entrada de registro:

{
  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"
}

Interpretar a telemetria do Cloud Service Mesh

As seções a seguir explicam como verificar o status da malha e analisar as diversas telemetrias que contêm detalhes úteis para auxiliar a solução de problemas.

Interpretar as métricas do plano de controle

Cloud Service Mesh gerenciado

O Cloud Service Mesh com um plano de controle gerenciado não oferece suporte a métricas do plano de controle.

Gerenciado `istiod`

O Cloud Service Mesh com um plano de controle istiod gerenciado não oferece suporte à inspeção de métricas do plano de controle nesta seção.

No cluster

Ao instalar o Cloud Service Mesh com o plano de controle no cluster, por padrão, istiod exporta métricas para a Observabilidade do Google Cloud para monitoramento. istiod adiciona o prefixo istio.io/control a essas métricas e fornece insights sobre o estado do plano de controle, como o número de proxies conectados a cada instância, eventos de configuração, push e validações do plano de controle.

Observe ou resolva os problemas do plano de controle com as etapas a seguir.

Carregue um painel de amostra:

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

Instale o painel do Cloud Service Mesh:

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

Procure um painel chamado Istio Control Plane Dashboard na lista. Para mais informações, consulte Como visualizar o painel instalado.

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

Diagnosticar atrasos de configuração

Cloud Service Mesh gerenciado

O Cloud Service Mesh com um plano de controle gerenciado não oferece suporte para o diagnóstico de atrasos na configuração.

Gerenciado `istiod`

O Cloud Service Mesh com um plano de controle istiod gerenciado não oferece suporte para diagnosticar atrasos na configuração.

No cluster

As etapas a seguir explicam como usar a métrica pilot_proxy_convergence_time para diagnosticar um atraso entre uma alteração de configuração e todas as convergências de passagem.

Execute um comando shell em um pod:

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

Acesse localhost:15014 e grep para convergence nas métricas:
```
curl http://localhost:15014/metrics | grep convergence
```

Interpretar registros de tráfego

As informações a seguir explicam como usar os registros de tráfego para resolver problemas de conexão. Os registros de tráfego são ativados por padrão.

O Cloud Service Mesh exporta dados para os registros de tráfego que podem ajudar a depurar os seguintes tipos de problemas:

Fluxo de tráfego e falhas
Roteamento de solicitação de ponta a ponta

Os registros de tráfego são ativados por padrão para instalações do Cloud Service Mesh no Google Kubernetes Engine. Para ativar os registros de tráfego, execute asmcli install novamente. Use as mesmas opções que você instalou originalmente, mas omita a sobreposição personalizada que desativou o Stackdriver.

Há dois tipos de registros de tráfego:

Os registros de acesso ao servidor fornecem uma visão das solicitações. Eles estão localizados em server-accesslog-stackdriver, anexado ao recurso monitorado k8s_container. Use a seguinte sintaxe de URL para exibir registros 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 registros de acesso do cliente fornecem uma visão das solicitações do lado do cliente. Eles estão localizados em client-accesslog-stackdriver, anexado ao recurso monitorado k8s_pod. Use a seguinte sintaxe de URL para exibir registros 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 registros de acesso contêm as seguintes informações:

Propriedades da solicitação HTTP, como ID, URL, tamanho, latência e cabeçalhos comuns.
Informações da carga de trabalho de origem e destino, como nome, namespace, identidade e rótulos comuns.
Informações de revisão e canônicas do serviço de origem e destino.
Se o rastreamento estiver ativado, os registros vão conter informações de rastreamento, como amostragem, ID de rastreamento e ID do período.

Os registros de tráfego podem conter os seguintes rótulos:

route_name
upstream_cluster
X-Envoy-Original-Path

Este é um exemplo de entrada de registro:

{
  "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
}

É possível usar esse registro de várias formas:

Integre ao Cloud Trace, um recurso opcional do Cloud Service Mesh.
Exporte registros de tráfego para o BigQuery, em que é possível executar consultas, como selecionar todas as solicitações em mais de cinco segundos.
Crie métricas com base em registros.
Resolver problemas de erros 404 e 503

Resolver problemas de erros `404` e `503`

O exemplo a seguir explica como usar esse registro para solucionar problemas quando uma solicitação falha com um código de resposta 404 ou 503.

No registro de acesso do cliente, procure uma entrada como a 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"
}

Navegue até os rótulos na entrada de registro de acesso. Localize o campo response_flag como este:
```
response_flag: "NR"
```
O valor NR é um acrônimo para NoRoute, o que significa que nenhuma rota foi encontrada para o destino ou não há cadeia de filtros correspondente para uma conexão downstream. Da mesma forma, também é possível usar o rótulo response_flag para solucionar erros 503.
Se você encontrar erros 503 nos registros de acesso de cliente e servidor, verifique se os nomes de porta definidos para cada serviço correspondem ao nome do protocolo em uso entre eles. Por exemplo, se um cliente binário golang se conectar a um servidor desse tipo usando HTTP, mas a porta for chamada http2, o protocolo não fará a negociação automática corretamente.

Para mais informações, consulte sinalizações de resposta.

Interpretar registros de acesso do Envoy

As etapas a seguir explicam como usar os registros de acesso do Envoy para mostrar o tráfego entre as duas extremidades de uma conexão para fins de solução de problemas.

Os registros de acesso do Envoy são úteis para diagnosticar problemas como:

Fluxo de tráfego e falhas
Roteamento de solicitação de ponta a ponta

Os registros de acesso do Envoy não são ativados por padrão no Cloud Service Mesh e podem ser ativados para os clusters em uma malha.

Para solucionar falhas de conexão ou solicitação, gere uma atividade no aplicativo que acione uma solicitação HTTP e, em seguida, inspecione a solicitação associada nos registros de origem ou destino.

Se você acionar uma solicitação que aparecer nos registros do proxy de origem, isso indicará que o redirecionamento do tráfego iptables está funcionando corretamente e que o proxy Envoy está processando o tráfego. Se houver erros nos registros, gere um dump de configuração do Envoy e verifique a configuração do cluster envoy para garantir que ele esteja correto. Se você vir a solicitação, mas o registro não tiver erros, verifique os registros de proxy de destino.

Se a solicitação aparece nos registros do proxy de destino, isso indica que a malha está funcionando corretamente. Se você vir um erro, execute um dump da configuração Envoy e verifique os valores corretos para a porta de tráfego definida na configuração do listener.

Se o problema persistir após a execução das etapas anteriores, o Envoy poderá ser negociado automaticamente com o protocolo entre o arquivo secundário e o pod do aplicativo. Verifique se o nome da porta do serviço do Kubernetes, por exemplo, http-80, corresponde ao protocolo que o aplicativo usa.

Usar o Explorador de registros para consultar registros

É possível usar a interface do Explorador de registros para consultar registros de acesso específicos do Envoy. Por exemplo, para consultar todas as solicitações com MULTUAL_TLS ativado e usar o protocolo grpc, anexe o seguinte à consulta de registros de acesso ao servidor:

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

Definir uma política de registro de acesso

Cloud Service Mesh gerenciado

Para configurar os registros de acesso do Cloud Service Mesh com um plano de controle gerenciado do Cloud Service Mesh, consulte Ativar os registros de acesso.

Gerenciado `istiod`

Para configurar os registros de acesso do Cloud Service Mesh com um plano de controle istiod gerenciado, consulte Ativar os registros de acesso.

No cluster

Para definir uma política de registro de acesso para o Cloud Service Mesh com o plano de controle no cluster:

Crie um arquivo de sobreposição personalizada IstioOperator que inclua os valores AccessLogPolicyConfig aplicáveis para o cenário.
Transmita esse arquivo para asmcli usando a opção --custom_overlay para atualizar a configuração do plano de controle no cluster. Para informações sobre como executar asmcli install com um arquivo de sobreposição personalizado, consulte Instalar com recursos opcionais.

Cuidado: se você tiver personalizado a instalação anterior, precisará das mesmas personalizações ao reinstalar o plano de controle para incluir o arquivo com as configurações de AccessLogPolicyConfig. A omissão de um arquivo de sobreposição resulta em uma instalação bem-sucedida. No entanto, a malha de serviço tem uma configuração diferente da que você pretendia, porque os valores omitidos são redefinidos para os padrões quando o plano de controle é reimplantado.

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

Se você tiver um problema com um serviço ou carga de trabalho específico em vez de um problema em toda a malha, inspecione os proxies Envoy individuais e colete informações relevantes deles. Para coletar informações sobre uma carga de trabalho específica e os proxies, use pilot-agent:

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

No exemplo, SCOPE é um dos seguintes:

certs: certificados dentro da instância do Envoy
clusters: clusters com o Envoy configurado
config_dump: despeja a configuração do Envoy
listeners: listeners com o Envoy configurado
logging: visualizar e alterar as configurações de geração de registros
stats: estatísticas do Envoy
stats/prometheus: estatísticas do Envoy como registros do Prometheus

Visualizar estados dos soquetes do proxy

É possível examinar diretamente o estado dos soquetes do proxy Envoy usando o processo a seguir.

Exiba uma lista de soquetes estabelecidos, incluindo soquetes no estado TIME_WAIT, que poderão afetar negativamente a escalabilidade se a contagem for alta:
```
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
```

Exiba um resumo das estatísticas do soquete:

kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s

Para mais informações, consulte Uma introdução ao comando ss (em inglês).

Registros `istio-proxy` e `istio-init`

Além disso, recupere os registros istio-proxy e analise o conteúdo deles para identificar erros que podem sugerir a causa do problema:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

É possível fazer o mesmo para o contêiner init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

A seguir

Integração com o Cloud Trace. O Cloud Trace é um recurso opcional no Cloud Service Mesh.
Veja os registros de tráfego para o BigQuery
Crie métricas com base em registros.

Solicitar registros do proxy

Como ativar e desativar registros de acesso

Cloud Service Mesh gerenciado

Registros de acesso do Envoy

Registros de tráfego

Ambos

Gerenciado istiod

Registros de acesso do Envoy

Registros de tráfego

No cluster

Registros de acesso do Envoy

Registros de tráfego

Como conferir os registros de acesso

Registros de acesso do Envoy

Linha de comando

Explorador de registros

Registros de tráfego

Registros do servidor

Registros do cliente

Interpretar a telemetria do Cloud Service Mesh

Interpretar as métricas do plano de controle

Cloud Service Mesh gerenciado

Gerenciado istiod

No cluster

Diagnosticar atrasos de configuração

Cloud Service Mesh gerenciado

Gerenciado istiod

No cluster

Interpretar registros de tráfego

Resolver problemas de erros 404 e 503

Interpretar registros de acesso do Envoy

Usar o Explorador de registros para consultar registros

Definir uma política de registro de acesso

Cloud Service Mesh gerenciado

Gerenciado istiod

No cluster

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

Visualizar estados dos soquetes do proxy

Registros istio-proxy e istio-init

A seguir

Gerenciado `istiod`

Gerenciado `istiod`

Gerenciado `istiod`

Resolver problemas de erros `404` e `503`

Gerenciado `istiod`

Registros `istio-proxy` e `istio-init`