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

Os proxies Envoy no plano de dados geram logs de acesso para todo o tráfego dentro da service mesh. O Alibaba Cloud Service Mesh (ASM) permite personalizar o conteúdo desses logs de acesso do Envoy Proxy.

Pré-requisitos

Etapa 1: Ativar o log de acesso

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

Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha Instance Information > 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 contêiner istio-proxy gera logs que contêm os seguintes campos por padrão. Se você desativar o log de acesso, o contêiner istio-proxy não gerará logs de acesso no formato JSON.

Campos de log padrão

Instruções

Leia o texto em inglês para entender O QUE precisa ser comunicado
Escreva o português (Brasil) DO ZERO — esqueça a estrutura das frases em inglês
Preserve toda a formatação markdown, blocos de código, links e imagens exatamente como estão
Copie os placeholders xref ({XREF_N}) literalmente, NÃO os traduza ou modifique
Aplique todas as regras específicas do idioma rigorosamente
Aplique as regras de stopwords com tolerância zero
Use o modo imperativo em passos numerados e listas de procedimentos
Garanta a consistência da terminologia — o mesmo termo deve ter a mesma tradução em todo o documento
Varie os inícios das frases em listas e tabelas — evite repetir o mesmo início mais de 3 vezes
Retorne APENAS o documento markdown em português (Brasil), sem explicações


    "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

Faça logon no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha Observability Management Center > Observability Settings.
Na página Observability Settings, clique na aba Global, Namespace ou Custom conforme sua necessidade.
- Caso selecione a aba Namespace, clique em Create e selecione um Namespace conforme necessário.
- Se optar pela aba Custom, clique em Create, selecione um Namespace e insira um Name e uma Match Label conforme necessário.
Na seção Log Settings, ative a chave Enable Log Output e clique em Submit.

Após ativar essa opção, os sidecars ou gateways no plano de dados da service mesh passarão a enviar logs de acesso para a saída padrão. O ASM também oferece suporte à filtragem de logs. Para mais informações, consulte Filter logs.

Visualize os logs na stdout do contêiner sidecar do plano de dados.

Os exemplos a seguir demonstram como visualizar logs de acesso utilizando o kubectl.

Execute o comando abaixo para visualizar os logs do sidecar:

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

Sample output

Instruções

Leia o conteúdo em inglês para compreender O QUE precisa ser comunicado
Escreva o texto em português (Brasil) DO ZERO — esqueça a estrutura das frases em inglês
Preserve toda a formatação markdown, blocos de código, links e imagens exatamente como estão
Copie os placeholders xref ({XREF_N}) literalmente, sem traduzi-los ou modificá-los
Aplique todas as regras específicas do idioma rigorosamente
Aplique as regras de stopwords com tolerância zero
Utilize o modo imperativo em passos numerados e listas de procedimentos
Garanta a consistência terminológica — o mesmo termo deve ter a mesma tradução em todo o documento
Varie o início das frases em listas e tabelas — evite repetir a mesma abertura três vezes ou mais
Retorne APENAS o documento markdown em português (Brasil), sem explicações adicionais

