Personalizar logs de acesso do plano de dados - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Pré-requisitos

Etapa 1: Ativar o registro de acesso

Para instâncias do ASM anteriores à versão 1.17.2.35

Acesse o console do ASM. No painel de navegação esquerdo, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação esquerdo, escolha ASM Instance > Base Information.
No canto superior direito da página Basic Information, clique em Settings.

No painel Settings Update, selecione Enable access logging and print it to container stdout e clique em OK.

O container istio-proxy gera logs que contêm os seguintes campos por padrão. Se você desativar o registro de acesso, o container istio-proxy não gerará logs de acesso no formato JSON.

Campos de log padrão


    "authority_for":"%REQ(:AUTHORITY)%",
    "bytes_received":"%BYTES_RECEIVED%",
    "bytes_sent":"%BYTES_SENT%",
    "downstream_local_address":"%DOWNSTREAM_LOCAL_ADDRESS%",
    "downstream_remote_address":"%DOWNSTREAM_REMOTE_ADDRESS%",
    "duration":"%DURATION%",
    "istio_policy_status":"%DYNAMIC_METADATA(istio.mixer:status)%",
    "method":"%REQ(:METHOD)%",
    "path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
    "protocol":"%PROTOCOL%",
    "request_id":"%REQ(X-REQUEST-ID)%",
    "requested_server_name":"%REQUESTED_SERVER_NAME%",
    "response_code":"%RESPONSE_CODE%",
    "response_flags":"%RESPONSE_FLAGS%",
    "route_name":"%ROUTE_NAME%",
    "start_time":"%START_TIME%",
    "trace_id":"%REQ(X-B3-TRACEID)%",
    "upstream_cluster":"%UPSTREAM_CLUSTER%",
    "upstream_host":"%UPSTREAM_HOST%",
    "upstream_local_address":"%UPSTREAM_LOCAL_ADDRESS%",
    "upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
    "upstream_transport_failure_reason":"%UPSTREAM_TRANSPORT_FAILURE_REASON%",
    "user_agent":"%REQ(USER-AGENT)%",
    "x_forwarded_for":"%REQ(X-FORWARDED-FOR)%"

Para instâncias do ASM 1.17.2.35 e posteriores

Acesse o console do ASM. No painel de navegação esquerdo, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação esquerdo, escolha Observability Management Center > Observability Settings.
Na página Observability Settings, clique na guia Global, Namespace ou Custom de acordo com suas necessidades.
- Se você clicar na guia Namespace, clique em Create e selecione um Namespace conforme necessário.
- Se você clicar na guia Custom, clique em Create, selecione um Namespace e insira um Name e um Match Label conforme necessário.
Na seção Log Settings, ative o switch Enable Log Output e clique em Submit.

Após ativar o switch, os sidecars ou gateways no plano de dados do service mesh gerarão logs de acesso na saída padrão. O ASM também oferece suporte a filtragem de logs. Para mais informações, consulte Filtrar logs.

Visualize os logs na saída padrão do container sidecar do plano de dados.

Os exemplos a seguir mostram como visualizar logs de acesso usando kubectl.

Execute o seguinte comando para visualizar os logs do sidecar:

kubectl logs httpbin-5c5944c58c-w**** -c istio-proxy --tail 1

Saída de exemplo

{
    "authority_for":"47.110.XX.XXX",
    "bytes_received":"0",
    "bytes_sent":"22382",
    "downstream_local_address":"192.168.0.29:80",
    "downstream_remote_address":"221.220.XXX.XXX:0",
    "duration":"80",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/static/favicon.ico",
    "protocol":"HTTP/1.1",
    "request_id":"0f2cf829-3da5-4810-a618-08d9745d****",
    "requested_server_name":"outbound_.8000_._.httpbin.default.svc.cluster.local",
    "response_code":"200",
    "response_flags":"-",
    "route_name":"default",
    "start_time":"2023-06-30T04:00:36.841Z",
    "trace_id":"-",
    "upstream_cluster":"inbound|80||",
    "upstream_host":"192.168.0.29:80",
    "upstream_local_address":"127.0.X.X:55879",
    "upstream_response_time":"79",
    "upstream_service_time":"79",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for":"221.220.XXX.XXX"
}

