Introducing dependency telemetry in Application Insights for Azure API Management policies
Running A(P)I platforms at-scale is not a walk in the park – As traffic flows through the system, it needs handle the load and provide insights on where the inefficiencies are. Finding the needle in a haystack Azure API Management provides a broad set of observability capabilities across its managed and self-hosted gateway offerings, although availability varies by gateway type: Azure Application Insights integration leveraging requests, traces from policies, custom metrics from policies & dependency tracking to integrate with your apps APM Request tracing with API Inspector Built-in analytics for (business) reporting (docs) Azure Monitor logs & metrics for our managed gateway or OpenTelemetry metrics for our self-hosted gateway Logging to Azure Event Hubs in your desired format through policies These capabilities are valuable, but the teams operating API platforms do not always define the APIs or author their policies. As a result, operators may lack visibility into the downstream work performed during each request: A single inbound request does not always map to a single backend request; policies can cause it to fan out into multiple downstream calls. Rate limiting happens, so calls downstream can retry and infuse latency All of these can infuse latency to the end-to-end experience for their customers and can only be diagnosed with detailed insights – They are looking for the needle in a haystack. In recent months, support cases have shown that customers can struggle to identify the source of latency when relying on Application Insights telemetry alone. Here are some examples showing high incoming latency but it’s difficult to understand the cause. Example #1: Example #2: Example #3: Introducing external dependency calls in Application Insights for policies We want to empower our customers by shifting our internal insights left to help customers be more efficient/self-diagnose API platforms at scale. I’m excited to share the first release of external dependency telemetry in Application Insights for Azure API Management policies. It covers the following policies: authentication-managed-identity authentication-token azure-openai-semantic-cache-lookup cosmosdb-request-handler forward-request get-authorization-context http-data-source invoke-dapr-binding llm-content-safety llm-semantic-cache-lookup send-request send-one-way-request send-service-bus-message sql-data-source validate-jwt This telemetry helps customers see where request time is spent and can reduce the need to open a support ticket. The examples below show how it explains the scenarios introduced earlier: Example #1 was retrying calls to the backend with a wait in between: Example #2 performed JWT validation, which required retrieving OpenID Connect metadata. It then made an initial slow backend call before the backend call visible to the customer. Example #3 combined three downstream operations in one request: validating a JWT, sending a message to Azure Service Bus, and then forwarding the request to the backend. What’s next? Improving your application landscape telemetry in Application Insights is just the beginning! We’re continuing to expand the diagnostic information available to customers in two areas: Enhance Azure Monitor diagnostic logs with additional per-request details and outbound dependency information. Add dependency telemetry for more policies and scenarios. Together, these improvements will give platform builders deeper insight into their A(P)I platforms and make that information easier to integrate with existing monitoring solutions. We’re excited to deliver this richer Application Insights telemetry, get started by reading our Azure Application Insights integration guidance. Let us know in the comments how you use it and which scenarios you would like us to cover next. Thanks for reading, Tom
Evoluindo a Resposta a Incidentes em AKS com Azure SRE Agent - Parte 1
Resumo executivo Em aplicações executadas no Azure Kubernetes Services (AKS), eventos OOMKilled estão entre as causas recorrentes de reinicialização de contêineres e indisponibilidade intermitente em aplicações web. A observabilidade fornecida por Azure Monitor, Container Insights, Log Analytics e métricas Prometheus permite detectar o sintoma, registrar o evento e disparar o alerta. A detecção isolada, porém, ainda deixa para a equipe de plantão o trabalho mais caro: correlacionar métricas, logs, eventos, alterações recentes e limites de recursos até chegar a uma hipótese defensável. Sobre essa base de observabilidade, o Azure SRE Agent adiciona uma camada de raciocínio e execução governada. Ao receber o incidente, ele coleta evidências nas fontes conectadas, valida hipóteses e produz um diagnóstico explicável. Em seguida, recomenda a ação de menor risco e, conforme o modo de execução configurado, solicita aprovação humana ou executa uma remediação pré-autorizada. O resultado é um fluxo mais rápido e rastreável, sem eliminar os controles de acesso e aprovação. Este whitepaper documenta o padrão em um laboratório reproduzível. No cenário, um pod em CrashLoopBackOff por limite de memória subdimensionado (20 Mi de limite, 10 Mi de solicitação) é investigado, diagnosticado e corrigido pelo agente sob aprovação humana, com verificação posterior e disparo automatizado por alerta do Azure Monitor. Além do passo a passo, o documento aprofunda a mecânica que sustenta o diagnóstico, cgroups v2, o OOM killer do kernel, classes de QoS, working set versus RSS e o comportamento de heap dos runtimes, porque a qualidade da resposta assistida depende diretamente da qualidade dos sinais que a alimentam. O que este documento entrega A anatomia técnica de um evento OOMKilled em AKS, do cgroup ao status do pod. Consultas KQL e PromQL prontas para detecção e para o desenho da regra de alerta. O modelo operacional do Azure SRE Agent: fontes de contexto, modos de execução, permissões, hooks e políticas de acesso a ferramentas. Um laboratório completo, do provisionamento do agente à recuperação verificada do workload. Um enquadramento de governança, auditoria e segurança para operações agênticas. O que este documento não cobre Disparo totalmente automatizado a partir do alerta e integração com o processo de gestão de incidentes, tema da Parte 2. Ajuste fino de capacidade em escala de frota (VPA/HPA em produção), tratado apenas como método. Valores de preço vigentes; o modelo de cobrança é descrito de forma qualitativa. 1. Introdução Aplicações nativas de nuvem distribuem o processamento entre pods, serviços, dependências e nós. Essa elasticidade melhora a escala, mas amplia a complexidade da investigação quando uma falha ocorre. Em um incidente de memória, o primeiro sinal pode ser um pod reiniciado, uma elevação de erros HTTP, aumento de latência ou degradação parcial de uma jornada específica. O problema raramente é a ausência de dados. É o custo cognitivo de atravessar métricas, logs, eventos do Kubernetes, histórico de implantação e manifestos sob pressão de tempo, para só então formular uma hipótese. Esse custo é pago integralmente a cada incidente, e não se acumula como conhecimento reutilizável. Este whitepaper apresenta um padrão de resposta a incidentes em que o Azure Monitor sustenta a detecção e a telemetria, enquanto o Azure SRE Agent converte sinais em contexto operacional acionável, preservando a decisão humana onde ela é necessária. 2. Contexto e desafio operacional O cenário considera uma aplicação web em AKS instrumentada com Container Insights, Log Analytics, métricas Prometheus e alertas do Azure Monitor. O desafio não é apenas saber que um contêiner foi encerrado, é determinar por que a memória ultrapassou o limite, qual versão e qual carga estavam envolvidas, qual foi o impacto ao usuário e qual ação reduz risco sem ocultar a causa raiz. Ou seja, transformar sinais distribuídos em uma decisão defensável sobre pressão de tempo. Telemetria distribuída entre métricas, logs, eventos e histórico de implantação. Pressão de tempo para restaurar o serviço antes da violação do SLO. Risco de reinicializações repetitivas que mascaram a ausência de correção estrutural. Necessidade de aprovação, rastreabilidade e segregação de funções em ambientes regulados. Há ainda um viés operacional relevante: sob pressão, o caminho mais curto, reiniciar o pod ou ampliar o limite de memória, quase sempre funciona no curto prazo. Isso torna difícil distinguir, retrospectivamente, um limite subdimensionado de um vazamento de memória lento, porque a evidência que separaria os dois é descartada junto com o contêiner encerrado. 3. Anatomia técnica do evento OOMKilled Antes de delegar a investigação a um agente, é necessário estabelecer com precisão o que o sinal significa. Boa parte dos diagnósticos incorretos de memória em Kubernetes nasce da confusão entre três mecanismos distintos: o OOM killer do kernel atuando no cgroup do contêiner, o despejo (eviction) decidido pelo kubelet por pressão no nó, e o encerramento por falha da aplicação. 3.1 O caminho do kernel: cgroups v2, memory.max e o OOM killer Quando um contêiner declara resources.limits.memory, o kubelet traduz esse valor para o controlador de memória do cgroup correspondente. Em nós AKS com imagens baseadas em Ubuntu 22.04 ou superior e Azure Linux 3.0, padrão em versões recentes do Kubernetes, o runtime opera sobre cgroup v2, e o limite é materializado no arquivo memory.max do cgroup do contêiner. A partir daí, o comportamento é do kernel Linux, não do Kubernetes. Quando as páginas anônimas do cgroup não podem mais ser recuperadas e a alocação ultrapassaria memory.max, o kernel invoca o OOM killer restrito àquele cgroup, escolhe um processo e envia SIGKILL. O contador correspondente é incrementado em memory.events, no campo oom_kill. # Dentro do nó, inspecionando o cgroup do contêiner (cgroup v2) cat /sys/fs/cgroup/.../memory.max # limite efetivo (bytes) cat /sys/fs/cgroup/.../memory.high # ponto de throttling por reclaim cat /sys/fs/cgroup/.../memory.current # uso corrente cat /sys/fs/cgroup/.../memory.events # low / high / max / oom / oom_kill Vale distinguir dois campos frequentemente confundidos em memory.events: max conta quantas vezes a alocação esbarrou no teto e forçou reclaim, enquanto oom_kill conta quantos processos foram efetivamente encerrados. Um valor alto em max com oom_kill igual a zero indica um contêiner operando permanentemente no limite: degradado, porém vivo. É exatamente o estado que antecede o incidente e que raramente dispara alerta. Como o processo recebe SIGKILL (sinal 9), o código de saída observado é 137, resultado da convenção POSIX 128 + número do sinal. O kubelet então registra o término e reinicia o contêiner conforme a restartPolicy. É por isso que a evidência canônica não está no status corrente do pod, mas no estado anterior do contêiner: kubectl get pod <pod> -n pets -o jsonpath='{.status.containerStatuses[0].lastState.terminated}' | jq # Saída esperada em um OOMKill: # { # "exitCode": 137, # "reason": "OOMKilled", # "startedAt": "...", # "finishedAt": "..." # } Reinícios sucessivos levam o pod a CrashLoopBackOff, em que o kubelet aplica um atraso exponencial entre tentativas, iniciando na ordem de dezenas de segundos e dobrando até um teto de poucos minutos, cujo valor padrão vem sendo revisado em versões recentes do Kubernetes. Esse atraso é o motivo pelo qual a indisponibilidade percebida cresce ao longo do incidente mesmo sem agravamento da causa raiz. 3.2 OOMKilled não é eviction: dois mecanismos, duas correções A distinção é operacionalmente decisiva porque as correções divergem: um OOMKill se resolve no manifesto do workload; um despejo se resolve na capacidade ou no agendamento do nó. Dimensão OOMKilled (cgroup) Eviction (kubelet) Gatilho Alocação excede memory.max do cgroup do contêiner memory.available do nó abaixo do limiar evictionHard/evictionSoft Quem decide Kernel Linux (OOM killer restrito ao cgroup) kubelet, ordenando os pods por QoS e excesso sobre requests Escopo Um contêiner O pod inteiro, podendo atingir vários pods do nó Sinal SIGKILL → exit code 137 Encerramento do pod; sem exit code 137 característico Evidência lastState.terminated.reason = OOMKilled status.phase = Failed, reason = Evicted Objeto do pod Preservado; contêiner reinicia no mesmo pod Pod permanece como registro de falha e é reagendado por seu controlador Correção típica Ajustar limits/requests ou o consumo da aplicação Capacidade do nó, requests coerentes, limiares de despejo, distribuição Nota. Um terceiro caso é frequentemente confundido com ambos: o encerramento do processo principal por erro da aplicação, que produz códigos de saída próprios (1, 2, 143 para SIGTERM). Verificar exitCode e reason antes de concluir por memória evita corrigir o sintoma errado. 3.3 Classes de QoS e a ordem em que os pods são sacrificados O Kubernetes deriva a classe de Quality of Service de cada pod a partir da relação entre requests e limits. Essa classe não é apenas rótulo: ela determina a prioridade de despejo e influencia diretamente o valor de oom_score_adj atribuído aos processos do contêiner. Classe de QoS Condição Prioridade de despejo Guaranteed requests iguais a limits para CPU e memória em todos os contêineres Última a ser despejada Burstable Pelo menos um request ou limit definido, sem igualdade entre eles Intermediária, proporcional ao excesso sobre o request BestEffort Nenhum request ou limit definido Primeira a ser despejada Para pods Burstable, o kubelet calcula oom_score_adj em função da fração da memória do nó reservada pelo request: quanto menor o request em relação à capacidade do nó, maior o score e mais atraente o processo se torna para o OOM killer. Pods Guaranteed recebem um valor fortemente negativo, e pods BestEffort recebem o valor máximo. Aplicação ao laboratório O order-service deste cenário declara requests de 10 Mi e limits de 20 Mi. A desigualdade entre os dois o classifica como Burstable, e o request muito baixo em relação à capacidade do nó eleva seu oom_score_adj. O workload é, portanto, simultaneamente o mais provável de estourar o próprio limite e um dos primeiros candidatos ao OOM killer sob pressão do nó, combinação que o torna um caso de teste representativo. Há uma consequência de projeto pouco explorada: elevar apenas o limit sem elevar o request melhora a sobrevivência ao OOMKill do cgroup, mas mantém o pod vulnerável em cenários de pressão do nó, porque o agendador continua reservando pouca memória para ele. Foi exatamente por isso que a recomendação do agente no laboratório ajustou os dois valores, e não apenas o limite. 3.4 Working set, RSS e por que o dashboard pode enganar A métrica que melhor aproxima a decisão do OOM killer é o working set, e não o RSS. Em cAdvisor, a fonte de container_memory_working_set_bytes e da métrica memoryWorkingSetBytes exposta pelo Container Insights, o working set corresponde ao uso total do cgroup menos o page cache inativo, isto é, a porção da memória que o kernel não conseguiria liberar trivialmente sob pressão. Métrica O que representa Uso recomendado container_memory_working_set_bytes Uso do cgroup menos page cache inativo Referência para alertas e para dimensionar limits container_memory_rss Páginas anônimas residentes do processo Investigação de vazamento no heap da aplicação container_memory_usage_bytes Uso total, incluindo page cache reclaimável Diagnóstico; superestima a pressão real container_memory_cache Page cache atribuído ao cgroup Explicar divergência entre usage e working set A armadilha prática: um painel construído sobre container_memory_usage_bytes pode indicar uso próximo ao limite sem risco real, porque boa parte é cache recuperável. Inversamente, um painel com média de 5 minutos pode mostrar 60% de uso e ainda assim o contêiner ser encerrado, porque o OOM killer reage a um pico instantâneo que a agregação suavizou. Alertas de memória devem usar working set e agregação por máximo, não por média. 3.5 Heap do runtime versus limite do contêiner Uma causa frequente de OOMKilled não está no limite em si, mas no desalinhamento entre o limite do cgroup e a política de heap do runtime. Runtimes que dimensionam o heap a partir da memória visível do host, e não do limite do cgroup, planejam crescer muito além do que o contêiner pode alocar, e o kernel encerra o processo antes que o coletor de lixo julgue necessário agir. Runtime Controle recomendado Observação Node.js --max-old-space-size (MB) Fixar abaixo do limite do contêiner; o order-service deste laboratório é Node.js JVM -XX:MaxRAMPercentage com UseContainerSupport Reservar espaço para metaspace, threads e buffers fora do heap .NET DOTNET_GCHeapHardLimitPercent; avaliar Server GC Server GC eleva o consumo por número de núcleos visíveis Go GOMEMLIMIT Limite flexível: intensifica a coleta em vez de abortar Python Limitar workers e pool de conexões Sem heap gerenciado; o consumo escala com concorrência Regra prática: o limite do contêiner deve acomodar o heap máximo do runtime somada a memória fora do heap, pilhas de threads, buffers de I/O, conexões, bibliotecas nativas e o próprio page cache anônimo. Dimensionar o heap igual ao limite do contêiner é uma causa clássica de OOMKilled sob carga. 3.6 Causas frequentes Limite subdimensionado: o consumo legítimo da carga excede o valor configurado, como ocorre neste laboratório. Vazamento de memória: o processo retém memória de forma progressiva entre requisições. Pico de tráfego ou payload atípico: a demanda transitória ultrapassa a capacidade provisionada. Concorrência excessiva: workers, filas ou caches locais ampliam o working set de forma não linear. Requests e limits incoerentes: o agendamento e a contenção não refletem o perfil real de consumo. Heap do runtime maior que o limite do cgroup: o processo planeja crescer além do permitido. Valores herdados de um dimensionamento anterior que nunca foi revisado após mudanças de código ou de carga. 4. Impactos para aplicações web em AKS Dimensão Impacto potencial Usuário Erros HTTP 5xx, timeouts, perda de sessão e latência elevada. Aplicação Interrupção de requisições em andamento, reprocessamento e perda de cache local. Plataforma CrashLoopBackOff, aumento de restarts e pressão sobre outros pods ou nós. Negócio Violação de SLO, risco à receita e degradação da experiência digital. Operações Escalonamento de plantão, investigação manual e aumento do MTTR. Um agravante específico do OOMKilled é o efeito em cascata: ao reiniciar, o contêiner reconstrói caches e refaz conexões, produzindo um pico de consumo de memória e CPU justamente no momento em que a capacidade agregada do serviço está reduzida. Isso pode encadear novos encerramentos em réplicas ainda saudáveis e transformar uma falha localizada em degradação do serviço. 5. Detecção: sinais, consultas e desenho do alerta A qualidade da investigação assistida depende da qualidade dos sinais disponíveis. Esta seção consolida as consultas usadas para detectar OOMKilled em AKS e o desenho da regra de alerta empregada no laboratório. 5.1 Sinais canônicos # Estado atual e contagem de reinícios kubectl get pods -n pets -o wide # Razão do término anterior, a evidência decisiva kubectl get pods -n pets -o custom-columns=\ NAME:.metadata.name,\ STATUS:.status.phase,\ RESTARTS:.status.containerStatuses[0].restartCount,\ REASON:.status.containerStatuses[0].lastState.terminated.reason,\ EXIT:.status.containerStatuses[0].lastState.terminated.exitCode # Limites efetivamente aplicados ao contêiner kubectl get deployment order-service -n pets \ -o jsonpath='{.spec.template.spec.containers[0].resources}' # Eventos correlatos na janela do incidente kubectl get events -n pets --sort-by=.lastTimestamp 5.2 Consultas KQL no Log Analytics Com Container Insights habilitado, o inventário de pods carrega o estado anterior de cada contêiner em formato JSON, o que permite isolar terminações por OOMKilled diretamente na consulta: // Contêineres encerrados por OOMKilled nas últimas 6 horas KubePodInventory | where TimeGenerated > ago(6h) | where isnotempty(ContainerLastStatus) | extend LastStatus = parse_json(ContainerLastStatus) | where tostring(LastStatus.reason) == "OOMKilled" | project TimeGenerated, ClusterName, Namespace, Name, ContainerName = ContainerName, ExitCode = toint(LastStatus.exitCode), RestartCount = ContainerRestartCount, FinishedAt = todatetime(LastStatus.finishedAt) | summarize Ocorrencias = count(), Ultima = max(FinishedAt), MaxRestarts = max(RestartCount) by ClusterName, Namespace, ContainerName | order by Ocorrencias desc Os eventos do Kubernetes oferecem uma segunda camada de confirmação, útil quando o intervalo de coleta do inventário perde uma terminação de curta duração: // Eventos de OOM e falhas de inicialização correlatas KubeEvents | where TimeGenerated > ago(6h) | where Reason in ("OOMKilling", "OOMKilled", "BackOff", "Failed") | project TimeGenerated, ClusterName, Namespace, Name, Reason, Message | order by TimeGenerated desc Para separar limite subdimensionado de vazamento, a consulta relevante é a tendência do working set contra o limite declarado. Um platô estável junto ao teto sugere subdimensionamento; uma inclinação positiva sustentada entre reinícios sugere retenção progressiva: // Working set máximo por contêiner, em janelas de 5 minutos Perf | where TimeGenerated > ago(24h) | where ObjectName == "K8SContainer" | where CounterName == "memoryWorkingSetBytes" | summarize MaxWorkingSetMi = max(CounterValue) / 1024 / 1024 by bin(TimeGenerated, 5m), InstanceName | render timechart 5.3 Equivalentes em PromQL Em clusters com Azure Monitor managed service for Prometheus, os mesmos sinais ficam disponíveis como séries temporais, o que facilita alertas baseados em razão de utilização: # Razão entre working set e limite declarado, por pod max by (namespace, pod, container) ( container_memory_working_set_bytes{namespace="pets", container!=""} ) / max by (namespace, pod, container) ( kube_pod_container_resource_limits{namespace="pets", resource="memory"} ) # Contêineres cuja última terminação foi OOMKilled kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1 # Taxa de reinícios na última hora increase(kube_pod_container_status_restarts_total{namespace="pets"}[1h]) > 0 Nota. Um alerta preventivo sobre a razão working set / limite acima de 0,85 por vários minutos antecipa o incidente antes do primeiro OOMKill, transformando uma interrupção em uma tarefa de dimensionamento planejada. Essa é a regra que mais reduz incidentes desta classe. 5.4 Desenho da regra de alerta utilizada no laboratório A regra empregada no cenário é uma Log Alert V2 sobre o workspace do Log Analytics, avaliando a consulta de OOMKilled e disparando quando a contagem de resultados é maior que zero. Parâmetro Valor no laboratório Consideração de produção Tipo Log search alert (Log Alerts V2) Consultas sobre logs; considerar alerta de métrica para latência menor Escopo Workspace do Log Analytics do cluster Escopo por cluster ou por assinatura, conforme o modelo de plantão Lógica Contagem de resultados maior que 0 Aumentar o limiar para tolerar reinícios isolados e evitar ruído Severidade 1, Error Alinhar à criticidade do serviço e à política de plantão Frequência / janela Avaliação periódica sobre janela curta Janela igual ou maior que a frequência, para não perder eventos Ação Action group com notificação por e-mail Encaminhar também a ITSM/PagerDuty e ao gatilho do agente Auto-resolução Padrão da regra Habilitar para incidentes transitórios; desabilitar se exigir baixa manual Latência esperada de ponta a ponta No laboratório, o pod entrou em OOMKilled às 17h45 e a notificação chegou às 17h47. Esses dois minutos somam ingestão no Log Analytics, período de avaliação da regra e entrega pelo action group. Alertas baseados em log carregam essa latência por construção, um dado relevante ao definir SLOs de detecção e ao decidir entre alerta de log e alerta de métrica. 6. O processo tradicional e seus limites 6.1 Fluxo típico de resposta O Azure Monitor dispara o alerta e notifica o plantão. O plantonista abre o portal, os dashboards e o Log Analytics. Executa comandos kubectl para localizar o pod e confirmar a razão do término. Compara consumo, limite, reinícios, eventos e alterações recentes. Formula uma hipótese, reinicia ou reimplanta o workload e acompanha a recuperação. Registra evidências e ações no sistema ITSM. 6.2 Limitações do modelo reativo Esse fluxo depende da experiência individual, exige alternância constante entre ferramentas e produz decisões inconsistentes entre plantonistas. Um restart reduz o sintoma, mas não distingue vazamento de memória, limite inadequado ou pico legítimo de carga. Sob pressão, cresce também o risco de ampliar recursos sem validação, perder evidências ao encerrar o contêiner afetado ou executar ações privilegiadas fora do processo de mudança. O custo mais alto, porém, é invisível: o conhecimento produzido durante a investigação permanece no indivíduo e não fica disponível para o próximo incidente da mesma classe. 7. Azure SRE Agent: arquitetura e modelo operacional O Azure SRE Agent é um agente de confiabilidade que conecta fontes de observabilidade, plataformas de incidente, repositórios de código e conhecimento operacional. Ele investiga causas prováveis, propõe mitigações e automatiza respostas orientadas por planos e runbooks, dentro de guardrails e fluxos de aprovação. Princípio de arquitetura O Azure Monitor permanece como fonte de detecção e evidência. O SRE Agent atua como camada de investigação, decisão e orquestração governada. O agente não substitui a observabilidade: ele consome e correlaciona o que ela produz. 7.1 Fontes de contexto A qualidade do diagnóstico é função direta das fontes conectadas. Durante a configuração, o agente solicita explicitamente a associação de quatro categorias de contexto. Fonte O que habilita Uso no cenário OOMKilled Recursos do Azure Consultar e operar recursos por meio da identidade do agente Ler o estado do cluster AKS e aplicar a mitigação aprovada Logs Consultar workspaces do Log Analytics Correlacionar eventos, inventário de pods e métricas de working set Código Acessar repositórios e artefatos de engenharia Relacionar o limite aplicado ao manifesto de origem Incidentes Integrar Azure Monitor, ServiceNow e PagerDuty Receber o alerta e vincular a investigação ao incidente 7.2 Execução por ferramentas e classificação de risco O agente não age por um canal opaco, cada passo é uma chamada de ferramenta explícita, um comando da CLI do Azure, uma consulta KQL, um comando kubectl, apresentada na thread com o comando exato e uma classificação de risco associada. No laboratório, comandos de leitura como az aks show aparecem marcados como Safe, enquanto operações como kubectl get deployments e kubectl patch recebem a marcação Medium risk. Essa transparência tem duas consequências práticas. A primeira é auditoria: a thread registra a sequência exata de comandos, permitindo reconstruir a investigação. A segunda é revisão: o operador avalia o comando concreto, não uma descrição em linguagem natural do que o agente pretende fazer. 7.3 Modos de execução (Run Modes) Os modos de execução controlam o fluxo de aprovação, isto é, se o agente pergunta antes de agir. É importante separar esse conceito das permissões, que controlam o acesso ao recurso. O agente precisa das duas condições satisfeitas para executar uma ação. Modo Comportamento Indicação Review O agente propõe a ação e aguarda Approve ou Deny Produção, infraestrutura crítica, alertas de segurança Autonomous O agente executa imediatamente e relata o que fez Ambientes de não produção e tarefas recorrentes confiáveis Três detalhes que mudam o desenho de governança Primeiro: o modo de execução é definido por plano de resposta e por tarefa agendada, não no nível do agente; a configuração do agente serve apenas como padrão de fallback. Segundo: os botões Approve e Deny aparecem para operações de infraestrutura do Azure; outras ações, como enviar e-mail, publicar no Teams ou consultar fontes externas, seguem a instrução do plano de resposta e exigem hooks ou políticas de acesso a ferramentas para receber controle equivalente. Terceiro: apenas administradores do SRE Agent podem aprovar ações, o que materializa a segregação de funções. Uma observação de adoção relevante: os planos de resposta e as tarefas agendadas assumem Autonomous como padrão, enquanto o agente é criado em Review. Assumir que criar o agente em Review protege automaticamente todos os fluxos é um erro de configuração fácil de cometer e caro de descobrir. 7.4 Permissões, escopo e elevação sob demanda O agente opera por meio de uma identidade gerenciada, e o que ele consegue fazer é delimitado pelas atribuições RBAC dessa identidade e pelo escopo em que foram concedidas. Quando o agente não possui a permissão necessária para uma operação, ele solicita acesso temporário por meio do fluxo On-Behalf-Of do Microsoft Entra, em vez de falhar silenciosamente. Esse comportamento é arquiteturalmente importante: ele permite conceder à identidade do agente um conjunto mínimo e permanente de permissões de leitura, deixando as operações de escrita dependentes de uma elevação explícita e rastreável. É o oposto do padrão adotado no laboratório, que concede permissões amplas por conveniência de demonstração. 7.5 Hooks e políticas de acesso a ferramentas Hooks são pontos de verificação personalizados que validam, auditam ou bloqueiam o comportamento do agente em momentos específicos do fluxo. Eles complementam os modos de execução: enquanto os modos controlam quando o agente pode agir, os hooks controlam o que acontece antes e depois de cada ação. Evento Quando dispara Aplicações típicas PostToolUse Após a execução de uma ferramenta Auditar o uso, bloquear ou sinalizar operações inseguras, injetar contexto adicional no resultado Stop Quando o agente vai devolver a resposta final Validar completude, exigir formato, rejeitar a resposta e forçar continuidade da investigação Tipos de execução: Prompt, avaliado pelo modelo para verificações que exigem julgamento; e Command, script determinístico para auditoria e aplicação de política. Escopos de configuração: no nível do agente, aplicando-se a todas as threads; ou no nível de um agente personalizado. Quando ambos correspondem, os dois executam. Políticas de acesso a ferramentas complementam os hooks ao restringir previamente quais ferramentas podem ser invocadas em cada contexto. 7.6 Provedor de modelo e residência de dados O provedor de modelo é escolhido na criação do agente e pode ser alterado depois, sem recriar o recurso. Há duas famílias disponíveis, com perfis distintos: modelos do Azure OpenAI e modelos Anthropic Claude. Para organizações reguladas, essa escolha ultrapassa o critério de qualidade de raciocínio e entra no domínio de conformidade: os provedores diferem quanto à cobertura de requisitos de residência de dados, incluindo o EU Data Boundary, e a disponibilidade varia por região. A recomendação é validar os requisitos de residência e a lista de regiões suportadas na documentação vigente antes de padronizar o provedor para cargas de produção. 7.7 Modelo de consumo O consumo do agente é medido em Azure Agent Units e combina dois componentes: um fluxo contínuo, associado à existência do agente e ao monitoramento de base, e um fluxo ativo, proporcional aos tokens processados durante investigações. Modelos com janelas de contexto maiores tendem a consumir mais no fluxo ativo. A implicação de FinOps é direta: o custo escala com o volume de investigações e com a profundidade do contexto conectado, não com o número de recursos monitorados. Reduzir alertas ruidosos diminui o custo do agente pelo mesmo mecanismo que reduz a fadiga do plantão. Consulte a página de preços para os valores vigentes. 8. Processo de resposta com o SRE Agent Receber e classificar: consumir o incidente do Azure Monitor e aplicar filtros por severidade, serviço e título. Coletar evidências: consultar Log Analytics, métricas, eventos do Kubernetes, estado do pod, histórico de implantação e runbooks. Formar hipóteses: comparar limite versus uso, tendência temporal, payload, versão implantada e eventos correlatos. Validar: sustentar cada hipótese com evidência observável e registrar as alternativas descartadas. Recomendar: apresentar ação imediata, correção estrutural, risco associado e critérios de rollback. Agir sob governança: executar apenas ações pré-autorizadas ou aguardar aprovação, conforme o modo de execução do plano. Verificar e aprender: confirmar a estabilidade, documentar o resultado e enriquecer a memória operacional. A etapa 4 é a que mais diferencia uma investigação assistida de uma sugestão genérica. Um diagnóstico útil não afirma apenas qual é a causa provável: registra qual evidência sustenta a conclusão, qual hipótese foi descartada e por quê. É esse registro que permite ao operador revisar a decisão em segundos, em vez de refazer a investigação. 9. Cenário do incidente 9.1 Situação O serviço order-service, no namespace pets, processa requisições de uma aplicação web de comércio eletrônico. Após aumento de tráfego e uso de payloads maiores, as réplicas passam a reiniciar. O Azure Monitor detecta a elevação na contagem de reinicializações e a ocorrência de eventos OOMKilled. 9.2 Linha de investigação # Evidência buscada Interpretação 1 reason igual a OOMKilled e exitCode 137 em lastState Encerramento pelo kernel por ultrapassagem do limite do cgroup, não falha da aplicação. 2 Working set atingindo o limite declarado Distinguir limite inadequado de crescimento anômalo entre requisições. 3 Pico correlacionado a tráfego ou tamanho de payload Avaliar comportamento legítimo versus retenção progressiva de memória. 4 Implantação recente do workload Determinar se houve regressão em código ou em configuração de recursos. 5 Contagem de restarts e erros HTTP Quantificar impacto ao usuário e urgência da mitigação. 6 Classe de QoS e relação requests/limits Avaliar exposição adicional a despejo por pressão no nó. 9.3 Formato do diagnóstico assistido O agente entrega um resumo com causa provável, grau de confiança, evidências que a sustentam, alternativas descartadas e plano de mitigação com critério de reversão. A estrutura importa tanto quanto o conteúdo: ela permite que a revisão humana seja auditoria, e não repetição do trabalho. O contêiner atingiu repetidamente o limite de memória durante o processamento de payloads acima do padrão histórico. Não há evidência suficiente de crescimento contínuo entre requisições; a hipótese principal é limite subdimensionado para a nova carga. Mitigação proposta: elevar limits e requests de memória, com verificação do consumo após a alteração. 10. Implementação e validação do cenário no AKS A seguir, o padrão conceitual é aplicado a um ambiente AKS de demonstração. O objetivo é conectar o cluster ao SRE Agent, conceder as permissões necessárias, integrar as fontes de observabilidade e validar o fluxo de diagnóstico e recuperação de um pod afetado por OOMKilled. Preparar o ambiente: validar o cluster AKS, a aplicação de demonstração e o estado inicial do workload. Criar o SRE Agent: provisionar o agente e selecionar o provedor de modelo conforme os requisitos do ambiente. Conectar as fontes de dados: integrar o cluster, o Azure Monitor e o Log Analytics para disponibilizar alertas, logs e métricas. Conceder permissões: atribuir à identidade gerenciada do agente o acesso necessário para investigar e, no laboratório, executar a remediação aprovada. Validar diagnóstico e recuperação: provocar o evento OOMKilled, acompanhar a investigação, aprovar a recomendação e confirmar a recuperação do pod. Escopo do laboratório As permissões concedidas nesta seção são deliberadamente amplas para reduzir o atrito da demonstração. Elas não representam uma configuração recomendada para produção. A seção 10.5 apresenta o desenho de menor privilégio equivalente, e a seção 12 detalha as implicações de segurança. 10.1 Ambiente e pré-requisitos A aplicação utilizada é o AKS Store Demo, exemplo de referência da Microsoft que representa uma loja de comércio eletrônico decomposta em microsserviços poliglotas. A tabela a seguir consolida a configuração do ambiente, para permitir a reprodução do cenário. Componente Configuração no laboratório Cluster AKS-SRE-Demo-Cluster, SKU Base, tier Free, 1 node pool Versão do Kubernetes 1.35.6 Região East US 2 Rede Azure CNI Overlay Observabilidade Container Insights habilitado, enviando logs e métricas ao Log Analytics Aplicação AKS Store Demo, namespace pets, exposta por Service do tipo LoadBalancer Workload em falha order-service (Node.js), requests 10 Mi / limits 20 Mi de memória Alerta Alert-OOMKilled-Pods, Log Alerts V2, severidade 1, Error Agente Azure SRE Agent provisionado no grupo de recursos Azure-SRE-RG A arquitetura da aplicação é relevante para o diagnóstico: o order-service recebe pedidos do store-front e os publica em uma fila RabbitMQ, consumida pelo makeline-service. Um serviço que faz buffer de mensagens antes de publicar é estruturalmente sensível ao tamanho do payload e à concorrência, precisamente o perfil que torna um limite de 20 Mi insustentável sob carga. 10.2 Arquitetura e estado inicial da aplicação Figura 1: Arquitetura do AKS Store Demo. O store-front e o store-admin consomem o order-service (Node.js), o product-service (Rust), o makeline-service (Go) e o ai-service (Python), com RabbitMQ como broker de mensagens e MongoDB como armazenamento de estado. Figura 2: Página inicial da aplicação de demonstração, publicada por meio de um Service do tipo LoadBalancer. O endereço IP público foi suprimido. Figura 3: Visão geral do cluster AKS antes da investigação: Kubernetes 1.35.6, região East US 2, configuração de rede Azure CNI Overlay e um único node pool. Identificadores de assinatura e o endereço do servidor de API foram suprimidos. A inspeção do namespace revela o estado que servirá de referência para todo o exercício. O pod do order-service encontra-se em CrashLoopBackOff, acumulando reinicializações sucessivas, o sintoma de superfície de um encerramento repetido pelo kernel. Figura 4: Saída de kubectl get all -n pets. O pod do order-service aparece em CrashLoopBackOff com reinicializações acumuladas, enquanto os demais serviços do namespace permanecem íntegros. Endereços IP públicos foram suprimidos. Nota. Observe que apenas um serviço está afetado. Essa assimetria já elimina hipóteses de escopo mais amplo, pressão de memória no nó, falha do runtime de contêiner ou problema de rede, e concentra a investigação na configuração ou no comportamento daquele workload específico. 10.3 Criação do agente e escolha do provedor de modelo O agente é provisionado no portal do SRE Agent, em sre.azure.com. Figura 5: Portal do Azure SRE Agent. A criação inicia pela opção Create Agent. No formulário, define-se o grupo de recursos, o nome do agente e o provedor de modelo. É possível escolher entre Azure OpenAI, com a família GPT-5, e Anthropic, com a família Claude, e alterar essa opção posteriormente sem recriar o recurso. Conforme discutido na seção 7.6, essa escolha deve considerar também os requisitos de residência de dados da organização. Figura 6: Formulário de criação do agente, com a seleção do grupo de recursos, do nome e do provedor de modelo. Figura 7: Revisão da configuração antes da confirmação. Nomes de assinatura foram suprimidos. Figura 8: Provisionamento do agente em andamento. Figura 9: Agente criado. A opção Set up your agent conduz à configuração das fontes de contexto. 10.4 Conexão das fontes de contexto O objetivo do agente é investigar as aplicações em execução no cluster AKS. Para isso, conecta-se primeiro o recurso do cluster. Figura 10: Associação do recurso do cluster AKS ao agente. Figura 11: Seleção do grupo de recursos onde o cluster AKS está provisionado. Figura 12: Confirmação do escopo selecionado. Nomes de assinatura foram suprimidos. Neste laboratório, o agente receberá permissões ampliadas para executar tarefas específicas no cluster. Essa configuração é restrita ao ambiente de demonstração. Em produção, recomenda-se aplicar o princípio do menor privilégio, limitar o escopo das funções, exigir aprovação para ações de maior impacto e validar previamente operações autorizadas, como alterar um pod ou recuperar um nó com estado desconhecido. Figura 13: Definição do nível de permissão concedido ao agente sobre os recursos conectados. Em seguida, integra-se o agente ao Azure Monitor, para que ele acesse os alertas configurados e inicie uma investigação quando o incidente correspondente for emitido. Figura 14: Integração com o Azure Monitor, habilitando o consumo de alertas como gatilho de investigação. Além do Azure Monitor, o agente pode ser integrado ao ServiceNow e ao PagerDuty para apoiar fluxos de investigação e gestão de incidentes, permitindo que a thread da investigação seja correlacionada ao registro formal do incidente. Figura 15: Integrações disponíveis com plataformas de gestão de incidentes. O cluster tem o Container Insights habilitado e envia logs e métricas ao workspace do Log Analytics. Conectar esse workspace é o que permite ao agente executar as consultas KQL apresentadas na seção 5 durante a investigação. Figura 16: Início da conexão com o Log Analytics. Figura 17: Seleção do workspace do Log Analytics associado ao cluster. Figura 18: Preenchimento dos dados do workspace. Identificadores de assinatura foram suprimidos. Figura 19: Conclusão da conexão com o Log Analytics. Figura 20: Painel de configuração das fontes de contexto, consolidando código, logs, recursos do Azure e incidentes. A amplitude do contexto conectado determina diretamente a profundidade possível do diagnóstico. 10.5 Identidade gerenciada e atribuições RBAC Neste ponto o agente já é funcional para investigação. Para que ele também possa executar a remediação no cluster, atribuem-se funções à sua identidade gerenciada. O primeiro passo é identificar essa identidade. Figura 21: Identidade gerenciada associada ao agente. Os identificadores de cliente, de principal e de assinatura foram suprimidos. No laboratório, foram atribuídas as funções Azure Kubernetes Service Cluster Admin Role e Azure Kubernetes Service Contributor Role, com escopo no grupo de recursos do cluster. az role assignment create ` --assignee "<uami-client-id>" ` --role "Azure Kubernetes Service Cluster Admin Role" ` --scope "/subscriptions/<subscription-id>/resourceGroups/Azure-SRE-RG" az role assignment create ` --assignee "<uami-client-id>" ` --role "Azure Kubernetes Service Contributor Role" ` --scope "/subscriptions/<subscription-id>/resourceGroups/Azure-SRE-RG" Figura 22: Resultado da atribuição da função Azure Kubernetes Service Cluster Admin Role. Identificadores de assinatura, de principal e da atribuição foram suprimidos. Figura 23: Resultado da atribuição da função Azure Kubernetes Service Contributor Role. A confirmação é feita no painel Access control (IAM) do cluster, localizando as atribuições concedidas à identidade gerenciada do agente. Figura 24: Painel de controle de acesso do cluster, confirmando as duas atribuições à identidade gerenciada do agente (destacadas). Identificadores de objeto e nomes de entidades de serviço do locatário foram suprimidos. Por que essa configuração não deve ir para produção A função Azure Kubernetes Service Cluster Admin Role autoriza a obtenção da credencial administrativa do cluster. Essa credencial é um certificado de cliente que opera fora da integração com o Microsoft Entra ID e da autorização RBAC do Kubernetes, ou seja, contorna exatamente os controles de identidade que a organização configurou no cluster. Some-se a isso a função Contributor no grupo de recursos, e a identidade do agente passa a acumular controle administrativo do plano de dados e amplo poder no plano de controle. O desenho equivalente sob menor privilégio troca esse par de funções por um conjunto mínimo, com escopo no cluster e não no grupo de recursos, apoiando-se no fluxo de elevação sob demanda descrito na seção 7.4 para as operações de escrita eventuais. Necessidade Função recomendada Escopo Obter kubeconfig respeitando o Entra ID Azure Kubernetes Service Cluster User Role Cluster Leitura no plano de dados do Kubernetes Azure Kubernetes Service RBAC Reader Cluster ou namespace Escrita controlada no plano de dados Azure Kubernetes Service RBAC Writer Namespace do workload Consultar métricas e logs Monitoring Reader Workspace do Log Analytics Operações de infraestrutura do cluster Elevação sob demanda via fluxo On-Behalf-Of Por operação, com registro Nota. As funções RBAC do Kubernetes (Reader, Writer, Admin) exigem que a autorização RBAC do Azure para Kubernetes esteja habilitada no cluster. Escopar por namespace, e não pelo cluster inteiro, reduz o raio de impacto de uma ação incorreta ao conjunto de workloads sob responsabilidade daquele agente. 10.6 Investigação assistida A primeira interação é deliberadamente simples: uma pergunta aberta sobre a saúde do cluster, sem indicar o problema. O objetivo é avaliar se o agente chega ao workload afetado por conta própria. Figura 25: Estado do pod do order-service imediatamente antes da investigação, usado como linha de base para validar diagnóstico e recuperação. Figura 26: O agente inicia a investigação executando comandos de inspeção. Cada chamada de ferramenta exibe o comando exato e a classificação de risco associada: Safe para az aks show e Medium risk para kubectl get deployments. Identificadores de assinatura foram suprimidos. A Figura 26 concentra o que diferencia esse modelo de uma automação convencional. O agente não executa um runbook fixo: ele escolhe o próximo comando a partir do resultado do anterior, e cada escolha fica registrada com o comando literal e sua classificação de risco. O operador acompanha a cadeia de raciocínio como uma sequência auditável de operações, não como uma caixa-preta que devolve uma conclusão. Figura 27: O agente identifica o pod do order-service em CrashLoopBackOff, com 13 reinicializações acumuladas. A partir do estado do pod, o agente correlaciona a razão do término com os limites declarados no manifesto e conclui que o limite de 20 Mi é insuficiente para a carga observada. A recomendação é elevar o limite para 128 Mi e a solicitação para 64 Mi, acompanhando o consumo após a alteração. Figura 28: Diagnóstico do agente: OOMKilled associado ao limite de 20 Mi e à solicitação de 10 Mi, com recomendação de elevação para 128 Mi e 64 Mi respectivamente. Figura 29: Continuação do diagnóstico, com o detalhamento das evidências e das alternativas consideradas. Leitura crítica da recomendação A recomendação ajusta requests e limits em conjunto, e não apenas o limite, o que, conforme a seção 3.3, preserva a classe Burstable com uma reserva de memória compatível e reduz a exposição a despejo por pressão no nó. O agente também sinaliza que valores maiores, como 256 Mi, só devem ser adotados após análise de métricas, testes de carga e investigação de possível vazamento. Essa ressalva é o que separa uma mitigação de uma correção: o número proposto restabelece o serviço, mas ainda não é um dimensionamento validado. 10.7 Mitigação aprovada e verificação A recomendação é apresentada como uma ação concreta a ser aprovada. O comando exibido é exatamente o que será executado: kubectl patch deployment order-service -n pets --type='json' -p='[ {"op":"replace", "path":"/spec/template/spec/containers/0/resources/limits/memory", "value":"128Mi"}, {"op":"replace", "path":"/spec/template/spec/containers/0/resources/requests/memory", "value":"64Mi"} ]' O efeito é alterar os recursos de memória do deployment order-service no namespace pets: o limite passa de 20 Mi para 128 Mi e a solicitação, de 10 Mi para 64 Mi. Como a alteração atinge o template do pod, o controlador executa um rollout, substituindo as réplicas existentes. Figura 30: Proposta de alteração apresentada para revisão. A ação é classificada como Medium risk e apresenta os controles Approve action e Cancel, com a indicação de que as permissões do agente serão utilizadas para concluí-la. Aprovada a ação, o agente a executa e passa espontaneamente à verificação, consultando o estado do novo pod em vez de declarar sucesso pela ausência de erro no comando. Figura 31: Após aplicar o patch, o agente consulta o estado do novo pod e aguarda a conclusão do startup probe antes de concluir. Esse detalhe merece destaque: o agente distingue a execução bem-sucedida de um comando da recuperação efetiva do serviço, e aguarda a passagem pelo startup probe antes de afirmar que o problema foi resolvido. É a mesma disciplina que se espera de um operador experiente. Figura 32: Comparação entre o estado anterior e o posterior apresentada pelo agente, acompanhada da ressalva sobre reconciliação com a fonte da verdade quando o deployment é gerenciado por GitOps, Helm ou pipeline de IaC. Dimensão Antes Depois Estado do pod CrashLoopBackOff, 13 reinicializações Running, Ready, 0 reinicializações Memória (request/limit) 10 Mi / 20 Mi 64 Mi / 128 Mi Classe de QoS Burstable, com reserva mínima Burstable, com reserva compatível Figura 33: Validação manual por kubectl: todos os objetos do namespace pets em execução, com o order-service estável e sem reinicializações. 10.8 Reconciliação com a fonte da verdade Um ponto levantado pelo próprio agente na Figura 32 merece tratamento explícito, porque é onde a maioria das remediações assistidas falha silenciosamente: a alteração foi aplicada diretamente ao objeto no cluster. Se o deployment for gerenciado por GitOps, Helm ou qualquer pipeline de infraestrutura como código, a fonte da verdade continua declarando 20 Mi. A próxima reconciliação do controlador, ou a próxima implantação, reverterá a correção e reintroduzirá o incidente, agora sem a memória do diagnóstico que o originou. O sintoma reaparece dias depois, aparentemente sem causa. Modelo de gestão Efeito do kubectl patch Ação obrigatória de fechamento Manifesto aplicado manualmente Persiste até a próxima aplicação Atualizar o manifesto no repositório Helm Revertido no próximo upgrade Atualizar o values.yaml e versionar o chart GitOps (Flux/Argo CD) Revertido na próxima reconciliação Abrir pull request na fonte da verdade Pipeline de IaC Revertido na próxima execução Atualizar o template e o registro de mudança Regra operacional Toda mitigação aplicada diretamente ao cluster deve gerar um item de acompanhamento na fonte da verdade antes do encerramento do incidente. Um incidente cuja correção existe apenas no cluster não está resolvido: está agendado para reincidir. 10.9 Do acionamento sob demanda ao disparo por alerta Até aqui, o agente foi acionado sob demanda. A etapa seguinte valida o caminho automatizado: um alerta do Azure Monitor configurado para disparar quando um pod apresentar terminação por OOMKilled. Figura 34: Regra de alerta configurada no Azure Monitor para detectar terminações por OOMKilled no cluster. Para provocar o evento de forma controlada, utiliza-se uma aplicação local que gera carga sobre o order-service até que o consumo ultrapasse o limite do cgroup. Figura 35: Painel local de simulação, com o gatilho de geração de carga sobre o order-service e o acompanhamento de pods íntegros, terminações por OOMKilled e alertas disparados. Às 17h45, o pod entra em estado OOMKilled com código de saída 137. Figura 36: Confirmação do estado por kubectl, evidenciando a terminação por OOMKilled. Dois minutos após o evento, a notificação do alerta chega ao destinatário configurado no action group, intervalo que corresponde à soma da ingestão no Log Analytics, do período de avaliação da regra e da entrega da notificação. Figura 37: Notificação recebida por e-mail às 17h47, referente à regra Alert-OOMKilled-Pods. Figura 38: Detalhe da notificação, indicando a condição atendida: contagem de resultados maior que zero, com o valor alcançado igual a 1. O disparo é então confirmado no portal do Azure, com a severidade e o tipo de sinal registrados. Figura 39: Alerta registrado no portal do Azure com estado Fired. Figura 40: Detalhes do alerta: severidade 1, Error, tipo de sinal Log Alerts V2 e horário de disparo consistente com o evento observado no cluster. Com esse alerta emitido e o agente integrado ao Azure Monitor, o gatilho necessário para a automação completa está validado. A Parte 2 tratará da transição do acionamento assistido para o fluxo disparado automaticamente pelo alerta, incluindo planos de resposta, modos de execução por plano e a integração com o processo de gestão de incidentes. 10.10 Do restabelecimento ao dimensionamento correto O laboratório encerra com o serviço estável, mas os valores aplicados são uma mitigação informada, não um dimensionamento validado. Fechar o ciclo exige um método, e esse método é independente do agente. Estabelecer a linha de base: medir o working set em percentil 95 e 99 sobre uma janela que cubra o ciclo completo de carga do serviço, incluindo picos previsíveis. Definir o request pelo consumo típico: o percentil 95 do working set em regime normal, valor que o agendador usará para reservar capacidade. Definir o limit com folga sobre o pico: o percentil 99 acrescido de margem para transientes, tipicamente entre 25% e 50%, evitando folga excessiva que desperdiça capacidade do nó. Alinhar o runtime: ajustar o heap máximo conforme a seção 3.5, reservando espaço para memória fora do heap. Validar sob carga: reproduzir o cenário que originou o incidente e confirmar que o working set permanece abaixo do limite com margem estável. Descartar vazamento: comparar a inclinação do consumo entre reinícios; crescimento sustentado sem correlação com a carga indica retenção progressiva, que nenhum aumento de limite resolve. Automatizar a revisão: usar o Vertical Pod Autoscaler em modo recomendação para acompanhar a adequação dos valores ao longo do tempo, sem aplicação automática. Nota. Elevar o limite de memória é uma resposta legítima quando a evidência aponta subdimensionamento, e ilegítima quando serve para adiar a investigação de um vazamento. A diferença entre as duas situações está na inclinação do consumo entre reinícios, um dado que só existe se a telemetria for retida além do ciclo de vida do contêiner. 11. Governança, aprovação e rastreabilidade Esta seção separa deliberadamente dois planos: capacidades do produto, que podem ser verificadas na documentação, e recomendações de arquitetura, que cada organização deve validar e adaptar às próprias políticas. Nota. Nomenclaturas, opções e comportamentos evoluem. Antes de aplicar este padrão em produção, valide a documentação vigente, os controles disponíveis no ambiente e os requisitos internos de segurança, auditoria e mudança. 11.1 O que foi observado no laboratório O agente coletou métricas, eventos e o estado dos pods para investigar o incidente, com cada comando registrado na thread. Identificou que os valores de memória estavam subdimensionados para a carga observada. Propôs um comando kubectl patch explícito, exibindo a alteração de 20 Mi para 128 Mi no limite e de 10 Mi para 64 Mi na solicitação. Apresentou a ação para revisão humana, classificada como Medium risk, e aguardou aprovação antes de executar. Após a aprovação, executou a alteração e verificou a recuperação do pod antes de concluir. Sinalizou espontaneamente o risco de reversão da correção em cenários gerenciados por GitOps ou Helm. Esse comportamento reflete o cenário demonstrado e não estabelece regra universal para todas as ferramentas, comandos ou ambientes. 11.2 Referência de governança para a organização A tabela a seguir é uma recomendação de desenho, não uma matriz fixa nem garantia de comportamento do produto. Categoria Exemplos Política sugerida Leitura get, list, show, describe, consultas KQL Permitir quando escopo e RBAC forem compatíveis com a investigação. Escrita patch, update, scale, restart Exigir revisão humana em ambientes críticos por meio de Review Mode no plano de resposta ou de hooks. Alto impacto delete, redução de capacidade, mudanças destrutivas Restringir por RBAC e por política de acesso a ferramentas; submeter a processo formal de mudança ou negar conforme o risco. A classificação de risco deve ser definida pela organização conforme o ambiente, o tipo de recurso, a criticidade do serviço e os requisitos regulatórios. A documentação do produto não deve ser interpretada como regra universal de que toda leitura é sempre permitida, toda escrita sempre exige aprovação ou todo delete é sempre negado. 11.3 Camadas de evidência para auditoria Nenhuma fonte isolada reconstrói o incidente por completo. A rastreabilidade útil vem da correlação entre camadas com escopos distintos. Camada O que registra Limitação Thread do agente Comandos executados, evidências, proposta e aprovação Escopo da conversa; confirmar retenção e exportação no ambiente Telemetria de auditoria do agente Atividade do agente para acompanhamento e conformidade Confirmar granularidade e campos disponíveis no ambiente Log de auditoria do Kubernetes Chamadas ao servidor de API do cluster Requer habilitação e destino de coleta configurados Azure Activity Log Operações do plano de controle do Azure Não cobre alterações internas do Kubernetes Sistema de ITSM Registro formal de incidente e mudança Depende da integração e da disciplina de preenchimento Recomenda-se correlacionar, conforme disponibilidade: horário da proposta e da execução; a ação ou comando apresentado ao operador; o estado anterior e posterior do recurso; o resultado da ferramenta e mensagens de erro relevantes; os identificadores do agente, recurso, alerta, incidente e mudança; e as informações de aprovação expostas pelos mecanismos disponíveis. 11.4 Fluxo recomendado para este cenário Etapa Aplicação no laboratório Controle recomendado 1. Diagnóstico e proposta O agente consulta métricas, eventos e estado do cluster e apresenta a ação recomendada. RBAC de menor privilégio, escopo por namespace e evidências observáveis. 2. Revisão humana Em Review Mode, o operador analisa o comando, o impacto e o escopo antes da execução. Critérios de aprovação e rollback definidos; aprovação restrita a administradores do agente. 3. Execução controlada Após a aprovação, o agente executa a alteração dentro das permissões concedidas. Identidade gerenciada, escopo mínimo, hooks de PostToolUse para auditoria. 4. Verificação O agente valida a recuperação antes de concluir. Critério de sucesso objetivo, baseado em estado observado e não em ausência de erro. 5. Reconciliação Não aplicável ao laboratório; a alteração permaneceu no cluster. Atualizar a fonte da verdade e vincular ao registro de mudança. 6. Registro O resultado é apresentado na thread do agente. Correlação entre telemetria, logs do cluster, registros do Azure e ITSM. Enquadramento Os modos de execução, os controles de acesso, os hooks e a telemetria são capacidades do produto. A matriz de risco, as evidências exigidas, as convenções de repositório e as integrações de auditoria são decisões de governança da organização. Manter essa separação explícita evita transformar recomendações de arquitetura em garantias de produto. 12. Considerações de segurança para operações agênticas Introduzir um agente com capacidade de execução no caminho de resposta a incidentes altera o modelo de ameaças da plataforma. As considerações a seguir derivam diretamente da configuração demonstrada. Consideração Risco Mitigação Privilégio excessivo Cluster Admin Role concede credencial que contorna o Entra ID e o RBAC do Kubernetes Substituir por Cluster User + RBAC Reader/Writer com escopo por namespace; elevar sob demanda Escopo amplo demais Funções no grupo de recursos alcançam recursos não relacionados ao incidente Escopar no recurso, não no grupo de recursos Segregação de funções Quem opera aprova a própria ação Restringir aprovação a administradores do agente distintos de quem aciona a investigação Conteúdo não confiável no contexto Logs e eventos podem carregar texto capaz de influenciar o raciocínio do agente Hooks de PostToolUse e políticas de acesso a ferramentas; revisão humana para ações de escrita Raio de impacto Uma ação incorreta atinge o cluster inteiro Escopo por namespace, janelas de mudança e critérios de rollback definidos previamente Residência de dados O provedor de modelo determina onde o contexto é processado Selecionar o provedor conforme os requisitos regulatórios e as regiões suportadas Exposição em capturas e threads Identificadores e segredos aparecem em evidências compartilhadas Revisar artefatos antes de circular; suprimir identificadores, como feito neste documento O item sobre conteúdo não confiável merece atenção particular. Durante a investigação, o agente lê logs e eventos produzidos pela aplicação, dados que, em última instância, podem ser influenciados por entradas de usuários. Tratar esse conteúdo como dado, e não como instrução, é responsabilidade compartilhada entre o produto e o desenho de governança: manter operações de escrita sob revisão humana em ambientes críticos é a defesa mais direta contra essa classe de risco. Princípio de composição Nenhum controle isolado é suficiente. A defesa em profundidade nesse modelo compõe quatro camadas independentes: RBAC delimita o que a identidade alcança; os modos de execução determinam se há aprovação humana; a classificação de risco por chamada de ferramenta informa a decisão do revisor; e os hooks aplicam política e auditoria antes e depois de cada ação. Remover qualquer uma delas transfere risco às demais. 13. Métricas para avaliar a adoção A adoção de resposta assistida deve ser avaliada por evidência, não por percepção. As métricas a seguir permitem comparar o antes e o depois de forma objetiva. Métrica O que mede Sinal de maturidade MTTD Tempo entre o evento e a detecção Estável; limitado pela latência de ingestão e avaliação MTTA Tempo entre o alerta e o início da investigação Redução acentuada com investigação automática MTTR Tempo entre o alerta e a recuperação verificada Redução sustentada, sem aumento de reincidência Taxa de aprovação sem alteração Recomendações aprovadas sem ajuste pelo operador Crescente; habilita migração seletiva para modo autônomo Taxa de reincidência em 30 dias Incidentes da mesma classe que retornam Decrescente; indica correção estrutural e não apenas mitigação Aderência à reconciliação Mitigações refletidas na fonte da verdade Próxima de 100%; principal defesa contra reincidência Ações autônomas por classe de risco Distribuição entre leitura, escrita e alto impacto Crescimento apenas nas classes com histórico consistente A recomendação de adoção é conservadora e apoiada na própria documentação do produto: iniciar em Review Mode, observar as recomendações por algumas semanas e migrar para modo autônomo apenas os gatilhos cujo padrão de aprovação já se mostrou consistente. A taxa de aprovação sem alteração é o indicador que sustenta essa decisão com dados. 14. Limitações e armadilhas observadas A mitigação foi aplicada diretamente ao cluster. Em ambientes gerenciados por GitOps, Helm ou IaC, a correção será revertida se a fonte da verdade não for atualizada. Os valores de 128 Mi e 64 Mi restabeleceram o serviço, mas constituem mitigação informada, não dimensionamento validado por testes de carga. As permissões concedidas no laboratório são amplas por conveniência de demonstração e contornam a integração com o Entra ID no plano de dados do cluster. Alertas baseados em log carregam latência de ingestão e de avaliação, dois minutos no laboratório, o que os torna inadequados para SLOs de detecção mais agressivos. Um restart bem-sucedido mascara a distinção entre limite subdimensionado e vazamento de memória; sem telemetria retida além do ciclo do contêiner, a diferença se perde. O modelo pode propor valores plausíveis, mas a validação por métricas e carga permanece responsabilidade da engenharia. O cenário cobre uma única classe de falha em um único workload; a generalização para outras classes exige validação própria. 15. Conclusão da Parte 1 O Azure Monitor e o Azure SRE Agent transformaram um evento OOMKilled em um fluxo governado de detecção, investigação, recomendação, aprovação e recuperação verificada. O resultado demonstra valor não apenas por restabelecer o pod, mas por correlacionar evidências, manter a decisão explicável e executar a remediação dentro dos limites de acesso definidos. Três observações se destacam do exercício. A primeira é que a transparência por chamada de ferramenta, com o comando literal e sua classificação de risco, transforma a revisão humana em auditoria rápida em vez de repetição do trabalho. A segunda é que o agente verificou a recuperação antes de concluir, distinguindo execução bem-sucedida de serviço restabelecido. A terceira é que ele sinalizou o risco de reversão por GitOps, armadilha que mais frequentemente converte uma correção em incidente recorrente. A conclusão arquitetural permanece: a observabilidade continua sendo a base. O agente amplifica o valor de uma telemetria bem construída, e amplifica igualmente as lacunas de uma telemetria pobre. Investir em sinais corretos, como working set em vez de uso bruto, agregação por máximo em vez de média e retenção além do ciclo de vida do contêiner, é pré-requisito, não consequência. Na Parte 2, o fluxo evoluirá do acionamento assistido para o disparo automatizado por alertas, com planos de resposta, definição de modos de execução por plano, hooks de auditoria e integração com o processo de gestão de incidentes. 16. Referências Azure SRE Agent Documentação do Azure SRE Agent Run Modes in Azure SRE Agent Agent Hooks in Azure SRE Agent Tutorial: Configure Agent Hooks Model Provider Selection in Azure SRE Agent Execute Mitigations in Azure SRE Agent Set up ServiceNow incident indexing Azure SRE Agent: preços Azure Monitor e observabilidade de contêineres Azure Monitor overview Overview of Azure Monitor alerts Container insights overview Consultas de exemplo para KubePodInventory Azure Monitor managed service for Prometheus Kubernetes e AKS Configure Quality of Service for Pods Node-pressure Eviction Resource Management for Pods and Containers Access and identity options for AKS AKS Store Demo: code sampleSome Questions About `log_send_rate`, `log_send_queue_size`, `redo_queue_size`, and `redo_rate`.
Hello, I've recently been trying to monitor the latency of the Available Group. Regarding logsend latency and redo latency, I hope to monitor them using the `log_send_queue_size` / `log_send_rate` and `redo_queue_size` / `redo_rate` metrics in the `dm_hadr_database_replica_states` DMV. However, in the process, I noticed that even in busy systems, `log_send_queue_size` and `log_send_rate` are often 0, whereas in idle systems, `redo_rate` is never 0. Could you please explain the specific definitions of `log_send_rate` and `redo_rate`? Why is `redo_rate` not zero when no data synchronization is taking place? In a system where data synchronization is occurring, `log_send_rate` and `log_send_queue_size` may be zero. My understanding is that log sends occur very quickly, while the monitoring granularity is not fine-grained enough—is that correct? Hope someone from the community comment on this.
Bulk-configure diagnostic settings on Azure Logic Apps Consumptions
Bulk-configure diagnostic settings on Azure Logic Apps — without clicking through the Portal LA-BulkDiag is a small, single-file PowerShell script that does the whole job in one guided run. It enumerates every Consumption Logic App in a resource group, shows you which ones already have settings, lets you pick a scope (every bare LA / every LA / a hand-picked subset), and creates the diagnostic setting on each. It auto-renames on collision so re-running is safe, and it ships with 129 Pester tests covering helpers, parameter binding, and end-to-end flows with a mocked az . Source + full docs: GitHub - dengyanbo/LA-BulkDiag: Bulk diagnostics configuration for Azure Logic Apps What it gives you A numbered, color-coded table of every Consumption LA in the RG and its current diagnostic-setting state (bare / has N / list failed). A single scope prompt — bare / all / pick / cancel — so the common cases are one keystroke. Selection grammar for the picker / -Selection : 1,3-5,8 , bare , all , none . Auto-rename on name collision ( la-diag → la-diag-1 → …) so the upsert behavior of Azure’s API never silently replaces an existing setting. Preflight verification of the destination workspace / storage account via az resource show before touching any Logic App. -WhatIf for a dry-run preview. Non-zero exit code if any LA failed, so it composes cleanly in CI. What it is not: it does not target Standard Logic Apps ( Microsoft.Web/sites with kind=workflowapp ) — those use a different API. It also doesn’t target Event Hub destinations. For everything else, see the “Scope and what this is NOT” section in the GitHub README. Quick start Prerequisites PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine). Azure CLI on PATH: https://aka.ms/installazurecliwindows An interactive az login against the subscription that owns the Logic Apps. Built-in Monitoring Contributor on the RG is enough. Get the script git clone https://github.com/dengyanbo/LA-BulkDiag.git cd LA-BulkDiag One-liner — fully interactive You don’t need to know the destination IDs up front; the script will ask: .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -SettingName la-diag You’ll see something like: Sub: my-sub (00000000-...) User: alice@contoso.com Destination not provided on the command line. Configure interactively: (paste the full ARM resource ID; leave blank to skip a destination) Log Analytics workspace resource ID: /subscriptions/.../workspaces/my-ws Storage account resource ID: Inspecting 3 Logic App(s) ... Logic Apps in 'my-rg': [ 1] order-processor bare (no settings) [ 2] notification-sender has 1: corp-governance [ 3] data-loader bare (no settings) How do you want to apply 'la-diag'? 1) bare -- apply to every BARE LA (recommended) 2) all -- apply to EVERY LA (may fail Azure-side on non-bare ones) 3) pick -- go into the selective picker 0) cancel Choice [1]: 1 Applying to every BARE LA. ==> order-processor Creating ... OK (Created). ==> data-loader Creating ... OK (Created). ================ Summary ================ LogicApp FinalName Status -------- --------- ------ order-processor la-diag Created data-loader la-diag Created Selected: 2 Succeeded: 2 Renamed: 0 Failed: 0 Not selected: 1 That’s the whole workflow. The commands you’ll actually use Grab the destination IDs once: $wsId = az monitor log-analytics workspace show -g ws-rg -n my-ws --query id -o tsv $saId = az storage account show -g sa-rg -n mysa --query id -o tsv 1. Apply to every bare LA — fully automated .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -SettingName la-diag -Selection bare -Selection bare skips both the scope prompt and the y/N confirm — perfect for CI. 2. Send to both a workspace and a storage account .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -StorageAccountId $saId ` -SettingName la-diag -Selection all 3. Metrics only, storage-only .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -StorageAccountId $saId -SettingName la-metrics ` -Preset metrics-only -Selection all Available presets: all (default) / logs-only / metrics-only / workflowruntime . 4. Specific Logic Apps by index — non-interactive After running once and seeing the numbered table, you can target them directly: .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection '1,3-5,8' 5. Dry-run before committing .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection all -WhatIf 6. Just inspect — list LAs + existing settings, change nothing .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName whatever -Selection none 7. Run the tests .\unit_test\Run-Tests.ps1 Auto-installs Pester 5 to CurrentUser if missing. Expected: Passed=129 Failed=0 . Selection grammar — cheat sheet Input Meaning 1 , 3 , 7 single index (1-based, matches the table) 1,3,5 multiple indices 1-5 inclusive range 1,3-5,8 mixed bare all LAs with no existing settings (recommended) all every LA (may fail on already-configured ones) none (or empty / q / cancel ) exit without changes Why the auto-rename matters Azure’s diagnostic-settings API is PUT — calling create --name la-diag on a Logic App that already has a setting named la-diag silently replaces the existing one. That’s a footgun if a colleague already set something up by hand. LA-BulkDiag refuses to overwrite. Instead, when -SettingName is already in use on a given LA, it auto-appends -1 , -2 , … until it finds a free name, and reports the actual name in the summary’s FinalName column. If you genuinely want to replace an existing setting, delete it first: az monitor diagnostic-settings delete -n <existing-name> --resource <la-id> Where to go next The GitHub repo has the full reference — parameter table, exit codes, status-value glossary, troubleshooting matrix (RBAC, MFA, throttling, category/sink conflicts), known limitations, and the full test inventory: 👉 https://github.com/dengyanbo/LA-BulkDiagLogic App Standard - When High Memory / CPU usage strikes and what to do
Introduction Monitoring your applications is essential, as it ensures that you know what's happening and you are not caught by surprise when something happens. One possible event is the performance of your application starting to decrease and processing becomes slower than usual. This may happen due to various reasons, and in this blog post, we will be discussing the High Memory and CPU usage and why it affects your Logic App. We will also observe some possibilities that we've seen that have been deemed as the root cause for some customers. How High Memory and high CPU affects the processing When the instructions and information are loaded into Memory, they will occupy a space that cannot be used for other sets of instructions. The more memory is occupied, the more the Operative System will need to "think" to find the correct set of instructions and retrieve/write the information. So if the OS needs more time to find or write your instructions, the less time it will spend actually doing the processing. Same thing for the CPU. If the CPU load is higher, it will slow down everything, because the available workers are not able to "think" multiple items at the same time. This translates into the Logic App processing, by the overall slowness of performance. When the CPU or Memory reach a certain threshold, we start to see the run durations going up and internal retries increasing as well. This is because the runtime workers are busy and the tasks have timeout limits. For example, let's think of a simple run with a Read Blob built-in connector action, where the Blob is very large (let's say 400MB). The flow goes: Request Trigger -> Read blob -> send email The trigger has a very short duration and doesn't carry much overhead, because we're not loading much data on it. The Read Blob though, will try to read the payload into Memory (because we're using a Built-in Connector, and these load all the information into Memory). Built-in connector overview - Azure Logic Apps | Microsoft Learn So, not considering background processes, Kudu and maintenance jobs, we've loaded 400MB into memory. Using a WS1 plan, we have 3.5GB available. By just having a blank Logic App, you will see some memory occupied, although it may vary. So, if we think it takes 500MB for the base runtime and some processes, it leaves us with 3GB available. If we load 4 files at the same time, we will be using ~1.8GB (files + base usage). Already using about 50% of the memory. And this is just for one workflow and 4 runs. Of course the memory is released after the run completes, but if you think on a broader scale, with multiple runs and multiple actions at the same time, you see how easy it is to reach the thresholds. When we see memory over ~70%, the background tasks may behave in unexpected ways, so it's essential to have a clear idea on how your Logic App is working and what data you're loading into it. Same thing for CPU. The more you load into it, the slower it gets. You may have low memory usage, but if you're doing highly complex tasks such as XML transformations or some other built-in data transforms, your CPU will be heavily used. And the bigger the file and the more complex the transformation, the more CPU will be used. How to check memory/CPU Correctly monitoring your resources usage is vital and can avoid serious impact. To help your Standard logic app workflows run with high availability and performance, the Logic App Product Group has created the Health Check feature. This feature is still in Preview, but it's already a very big assistance in monitoring. You can read more about it, in the following article, written by our PG members, Rohitha Hewawasam and Kent Weare: Monitoring Azure Logic Apps (Standard) Health using Metrics And also the official documentation for this feature: Monitor Standard workflows with Health Check - Azure Logic Apps | Microsoft Learn The Metrics can also assist in providing a better view on the current usage. Logic App Metrics don't drill down on CPU usage, because those metrics are not available at App level, but rather at App Service Plan level. You will be able to see the working memory set and Workflow related metrics. Example metric: Private Bytes (AVG) - Logic App metrics On the AppService Plan overview, you will be able to see some charts with these metrics. It's an entry point to understand what is currently going on with your ASP and the current health status. Example: ASP Dashboard In the Metrics tab, you are able to create your own charts with a much greater granularity and also save as Dashboards. You're also able to create Alerts on these metrics, which greatly increases your ability to effectively monitor and act on abnormal situations, such as High Memory usage for prolonged periods of time. Example: Memory Percentage (Max) - ASP Metrics Currently there are multiple solutions provided to analyze your Logic App behavior and metrics, such as Dashboards and Azure Monitor Logs. I highly recommend reading these two articles from our PG that discuss these topics and explain and exemplify this: Logic Apps Standard Monitoring Dashboards | Microsoft Community Hub Monitoring Azure Logic Apps (Standard) with Azure Monitor Logs How to mitigate - a few possibilities Platform settings on 32 bits If your Logic App was created long back, it may be running on an old setting. Early Logic Apps were created with 32 bits, which severely limited the Memory usage scalability, as this architecture only allows a maximum of 3GB of usage. This comes from the Operative System limitations and memory allocation architecture. After some time, the standard was to create Logic Apps in 64 bits, which allowed the Logic App to scale and fully use the maximum allowed memory in all ASP tiers (up to 14GB in WS3). This can be checked and updated in the Configuration tab, under Platform settings. Orphaned runs It is possible that some runs do not finish due to various possibilities. Either they are long running or have failed due to unexpected exceptions, runs that linger in the system will cause an increase in memory usage, because the information will not be unloaded from Memory. When the runs become orphaned, they may not be spotted but they will remain "eating up" resources. The easiest way to find these runs, is to check the workflows and under the "Running" status, check which ones are still running well after the expected termination. You can filter the Run History by Status and use this to find all the runs that are still in "Running". In my example, I had multiple runs that had started hours before, but were not yet finished. Although this is a good example, it requires you to check each workflow manually. You can also do this by using Log Analytics and execute a query to return all the Runs that are not yet finished. You need to activate the Diagnostic Settings, as mentioned in this blog post: Monitoring Azure Logic Apps (Standard) with Azure Monitor Logs To make your troubleshooting easier, I've created a query that does this for you. It will check only for the Runs and return those that do not have a matching Completed status. The OperationName field will register the Start, Dispatch and Completed status. By eliminating the Dispatched status, we're left with Start and Completed. Therefore, this query should return all the RunIDs that have a Start but not a matching Completed status, as it groups them by counting the RunIDs. LogicAppWorkflowRuntime | where OperationName contains "WorkflowRun" and OperationName != 'WorkflowRunDispatched' | project RunId, WorkflowName, TimeGenerated,OperationName, Status, StartTime,EndTime | summarize Runs = count() by RunId, WorkflowName, StartTime | where Runs == 1 | project RunId, WorkflowName, StartTime Large payloads As previously discussed, large payloads can create a big overload and increase greatly the memory usage. This applies not only to the Built-in Connectors, but also to the Managed connectors, as the information stills needs to be processed. Although the data is not loaded into the ASP memory when it comes to Managed connectors, there is a lot of data flowing and being processed in CPU time. A Logic App is capable of processing a big amount of data, but when you combine large payloads, a very large number of concurrent runs, along with large number of actions and Incoming/Outgoing requests, you get a mixture that if left unattended and continues to scale up, will cause performance issues over time. Usage of built-in connectors The Built-in Connectors (or In App) are natively run in the Azure Logic Apps runtime. Due to this, the performance, capabilities and pricing are better, in most cases. Because they are running under the Logic App Runtime, all the data will be loaded in-memory. This requires you to do a good planning of your architecture and forecast for high levels of usage and heavy payload. As previously shown, using Built-in connectors that handle very large payloads, can cause unexpected errors such as Out of Memory exceptions. The connector will try to load the payload into memory, but if starts to load and the memory is no longer available, it can crash the worker and return an Out Of Memory exception. This will be visible in the Runtime logs and it may also lead to the run becoming orphaned, as it get stuck in a state that is not recoverable. Internally, the Runtime will attempt to gracefully retry these failed tasks, and it will retry multiple times. But there is always the possibility that the state is not recoverable and thus the worker crashes. This makes it also necessary to closely monitor and plan for high usage scenarios, in order to properly scale Up and Out your App Service Plans. Learnings Monitoring can be achieved as well through the Log Stream, which requires you to configure a Log Analytics connection, but can provide a great deal of insight of what the Runtime is doing. It can give you Verbose level or simply Warning/Error levels. It does provide a lot of information and can be a bit tricky to read, but the level of detail it provides, can be a huge assistance in troubleshooting from your side and from the Support side. For this, you can navigate to your Log Stream tab, enable it, change to "Filesystem Logs" and enjoy the show. If an Out of Memory exception is caught, it will show up in red letters (as other exceptions show), and will be something similar to this: Job dispatching error: operationName='JobDispatchingWorker.Run', jobPartition='', jobId='', message='The job dispatching worker finished with unexpected exception.', exception='System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. at System.Threading.Thread.StartCore() at System.Threading.Thread.Start(Boolean captureContext) at System.Threading.Thread.Start() No PROD Logic App should be left without monitoring and alerting. Being a critical system or not, you should always plan not only for disaster scenarios but also for higher than usual volumes, because nothing is static and there's always the possibility that the system that today has a low usage, will be scaled and will be used in some way that it was not intended to. For this, implementing the monitoring on the resources metrics is very valuable and can detect issues before they get overwhelming and cause a show stopper scenario. You can use the Metrics from the Logic App that are provided out of the box, or the metrics in the ASP. These last metrics will cover a wider range of signals, as it's not as specific as the ones from the Logic App. You can also create custom Alerts from the Metrics and thus increasing your coverage on distress signals from the Logic App processing. Leaving your Logic App without proper monitoring will likely catch you, your system administrators and your business by surprise when the processing falls out of the standard parameters and chaos starts to arise. There is one key insight that must be applied whenever possible: expect the best, prepare for the worst. Always plan ahead, monitor the current status and think proactively and not just reactively. Disclaimer: The base memory and CPU values are specific for your app, and it can vary based on number of apps in App Service Plan, the number of instances you have as Always Running, etc, and number of workflows in the app, and how complex these workflows are and what internal jobs needs to be provisioned.
OpenTelemetry in Azure Logic Apps (Standard and Hybrid)
Why OpenTelemetry? As modern applications become more distributed and complex, robust observability is no longer optional—it is essential. Organizations need a consistent way to understand how workflows are performing, trace failures, and optimize end-to-end execution. OpenTelemetry provides a unified, vendor-agnostic framework for collecting telemetry data—logs, metrics, and traces—across different services and infrastructure layers. It simplifies monitoring and makes it easier to integrate with a variety of observability backends such as Azure Monitor, Grafana Tempo, Jaeger, and others. For Logic Apps—especially when deployed in hybrid or on-premises scenarios—OpenTelemetry is a powerful addition that elevates diagnostic capabilities beyond the default Application Insights telemetry. What is OpenTelemetry? OpenTelemetry (OTel) is an open-source observability framework under the Cloud Native Computing Foundation (CNCF) that provides a unified standard for generating, collecting, and exporting telemetry data such as logs, metrics, and traces. By abstracting away vendor-specific instrumentation and enabling interoperability across various tools and platforms, OpenTelemetry empowers developers and operators to gain deep visibility into distributed systems—regardless of the underlying infrastructure or language stack. In the context of Azure Logic Apps, OpenTelemetry support enables standardized, traceable telemetry that can integrate seamlessly with a wide range of observability solutions. This helps teams monitor, troubleshoot, and optimize workflows with more precision and flexibility. How to Configure from Visual Studio Code? To configure OpenTelemetry for a Logic App (Standard) project from Visual Studio Code: Locate the host.json file in the root of your Logic App project. Enable OpenTelemetry by adding "telemetryMode": "OpenTelemetry" at the root level of the file. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } Define the following application settings in local.settings.json or within your CI/CD deployment pipeline: OTEL_EXPORTER_OTLP_ENDPOINT: The OTLP exporter endpoint URL where the telemetry data should be sent. OTEL_EXPORTER_OTLP_HEADERS (optional): A list of headers to apply to all outgoing data. This is commonly used to pass authentication keys or tokens to your observability backend. If your endpoint requires additional OpenTelemetry-related settings, include those in the application settings as well. Refer to the official OTLP Exporter Configuration documentation for details. How to Configure OpenTelemetry from Azure Portal? – Standard Logic Apps To enable OpenTelemetry support for a Standard Logic App hosted using either a Workflow Standard Plan or App Service Environment v3, follow the steps below: 1. Update the host.json File In the Azure portal, navigate to your Standard Logic App resource. In the left-hand menu, under Development Tools, select Advanced Tools > Go. This opens the Kudu console. In Kudu, from the Debug Console menu, select CMD, and navigate to: site > wwwroot Locate and open the host.json file in a text editor. Add the following configuration at the root level of the file to enable OpenTelemetry, then save and close the editor. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } 2. Configure App Settings for Telemetry Export Still within your Logic App resource, go to Settings > Environment Variables and select App settings. Add the following key-value pairs: App Setting Description OTEL_EXPORTER_OTLP_ENDPOINT The OTLP (OpenTelemetry Protocol) endpoint URL where telemetry data will be exported. For example: https://otel.your-observability-platform.com OTEL_EXPORTER_OTLP_HEADERS (Optional) Any custom headers required by your telemetry backend, such as an Authorization token (e.g., Authorization=Bearer <key>). Select Apply to save the configuration. How to Configure OpenTelemetry from Azure Portal? – Hybrid Logic Apps To enable OpenTelemetry support for a Standard Logic App using the Hybrid hosting option, follow the steps below. This configuration enables telemetry collection and export from an on-premises deployment, using environment variables and local file system access. 1. Modify host.json on the SMB Share On your on-premises file share (SMB), navigate to the root directory of your Logic App project. Locate the host.json file. Add the following configuration to enable OpenTelemetry and save the file. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } 2. Configure Environment Variables in Azure Portal Go to the Azure Portal and navigate to your Standard Logic App (Hybrid) resource. From the left-hand menu, select Settings > Containers, then click on Edit and deploy. In the Edit a container pane, select Environment variables, and then click Add to define the following: Name Source Value Description OTEL_EXPORTER_OTLP_ENDPOINT Manual <OTLP-endpoint-URL> The OTLP exporter endpoint URL where telemetry should be sent. Example: https://otel.yourbackend.com OTEL_EXPORTER_OTLP_HEADERS (Optional) Manual <OTLP-headers> Custom headers (e.g., Authorization=Bearer <token>) required by your observability backend. Once you've added all necessary settings, click Save. Example of Endpoint Configuration & How to Check Logs To export telemetry data using OpenTelemetry, configure the following environment variables in your Logic App’s application settings or container environment: Name Source Value Description OTEL_EXPORTER_OTLP_ENDPOINT Manual Entry https://otel.kloudmate.com:4318 The OTLP receiver endpoint for your observability backend. OTEL_EXPORTER_OTLP_HEADERS Manual Entry Authorization=<your-api-key> Used to authenticate requests to the telemetry backend. OTEL_EXPORTER_OTLP_PROTOCOL Manual Entry http/protobuf Protocol used for exporting telemetry (KloudMate supports gRPC/HTTP). In this example, we are using KloudMate as the destination for telemetry data. Once correctly configured, your Logic App will begin exporting telemetry data to KloudMate as shown below: Limitations and Troubleshooting Steps Current Limitations Supported trigger types for OpenTelemetry in Logic Apps are: HTTP Service Bus Event Hub Exporting metrics is not currently supported. Troubleshooting Steps No traces received: Validate OTEL_EXPORTER_OTLP_ENDPOINT URL and port availability. Ensure outbound traffic to observability backend is permitted. Authentication issues: Review and correct header values in OTEL_EXPORTER_OTLP_HEADERS. References Set up and view enhanced telemetry for Standard workflows - Azure Logic Apps | Microsoft Learn💡Integration Environment Update – Unified experience to create and manage alerts
We’re excited to announce the next milestone in our journey to simplify monitoring across Azure Integration Services. As a follow-up to our earlier preview release on unified monitoring and dashboards, we’re now making it easier than ever to configure alerts for your integration applications. This update introduces a consistent, application-centric alerting experience across Logic Apps, Service Bus, and API Management (APIM)—all available directly within the Integration Environment. What’s New With this release, you can now: Create alerts effortlessly using a simplified, unified interface Monitor your application’s health based on fired alerts Troubleshoot quickly using integrated dashboards and alert insights Track messages across services from a single, consolidated view Together with the earlier update that introduced dashboards and runtime telemetry, this completes the core loop: observe, get notified, and act—all from one place. Powered by Azure Monitor The entire experience is built on Azure Monitor, giving you: A streamlined UI tailored for integration scenarios Consistency with Azure-wide alerting practices The ability to reuse existing action groups, alert rules, and automation Access to advanced configurations for users who need more control Whether you’re new to Azure Integration Services or already managing complex enterprise apps, this means less friction and more flexibility. Unified Monitoring Experience in Action Here’s how it all comes together in the Integration Environment: Set up alert-based workflows to notify, escalate, or auto-remediate incidents View application-level alerts in one place Use dashboards to correlate issues across Logic Apps, APIM, and Service Bus Rely on familiar Azure Monitor constructs, so there's no need to start from scratch This holistic view turns Integration Environment into the control plane for managing health and performance of your event-driven and API-based applications. With this update, you can detect issues faster, respond proactively to integration failures, reduce operational overhead, and scale your monitoring using familiar Azure tooling. Get Started This update is now available in your Integration Environment in the Azure Portal. To get Started, follow the steps to configure Integration Environment and Application. Then you are ready to configure alerts for the resources in your application. Here are some key steps In the chosen application, navigate to Alerts page. Via edit, open the page to alert rules. You can do this for the parent resource, or expand them to select a child resource like workflow in case of Logic Apps, or API in case of API Management, queues in case of Service Bus. To get started, we provide you an option to start with recommended rules or you can choose Add rule as well. The recommended rules is a really easy way to configure alerts in one go for a resource. We also recommend default thresholds which you can choose as is or update them. Remove a rule from the list if not needed. When you Save, we use Azure monitor APIs to create a rule per row. After Save, you will see the link to rule if you want to make any updates beyond what’s show in the UI. The recipients for the Alerts can be configured in action group tabs, based on the alert severity. Through Add rule, you can also choose to create alert rules for signals beyond the recommended ones. This is another example of recommended rules for Service Bus queues The alerts page also shows the alert activity to get a clear visual on the health of the application and different resources in it. You can see the count of alerts by severity allowing you to focus and triage the more critical issues. At this point, you know what resources in the application need further troubleshooting. This is where the monitoring dashboards in Integration Environment help you get a metrics and log based views into the details of the health of each resource to do the root cause analysis and mitigate the issues and alerts. We’d Love Your Feedback We understand how critical observability and monitoring are to running reliable integration solutions. Our goal is to provide the best end-to-end monitoring experience for Azure Integration Services—and to do that, we need your input. Whether you're just getting started or managing enterprise-grade integrations, your feedback helps us improve the tools and features that matter most. 👉 Have ideas, suggestions, or gaps you’d like us to address? Reply to this blog post or submit your feedback —we're listening. Let’s build the future of Integration monitoring, together.
Intune PKCS Certificate not showing in Monitor > Certificates
When working with Intune to deploy PKCS Certificates from an On Prem Enterprise CA, we are not seeing the certificates issued to iOS/iPadOS devices within the Certificate Report. Windows issued certificates are showing fine however. We can confirm that the Certificate profile shows successful and the device actually has a certificate under Settings > General > VPN and Device Management > Management Profile > More Details. Is there something that I missed to be able to see the issued certs in monitor or is there something wrong with the reporting. Of note, we also see the iOS/iPadOS certificates in the succeeded folder on the certificate connector but no the Windows ones. Event Viewer also shows that the certificate was successfully issued and sent to Intune.