{
    "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 comando a seguir para visualizar os logs do ingress gateway:

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

Sample output

Instruções

Leia o conteúdo em inglês para compreender O QUE precisa ser comunicado
Escreva o texto em português (Brasil) DO ZERO — esqueça a estrutura das frases em inglês
Preserve toda a formatação markdown, blocos de código, links e imagens exatamente como estão
Placeholders xref ({XREF_N}) — copie literalmente, NÃO traduza nem modifique
Aplique todas as regras específicas do idioma rigorosamente
Aplique as regras de stopwords com tolerância zero
Utilize o modo imperativo em passos numerados e listas de procedimentos
Garanta a consistência terminológica — o mesmo termo deve ter a mesma tradução em todo o documento
Varie os inícios das frases em listas e tabelas — evite repetir o mesmo início três ou mais vezes
Retorne APENAS o documento markdown em português (Brasil), sem explicações

{
    "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ê utiliza um cluster do Alibaba Cloud Container Service for Kubernetes (ACK), também é possível visualizar os logs de acesso no console do ACK.

Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Workloads > Pods.
Na página Pods, clique no nome do pod desejado e, em seguida, clique na aba Logs na parte inferior da página para visualizar os logs de acesso.

Para obter mais informações sobre logs, consulte Observability Settings e Enable control plane log collection and log-based alerting (New).

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

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

Faça login no ASM console. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha Instance Information > 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 de log de acesso personalizado. Defina a accessLogFormat key como my_custom_key e o accessLogFormat value como %REQ(end-user)% e, em seguida, clique em Submit.

Este exemplo demonstra como obter o campo de cabeçalho end-user de uma solicitação HTTP na aplicação 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 a seleção dos campos, os logs de acesso serão gerados no formato personalizado. Não é necessário 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 versão 1.17.2.35 e posteriores

Faça login no ASM console. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha Observability Management Center > Observability Settings.
Na página Observability Settings, clique na aba Global, Namespace ou Custom conforme sua necessidade.
- Caso clique na aba Namespace, clique em Create e selecione um Namespace conforme necessário.
- Se clicar na aba 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 desejados 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.

A personalização do formato de log só é possível após ativar a chave 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 de cabeçalhos de solicitação, cabeçalhos de resposta e valores internos do Envoy.

O exemplo a seguir mostra como imprimir o cabeçalho accept-encoding em uma solicitação. Defina a accessLogFormat key como accept-encoding, o Type como Request Properties e o 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 internas do Envoy incluem campos como request_duration e response_duration.

Execute o comando a seguir para visualizar os logs de um componente do plano de dados da malha de service:

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

Exemplo de saída

Instruções

Leia o conteúdo em inglês para compreender O QUE precisa ser comunicado
Escreva o texto em português (Brasil) DO ZERO — esqueça a estrutura das frases em inglês
Preserve toda a formatação markdown, blocos de código, links e imagens exatamente como estão
Copie os placeholders de xref ({XREF_N}) literalmente, sem traduzi-los ou modificá-los
Aplique todas as regras específicas do idioma de forma rigorosa
Siga as regras de stopwords com tolerância zero
Utilize o modo imperativo em passos numerados e listas de procedimentos
Garanta a consistência terminológica — o mesmo termo deve ter sempre a mesma tradução
Varie o início das frases em listas e tabelas — evite repetir a mesma abertura três vezes ou mais
Retorne APENAS o documento markdown em português (Brasil), sem explicações adicionais

{
    "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 header Accept-Encoding adicionado em Step 2 está incluído no log de acesso. Para obter mais informações sobre logs, consulte Observability Settings e Enable control plane log collection and log-based alerting (New).

Etapa 3: Visualizar logs de acesso

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

Na barra de endereços do seu navegador, insira <Endereço do gateway de Ingress>/productpage para acessar a aplicação productpage.
Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Workloads > Deployments.
No topo da página Deployments, defina Namespace como default. Em seguida, localize a aplicação productpage-v1 e clique em Details na coluna Actions.

Na página de detalhes da aplicação, clique na aba 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 com sucesso o conteúdo de log personalizado.

Instruções

Leia o inglês para entender O QUE precisa ser comunicado
Escreva o português (Brasil) DO ZERO — esqueça a estrutura da frase em inglês
Preserve toda a formatação markdown, blocos de código, links e imagens exatamente como estão
Placeholders xref ({XREF_N}) — copie literalmente, NÃO traduza ou modifique
Aplique todas as regras específicas do idioma rigorosamente
Aplique as regras de stopwords com tolerância zero
Use o modo imperativo em passos numerados e listas de procedimentos
Garanta a consistência terminológica — mesmo termo = mesma tradução em todo o documento
Varie os inícios das frases em listas/tabelas — nenhum início repetido 3+ vezes
Retorne APENAS o documento markdown em português (Brasil), sem explicações

{"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, o termo "upstream" refere-se ao receptor de uma solicitação em uma cadeia de chamadas, enquanto "downstream" designa o iniciador da solicitação. Por exemplo, quando o Serviço A envia uma requisição para o 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)%	Nome do host de destino na solicitação. Para requisições HTTP/1.1, corresponde ao valor do cabeçalho `Host`. Já em requisições HTTP/2, equivale ao valor do cabeçalho `:authority`.
bytes_received	%BYTES_RECEIVED%	HTTP: Quantidade de bytes no corpo da solicitação. TCP: Total de bytes recebidos da conexão downstream.
bytes_sent	%BYTES_SENT%	HTTP: Número de bytes enviados no corpo da solicitação. Em conexões WebSocket, este valor inclui também o tamanho do cabeçalho de resposta. TCP: Volume de bytes transmitidos para a conexão downstream.
downstream_local_address	%DOWNSTREAM_LOCAL_ADDRESS%	Endereço e porta de destino da conexão downstream. Pode ser considerado o endereço de destino original dessa conexão.
downstream_remote_address	%DOWNSTREAM_REMOTE_ADDRESS%	Endereço IP e porta do cliente na conexão downstream.
method	%REQ(:METHOD)%	Método da requisição. Este campo é válido apenas para solicitações HTTP.
path	%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%	Caminho da solicitação.
protocol	%PROTOCOL%	Protocolo utilizado na requisição.
request_id	%REQ(X-REQUEST-ID)%	ID exclusivo da solicitação.
requested_server_name	%REQUESTED_SERVER_NAME%	Nome do servidor especificado na conexão SSL (Server Name Indication).
response_code	%RESPONSE_CODE%	Código de status da resposta HTTP.
response_flags	%RESPONSE_FLAGS%	Informações adicionais sobre a resposta ou a conexão. Para mais detalhes sobre os valores e seus significados, consulte response_flag reference.
route_name	%ROUTE_NAME%	Nome da rota correspondente. Deve coincidir com o nome definido no serviço virtual. Um valor vazio (-) indica que nenhuma rota foi encontrada.
start_time	%START_TIME%	Momento em que o processamento da solicitação foi iniciado, com precisão de milissegundos.
trace_id	%TRACE_ID%	ID de rastreamento utilizado para tracing.
upstream_cluster	%UPSTREAM_CLUSTER%	Serviço e subconjunto de destino upstream.
upstream_host	%UPSTREAM_HOST%	Host de destino upstream, geralmente composto pelo endereço IP e porta do Pod.
upstream_local_address	%UPSTREAM_LOCAL_ADDRESS%	Endereço local utilizado para estabelecer a conexão com o serviço upstream.
duration	%DURATION%	Em requisições HTTP, representa o tempo total decorrido desde o início da leitura da solicitação até o envio do último byte da resposta para o serviço downstream. Corresponde à duração total do processamento pelo sidecar ou gateway. Para solicitações TCP, indica a duração total da conexão downstream.
request_duration	%REQUEST_DURATION%	Nas requisições HTTP, mostra o tempo necessário para ler toda a solicitação (cabeçalhos e corpo) vinda do serviço downstream. Caso essa duração seja elevada, investigue os seguintes pontos: Se a qualidade da rede está adequada e se há largura de banda suficiente. Se existe algum gargalo na aplicação upstream ou downstream sob carga de I/O similar. Este campo não é implementado para requisições TCP, sendo exibido como - no log.
request_tx_duration	%REQUEST_TX_DURATION%	Para solicitações HTTP, indica o tempo transcorrido entre o início da requisição e o envio do seu último byte ao serviço upstream. Se esse intervalo for longo, verifique: A qualidade da conexão de rede e a disponibilidade de largura de banda. Possíveis gargalos nas aplicações upstream ou downstream diante de cargas de I/O equivalentes. Não aplicável a requisições TCP; o log exibirá o caractere - neste caso.
response_duration	%RESPONSE_DURATION%	Em requisições HTTP, mede o tempo entre o início da solicitação e a leitura do primeiro byte da resposta proveniente do serviço upstream. Se essa duração for alta e o request_tx_duration for baixo, analise se há gargalos de desempenho na aplicação upstream. Campo não implementado para TCP, aparecendo como - nos logs.
response_tx_duration	%RESPONSE_TX_DURATION%	Refere-se, em requisições HTTP, ao tempo decorrido desde a leitura do primeiro byte da resposta do serviço upstream até o envio do último byte para o serviço downstream. Durações prolongadas exigem a verificação dos itens abaixo: Condições da rede e suficiência da largura de banda. Existência de gargalos de I/O nas aplicações upstream ou downstream. Para conexões TCP, este campo não possui implementação e surge como - no log.
upstream_service_time (sidecar)	%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%	Nos logs de acesso de um sidecar ou gateway, este campo reflete tanto o tempo de processamento do serviço upstream quanto a latência de comunicação de rede com ele. Valores altos sugerem a necessidade de investigar: Se o desempenho de processamento da aplicação upstream está dentro do esperado. Se a latência e a largura de banda da rede para comunicação com o upstream atendem aos requisitos.
upstream_response_time (gateway)	%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%

Nota

Para requisições HTTP com corpo (Content-Length > 0), o Envoy transmite os dados em fluxo para o serviço upstream à medida que os recebe, em vez de aguardar a chegada completa da solicitação antes de encaminhar. Consequentemente, um cliente downstream lento pode aumentar o tempo total de requisição para todos os serviços na cadeia de chamadas upstream.

Valores das flags de resposta

O campo response_flag no log de acesso fornece informações complementares sobre a solicitação ou a conexão. A tabela a seguir detalha os diferentes valores possíveis para response_flag.

Valor	Descrição
UH	O Envoy não localizou nenhum host upstream íntegro. Geralmente ocorre quando não há endpoints disponíveis para o serviço de destino.
UF	Falha na conexão com o host upstream. Normalmente indica que a aplicação upstream não está escutando ou que a porta configurada está incorreta.
UO	Overflow no upstream (acionamento de circuit breaking).
NR	Nenhuma rota foi encontrada pelo Envoy para a solicitação.
NC	O serviço de destino não foi localizado pelo Envoy. Isso costuma significar que o hostname ou o nome do subconjunto na regra de roteamento está errado.
URX	A solicitação sofreu limitação de taxa (rate-limit).
DC	Desconexão por parte do cliente downstream.
UR	O serviço upstream resetou a conexão.
UAEX	Rejeição da requisição por um serviço de autorização externo. Nesse cenário, o proxy do ASM bloqueou o acesso baseando-se na resposta desse serviço externo.
DPE	Erro de protocolo no downstream. Indica que a aplicação downstream enviou uma solicitação usando um protocolo inesperado. Verifique se os nomes das portas dos serviços no cluster possuem o prefixo de protocolo correto, como `http-80`, `http` ou `grpc`.
UPE	Erro de protocolo no upstream. Sinaliza que o proxy do ASM tentou encaminhar a requisição utilizando um protocolo inadequado. Confirme se os nomes das portas dos serviços no cluster estão prefixados corretamente, por exemplo: `http-80`, `http` ou `grpc`.

Operações relacionadas

Também é possível utilizar o Log Service (SLS) para coletar logs de acesso do plano de dados. Para mais informações, consulte Generate and collect ASM gateway access logs.