Execute o seguinte comando para visualizar os logs do gateway de entrada:

kubectl -n istio-system logs istio-ingressgateway-6cff9b6b58-r**** --tail 1

Saída de exemplo

{
    "authority_for":"47.110.XX.XXX",
    "bytes_received":"0",
    "bytes_sent":"22382",
    "downstream_local_address":"192.168.0.63:80",
    "downstream_remote_address":"221.220.XXX.XXX:64284",
    "duration":"81",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/static/favicon.ico",
    "protocol":"HTTP/1.1",
    "request_id":"0f2cf829-3da5-4810-a618-08d9745d****",
    "requested_server_name":"-",
    "response_code":"200",
    "response_flags":"-",
    "route_name":"httpbin",
    "start_time":"2023-06-30T04:00:36.841Z",
    "trace_id":"-",
    "upstream_cluster":"outbound|8000||httpbin.default.svc.cluster.local",
    "upstream_host":"192.168.0.29:80",
    "upstream_local_address":"192.168.0.63:36140",
    "upstream_response_time":"81",
    "upstream_service_time":"81",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for":"221.220.XXX.XXX"
}

(Opcional) Visualize os logs de acesso no console do Container Service for Kubernetes.

Se você usa um cluster do Alibaba Cloud Container Service for Kubernetes (ACK), também pode visualizar os logs de acesso no console do ACK.
1. Acesse o console do ACK. No painel de navegação esquerdo, clique em Clusters.
2. Na página Clusters, clique no nome do seu cluster. No painel de navegação esquerdo, clique em Workloads > Pods.
3. Na página Pods, clique no nome do pod de destino e, em seguida, clique na guia Logs na parte inferior da página para visualizar os logs de acesso.

Para mais informações sobre logs, consulte Configurações de observabilidade e Ativar coleta de logs do plano de controle e alertas baseados em logs (Novo).

Etapa 2: Personalizar o conteúdo do log de acesso

Para instâncias do ASM anteriores à versão 1.17.2.35

Acesse o console do ASM. No painel de navegação esquerdo, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação esquerdo, escolha ASM Instance > Base Information.
Na seção Basic Information da página Config Info, clique em Enable access logging and print it to container stdout ao lado de Update Access Log Format.
Na caixa de diálogo Update Access Log Format, adicione um formato personalizado de log de acesso. Defina accessLogFormat key como my_custom_key e accessLogFormat value como %REQ(end-user)% e clique em Submit.

Este exemplo mostra como obter o campo de cabeçalho end-user de uma solicitação HTTP no aplicativo de exemplo Bookinfo. Ao personalizar o formato do log de acesso, você pode selecionar campos opcionais fornecidos pelo ASM ou adicionar campos personalizados. Após selecionar os campos, os logs de acesso serão gerados no formato personalizado. Você não precisa selecionar os quatro campos a seguir: request_duration (%REQUEST_DURATION%), request_tx_duration (%REQUEST_TX_DURATION%), response_duration (%RESPONSE_DURATION%) e response_tx_duration (%RESPONSE_TX_DURATION%).

Para instâncias do ASM 1.17.2.35 e posteriores

Acesse o console do ASM. No painel de navegação esquerdo, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação esquerdo, escolha Observability Management Center > Observability Settings.
Na página Observability Settings, clique na guia Global, Namespace ou Custom de acordo com suas necessidades.
- Se você clicar na guia Namespace, clique em Create e selecione um Namespace conforme necessário.
- Se você clicar na guia Custom, clique em Create, selecione um Namespace e insira um Name e um Match Label conforme necessário.
Na seção Log Settings, selecione campos, modifique as informações dos campos de destino ou clique no ícone ao lado das métricas de log na parte inferior para adicionar um campo de log conforme necessário. Em seguida, clique em Submit.

