Introdução
À medida que arquiteturas baseadas em microsserviços ganham complexidade, a observabilidade torna-se o pilar central para a estabilidade operacional. No Azure Kubernetes Service (AKS), a combinação do Istio para service mesh e do Azure Application Insights para telemetria de aplicação é poderosa, mas frequentemente desconexa.
Sem uma configuração deliberada, cada ferramenta opera em camadas distintas, dificultando a correlação de um fluxo de requisição. Este artigo apresenta uma solução prática e pronta para produção para habilitar logs de acesso do Istio (Envoy) no AKS e correlacioná-los diretamente com a telemetria do Application Insights, permitindo um rastreamento completo para acelerar o diagnóstico e a visibilidade.
Contexto de Observabilidade da Plataforma
O ambiente considerado aqui consiste em:
- AKS com Istio gerenciado habilitado.
- Sidecars do Envoy injetados nos pods de aplicação.
- SDK do Application Insights em execução nas cargas de trabalho.
- Log Analytics como o repositório centralizado de logs.
O objetivo é alinhar essas camadas utilizando um contexto de rastreamento (trace context) comum, sem a necessidade de sistemas de tracing adicionais ou agentes customizados que aumentem a carga operacional.
Habilitando o Logging de Acesso do Istio na Malha
O primeiro passo é garantir a emissão consistente de logs de acesso do Envoy em toda a malha. O Istio oferece a API Telemetry, permitindo a ativação centralizada sem a necessidade de modificar workloads individuais.
Aplique o recurso Telemetry no namespace do sistema do Istio:
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
name: mesh-access-logs
namespace: aks-istio-system
spec:
accessLogging:
- providers:
- name: envoy
Esta configuração garante que todos os sidecars do Envoy emitam logs de forma uniforme e compatível com o Istio gerenciado do AKS.
Padronizando Logs com EnvoyFilter
Para que os logs sejam operacionais em escala, precisamos de uma estrutura JSON consistente. No AKS, utilizamos EnvoyFilter para customizar a formatação, garantindo que o log inclua headers de correlação e trace.
Configurando o Logging Inbound e Outbound
A aplicação de EnvoyFilter deve ser feita para tráfego inbound e outbound para observarmos tanto a entrada de solicitações quanto as chamadas downstream efetuadas pelos microsserviços:
(Nota: O trecho de código original de EnvoyFilter deve ser aplicado separadamente para cada contexto conforme as especificações de SIDECAR_INBOUND e SIDECAR_OUTBOUND presentes no original.)
Automação via PowerShell
Para padronizar esse deployment entre múltiplos clusters e ambientes, utilize um script PowerShell que valide o namespace aks-istio-system e aplique os recursos Telemetry e EnvoyFilter via kubectl.
Ingestão no Azure Monitor
Como os logs do Envoy estão direcionados para stdout, o AKS os coleta nativamente. Eles serão ingeridos no Log Analytics e estarão disponíveis na tabela ContainerLogV2. Isso elimina a necessidade de sidecars adicionais ou pipelines customizados de log.
Alinhando Telemetria com o Application Insights
O Application Insights utiliza o padrão W3C Trace Context, onde o operation_Id é o identificador chave. Como conseguimos capturar o cabeçalho traceparent via logs do Envoy, ambos os sistemas passam a compartilhar o mesmo ID de rastreamento.
Correlacionando Requisições com KQL
Com ambos os sistemas emitindo o traceparent, você pode realizar joins no Log Analytics para traçar a jornada de uma requisição:
let operationId = "<OperationID>"; // Substitua pelo seu operation_Id
ContainerLogV2
| where TimeGenerated >= ago(24h)
| where ContainerName == "istio-proxy"
| where LogSource == "stdout"
| extend AccessLog = parse_json(LogMessage)
| extend ExtractedOperationId = extract(@"00-([a-f0-9]{32})-", 1, tostring(AccessLog.traceparent))
| where ExtractedOperationId == operationId
| project TimeGenerated, PodName, Method = tostring(AccessLog.method), Path = tostring(AccessLog.path), TraceParent = tostring(AccessLog.traceparent)
| order by TimeGenerated asc
Considerações Finais
A observabilidade de ponta a ponta no AKS é uma questão de alinhar padrões de telemetria entre a rede e a aplicação. Ao estruturar os logs do Istio, times de engenharia no Brasil ganham uma ferramenta potente para reduzir o MTTR (Mean Time To Resolution) sem adicionar complexidade técnica excessiva à plataforma.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
