Nas seções a seguir, explicamos como verificar o status da malha e analisar os diversos registros que contêm detalhes úteis para auxiliar a solução de problemas.
Interpretar as métricas do plano de controle
Ao instalar o Anthos Service Mesh usando o perfil asm-gcp
, o Istiod exporta
métricas para a observabilidade do Google Cloud para monitoramento, por padrão. O 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 && git checkout asm
Instale o painel do Anthos 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.Se você não estiver usando o perfil
asm-gcp
, ainda poderá ativar as métricas do plano de controle adicionando as variáveis de ambiente à implantação do Istiod:- name: ENABLE_STACKDRIVER_MONITORING value: "true"
Além disso, é possível adicionar essa variável de ambiente usando a opção de instalação
components.pilot.k8s.env
.
Para ver a lista completa de métricas disponíveis, consulte Métricas exportadas.
Diagnosticar atrasos de configuração
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 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
Acesse
localhost:15014
egrep
paraconvergence
nas métricas:curl http://localhost:15014/metrics | grep convergence
Interpretar registros de acesso de observabilidade do Google Cloud
As informações a seguir explicam como usar os registros de acesso de observabilidade do Google Cloud para resolver problemas de conexão.
O Anthos Service Mesh exporta dados para os registros de acesso de observabilidade do Google Cloud 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 acesso/tráfego de observabilidade do Google Cloud são ativados por padrão no
perfil asm-gcp
em toda a malha. No entanto, se eles ainda não estiverem
ativados, é possível usar o seguinte comando:
istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \ --set values.telemetry.v2.stackdriver.enabled=true \ --set values.telemetry.v2.stackdriver.logging=true
Há dois tipos de registros de acesso:
Os registros de acesso ao servidor fornecem uma visão das solicitações. Eles estão localizados em
server-accesslog-stackdriver
, anexado ao recurso monitoradok8s_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 monitoradok8s_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
Somente os registros de erros de clientes são ativados por padrão para reduzir os custos de registro, mas é possível ativar todos os registros de clientes (sucessos e erros) usando o seguinte comando:
istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION
--set values.telemetry.v2.stackdriver.enabled=true
--set values.telemetry.v2.stackdriver.outboundAccessLogging=FULL
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 conterão informações de rastreamento, como amostragem, ID de rastreamento e ID do período.
As informações exibidas nos registros de acesso de observabilidade do Google Cloud são originadas dos registros de acesso do Envoy quando você os ativa na configuração do Istio. Elas contêm os seguintes cabeçalhos:
route_name
upstream_cluster
X-Envoy-Original-Path
X-Envoy-Original-Host
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 Anthos 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
e503
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 paraNoRoute
, 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ótuloresponse_flag
para solucionar erros503
.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 chamadahttp2
, o protocolo não fará a negociação automática corretamente.
Para mais informações, consulte sinalizações de resposta.
Interpretar registros do Envoy
Nas etapas a seguir, explicamos como usar os registros de acesso do proxy 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ções de ponta a ponta
Os registros de acesso não são ativados por padrão no Anthos Service Mesh e só podem ser ativados globalmente em toda a malha.
Para solucionar falhas de conexão/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. Por exemplo, para consultar todas as solicitações com
MULTUAL_TLS
ativado e usar o protocolo grpc
, anexe a 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
É possível definir uma política de registros de proxy que determine o tipo de informação que você
coletará. Isso é útil para controlar o escopo dos registros para solucionar
problemas. Por exemplo, a geração de registros captura automaticamente erros, mas é possível definir
logWindowDuration
para capturar eventos de sucesso para um período específico
ou definir a duração da janela como zero para registrar todos os acessos. A política é definida no nível da malha ou
do cluster.
Para ativar uma política de registro de acesso, use o seguinte comando:
istioctl install --set profile=PROFILE_NAME \ --set values.telemetry.v2.stackdriver.enabled=true \ --set values.telemetry.v2.stackdriver.logging=true \ --set values.telemetry.accessLogPolicy.enabled=true
Para mais informações sobre as opções de configuração de registro de acesso, como
logWindowDuration
, consulte
Configuração do AccessLogPolicy.
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 -c istio-proxy -- pilot-agent request GET SCOPE
No exemplo, SCOPE é um dos seguintes:
certs
: certificados dentro da instância do Envoyclusters
: clusters com o Envoy configuradoconfig_dump
: despeja a configuração do Envoylisteners
: listeners com o Envoy configuradologging
: visualizar e alterar as configurações de geração de registrosstats
: estatísticas do Envoystats/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 exec POD_NAME -c istio-proxy -- ss -anopim
Exiba um resumo das estatísticas do soquete:
kubectl exec POD_NAME -c istio-proxy -- 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 -c istio-proxy
É possível fazer o mesmo para o contêiner init
:
kubectl logs POD_NAME -c istio-init