Você só pode personalizar o formato do log após ativar o switch Enable Log Output. Na seção Log Format, os campos de log selecionados por padrão são obrigatórios e não podem ser modificados. Os campos de log podem recuperar valores dos cabeçalhos de solicitação, cabeçalhos de resposta e valores integrados do Envoy.

O exemplo a seguir mostra como imprimir o cabeçalho accept-encoding em uma solicitação. Defina accessLogFormat key como accept-encoding, Type como Request Properties e accessLogFormat value como Accept-Encoding. Por exemplo, a expressão de formato para o campo de atributo de solicitação authority_for é %REQ(:AUTHORITY)%, a expressão de formato para o campo de atributo de resposta upstream_response_time é %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%, e as propriedades integradas do Envoy incluem campos como request_duration e response_duration.

Execute o seguinte comando para visualizar os logs de um componente do plano de dados do service mesh:

kubectl logs httpbin-5c5944c58c-w**** -c istio-proxy --tail 1|grep accept-encoding --color=auto

Saída de exemplo

{
    "bytes_received":"0",
    "bytes_sent":"9593",
    "downstream_local_address":"192.168.0.29:80",
    "downstream_remote_address":"69.164.XXX.XX:0",
    "duration":"2",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/",
    "protocol":"HTTP/1.1",
    "request_id":"29939dc9-62be-4ddf-acf6-32cb098d****",
    "requested_server_name":"outbound_.8000_._.httpbin.default.svc.cluster.local",
    "response_code":"200",
    "response_flags":"-",
    "route_name":"default",
    "start_time":"2023-06-30T04:18:19.734Z",
    "trace_id":"-",
    "upstream_cluster":"inbound|80||",
    "upstream_host":"192.168.0.29:80",
    "upstream_local_address":"127.0.X.X:34723",
    "upstream_service_time":"2",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 zgrab/0.x",
    "x_forwarded_for":"69.164.XXX.XX",
    "authority_for":"47.110.XX.XXX",
    "upstream_response_time":"2",
    "accept-encoding":"gzip"
}

A saída mostra que o valor do cabeçalho Accept-Encoding adicionado na Etapa 2 está incluído no log de acesso. Para mais informações sobre logs, consulte Configurações de observabilidade e Ativar coleta de logs do plano de controle e alertas baseados em logs (Novo).

Etapa 3: Visualizar logs de acesso

Após ativar o registro de acesso, o container sidecar solicitante gera logs de acesso no formato personalizado especificado.

Na barra de endereço do navegador, insira <Ingress gateway address>/productpage para acessar o aplicativo productpage.
Acesse o console do ACK. No painel de navegação esquerdo, clique em Clusters.
Na página Clusters, clique no nome do seu cluster. No painel de navegação esquerdo, clique em Workloads > Deployments.
Na parte superior da página Deployments, defina Namespace como default. Em seguida, localize o aplicativo productpage-v1 e clique em Details na coluna Actions.

Na página de detalhes do aplicativo, clique na guia Logs e defina Container como istio-proxy.

O painel de saída de log exibe a seguinte entrada. A presença do campo my_custom_key com o valor jason indica que você configurou o conteúdo do log personalizado com êxito.

{"method":"GET","x_forwarded_for":null,"upstream_host":"172.19.16.90:9080","protocol":"HTTP/1.1","my_custom_key":"jason","authority_for":"addedvalues:9080","response_code":200,"start_time":"2021-10-21T11:40:12.0552","request_id":"5222b7fb-05a6-4fae-8e13-xxx","bytes_sent":883,"downstream_remote_address":"172.19.16.11:33752","upstream_transport_failure_reason":null,"downstream_local_address":"192.168.237.140:9080","requested_server_name":null,"response_flags":"-","duration":4,"user_agent":"python-requests/2.18.4","route_name":"default","trace_id":null,"istio_policy_status":null,"path":"/addedvalues/0","upstream_cluster":"outbound|9080||addedvalues.default.svc.cluster.local","bytes_received":0,"upstream_service_time":"3","authority":"addedvalues:9080","upstream_local_address":"172.19.16.11:52430"}

Campos do log de acesso

No Service Mesh ASM, "upstream" refere-se ao receptor de uma solicitação em uma cadeia de chamadas e "downstream" refere-se ao iniciador da solicitação. Por exemplo, quando o Serviço A envia uma solicitação ao Serviço B, o Serviço A é o "downstream" e o Serviço B é o "upstream".

Parâmetro	Valor	Descrição
authority_for	%REQ(:AUTHORITY)%	O hostname de destino na solicitação. Para uma solicitação HTTP/1.1, corresponde ao valor do cabeçalho de solicitação `Host`. Para uma solicitação HTTP/2, corresponde ao valor do cabeçalho de solicitação `:authority`.
bytes_received	%BYTES_RECEIVED%	HTTP: O número de bytes no corpo da solicitação. TCP: O número de bytes recebidos da conexão downstream.
bytes_sent	%BYTES_SENT%	HTTP: O número de bytes enviados no corpo da resposta. Para uma conexão WebSocket, esse valor inclui o tamanho do cabeçalho de resposta. TCP: O número de bytes enviados para a conexão downstream.
downstream_local_address	%DOWNSTREAM_LOCAL_ADDRESS%	O endereço e a porta de destino da conexão downstream. Pode ser considerado o endereço de destino original da conexão downstream.
downstream_remote_address	%DOWNSTREAM_REMOTE_ADDRESS%	O endereço e a porta do cliente da conexão downstream.
method	%REQ(:METHOD)%	O método da solicitação. Este campo é válido apenas para solicitações HTTP.
path	%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%	O caminho da solicitação.
protocol	%PROTOCOL%	O protocolo da solicitação.
request_id	%REQ(X-REQUEST-ID)%	O ID único da solicitação.
requested_server_name	%REQUESTED_SERVER_NAME%	O nome do servidor especificado na conexão SSL (Server Name Indication).
response_code	%RESPONSE_CODE%	O código de status de resposta HTTP.
response_flags	%RESPONSE_FLAGS%	Informações adicionais sobre a resposta ou conexão. Para mais informações sobre os valores e seus significados, consulte Referência de response_flag.
route_name	%ROUTE_NAME%	O nome da rota correspondente. É consistente com o nome de rota definido no virtual service. Um valor vazio (-) indica que nenhuma rota foi correspondida.
start_time	%START_TIME%	O momento em que o processamento da solicitação foi iniciado, com precisão de milissegundos.
trace_id	%TRACE_ID%	O ID de rastreamento para rastreabilidade.
upstream_cluster	%UPSTREAM_CLUSTER%	O serviço de destino upstream e o subconjunto.
upstream_host	%UPSTREAM_HOST%	O host de destino upstream, geralmente o endereço IP e a porta do Pod.
upstream_local_address	%UPSTREAM_LOCAL_ADDRESS%	O endereço local usado para estabelecer uma conexão com o serviço upstream.
duration	%DURATION%	Para uma solicitação HTTP, este campo indica o tempo total decorrido desde o início da leitura da solicitação até o último byte da resposta ser enviado ao serviço downstream. É o tempo total que um sidecar ou gateway leva para processar uma solicitação. Para uma solicitação TCP, este campo indica a duração total da conexão downstream.
request_duration	%REQUEST_DURATION%	Para uma solicitação HTTP, este campo indica o tempo necessário para ler a solicitação completa (cabeçalhos e corpo) do serviço downstream. Se esta duração for longa, investigue: Se a qualidade da rede é boa e a largura de banda é suficiente. Se o aplicativo upstream ou downstream apresenta um gargalo sob uma carga de E/S semelhante. Para uma solicitação TCP, este campo não está implementado e é exibido como - no log.
request_tx_duration	%REQUEST_TX_DURATION%	Para uma solicitação HTTP, este campo indica o tempo decorrido desde o início da solicitação até que seu último byte seja enviado ao serviço upstream. Se esta duração for longa, investigue: Se a qualidade da rede é boa e a largura de banda é suficiente. Se o aplicativo upstream ou downstream apresenta um gargalo sob uma carga de E/S semelhante. Para uma solicitação TCP, este campo não está implementado e é exibido como - no log.
response_duration	%RESPONSE_DURATION%	Para uma solicitação HTTP, este campo indica o tempo decorrido desde o início da solicitação até que o primeiro byte da resposta seja lido do serviço upstream. Se esta duração for longa e request_tx_duration for curto, investigue se o aplicativo upstream apresenta um gargalo de desempenho. Para uma solicitação TCP, este campo não está implementado e é exibido como - no log.
response_tx_duration	%RESPONSE_TX_DURATION%	Para uma solicitação HTTP, este campo indica o tempo decorrido desde a leitura do primeiro byte da resposta do serviço upstream até o envio do último byte ao serviço downstream. Se esta duração for longa, investigue: Se a qualidade da rede é boa e a largura de banda é suficiente. Se o aplicativo upstream ou downstream apresenta um gargalo sob uma carga de E/S semelhante. Para uma solicitação TCP, este campo não está implementado e é exibido como - no log.
upstream_service_time (sidecar)	%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%	Nos logs de acesso de um sidecar ou gateway, este campo indica o tempo de processamento do serviço upstream e o tempo necessário para a comunicação de rede com o serviço upstream. Se esta duração for longa, investigue se: O desempenho de processamento do aplicativo upstream atende às expectativas. A latência e a largura de banda da rede para comunicação com o serviço upstream atendem às expectativas.
upstream_response_time (gateway)	%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%

Nota

Para solicitações HTTP com corpo (Content-Length > 0), o Envoy transmite a solicitação ao serviço upstream à medida que a recebe, sem aguardar a chegada completa da solicitação antes de encaminhá-la. Portanto, um cliente downstream lento pode aumentar o tempo total de solicitação para todos os serviços na cadeia de chamadas upstream.

Valores do sinalizador de resposta

O campo response_flag no log de acesso fornece informações adicionais sobre a solicitação ou conexão. A tabela a seguir descreve os diferentes valores de response_flag.

Valor	Descrição
UH	O Envoy não encontrou um host upstream íntegro. Normalmente, isso ocorre porque não existe nenhum endpoint disponível para o serviço de destino.
UF	Falha ao conectar ao host upstream. Normalmente, isso ocorre porque o aplicativo upstream não está em execução ou a porta está configurada incorretamente.
UO	Overflow do upstream (circuit breaking).
NR	O Envoy não encontrou uma rota para a solicitação.
NC	O Envoy não encontrou o serviço de destino. Normalmente, isso significa que o hostname ou o nome do subconjunto na regra de roteamento configurada está incorreto.
URX	A solicitação foi limitada por taxa.
DC	O cliente downstream foi desconectado.
UR	O serviço upstream reiniciou a conexão.
UAEX	Um serviço de autorização externo rejeitou a solicitação. O proxy do ASM recusou a solicitação com base na resposta do serviço de autorização externo.
DPE	Erro de protocolo downstream. Indica que a solicitação enviada pelo aplicativo downstream usa um protocolo inesperado. Verifique se os nomes das portas dos serviços no cluster têm o prefixo de protocolo correto, como `http-80`, `http` ou `grpc`.
UPE	Erro de protocolo upstream. Indica que o proxy do ASM tentou encaminhar uma solicitação ao serviço upstream usando um protocolo inesperado. Verifique se os nomes das portas dos serviços no cluster têm o prefixo de protocolo correto, como `http-80`, `http` ou `grpc`.

Operações relacionadas

Você também pode usar o Log Service (SLS) para coletar logs de acesso do plano de dados. Para mais informações, consulte Gerar e coletar logs de acesso do gateway ASM.