Microsoft AZ-400: Monitoramento, Observabilidade e Feedback — Guia de estudos

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Faz parte do Microsoft DevOps Engineer Expert AZ-400 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Equipes de DevOps modernas tratam monitoramento, observabilidade e feedback como um ciclo contínuo que informa as decisões de engenharia, operações e produto. No Azure, a telemetria flui das aplicações e da infraestrutura para o Azure Monitor e o Log Analytics, onde é consultada, correlacionada e visualizada. O rastreamento distribuído conecta os serviços em transações de ponta a ponta, enquanto os alertas e as integrações com o plantão impulsionam a remediação rápida. Dashboards do Azure DevOps, análise de itens de trabalho e experimentação fecham o ciclo, retroalimentando o planejamento e a entrega com insights. Esta seção fornece a profundidade necessária para projetar uma pilha de observabilidade integrada que entrega feedback acionável em todas as etapas.

Telemetria, Rastreamento e Azure Monitor

O Application Insights é o componente de monitoramento de desempenho de aplicações (APM) do Azure Monitor. A instrumentação é adicionada via:

SDKs e instrumentação automática: .NET/.NET Core, Java, JavaScript, Node.js, Python e o Application Insights Agent para .NET e Java. Use uma string de conexão e defina cloud_RoleName para distinguir os componentes.
Inicializadores e processadores de telemetria: Adicione ou modifique propriedades (ex: tenantId) e filtre PII (Informações de Identificação Pessoal) antes da emissão.
Telemetria personalizada: TrackEvent para ações de negócio, TrackMetric para KPIs numéricos, TrackException para contextos de erro e TrackDependency para chamadas externas que você precisa modelar explicitamente.

Os tipos de telemetria incluem requisições, dependências (HTTP, SQL, SDKs do Azure), rastreamentos, exceções, visualizações de página, desempenho de carregamento de página, resultados de testes de disponibilidade, eventos/métricas personalizados e métricas em tempo real. A amostragem controla o volume e o custo, preservando o sinal: a amostragem adaptativa do SDK ajusta automaticamente as taxas por tipo para manter a taxa de transferência (throughput) e a correlação desejadas; a amostragem de taxa fixa fornece amostragem determinística para conformidade. Prefira a amostragem do lado do SDK para que os sistemas downstream nunca processem itens descartados. Mantenha a amostragem persistente (sticky sampling) para a integridade do rastreamento de ponta a ponta.

O rastreamento distribuído fornece visibilidade de transações de ponta a ponta. O Application Insights implementa o padrão W3C Trace-Context (traceparent/tracestate), propagando automaticamente os IDs de correlação através de HTTP; propague o contexto através de limites assíncronos e protocolos personalizados para evitar rastreamentos quebrados. O rastreamento de dependências coleta automaticamente chamadas de saída comuns; emita dependências personalizadas para saltos em filas de mensagens ou RPCs não padrão para completar o gráfico de chamadas. O App Map e o Transaction Search visualizam fluxos entre serviços, latências e pontos críticos de falha. Para a correlação do front-end com o back-end, habilite o SDK de JavaScript e garanta que os cabeçalhos de correlação do lado do servidor sejam aceitos para medir os tempos reais de carregamento da página e as jornadas do usuário.

O Azure Monitor unifica a telemetria da plataforma e da aplicação:

Métricas: Multidimensionais, quase em tempo real (granularidade de um minuto ou melhor). Use alertas de métrica com limiares estáticos ou dinâmicos para detecções rápidas e de baixa latência.
Logs: Telemetria semiestruturada em um workspace do Log Analytics, consultada com KQL para análise profunda e busca por anomalias.
Alertas: Regras de métrica, log e log de atividades são roteadas para grupos de ações. Use limiares dinâmicos, direcionamento para múltiplos recursos e o esquema de alerta comum para um tratamento consistente.
Grupos de ações: E-mail/SMS/voz, notificações push, webhooks (incluindo PagerDuty/OpsGenie), conectores ITSM, Logic Apps, Azure Functions e runbooks do Automation para remediação.
Configurações de diagnóstico: Configure cada recurso do Azure para transmitir métricas/logs da plataforma para o Log Analytics, Azure Storage (para arquivamento) e Event Hubs (para ingestão em SIEM). Garanta a consistência com uma implantação orientada por políticas.

Consultas e Análise com Log Analytics (KQL)

Um workspace do Log Analytics é o limite de consulta e governança para logs. Planeje por ambiente e soberania de dados: workspaces separados para produção vs. não produção podem simplificar o RBAC e as políticas de retenção; a centralização facilita a correlação entre serviços. As fontes de dados incluem o Azure Diagnostics (logs/métricas da plataforma), agentes de VM (Syslog/eventos do Windows, contadores de desempenho), Container Insights/AKS, logs de componentes do Application Insights (unificados sob os Logs do Azure Monitor), logins do Azure AD, logs personalizados via APIs de ingestão e Regras de Coleta de Dados para roteamento e transformação precisos do fluxo.

A Kusto Query Language (KQL) é otimizada para análise de séries temporais e telemetria:

Operadores principais: where (filtrar), project (selecionar), extend (derivar), summarize by (agregar), join/union (correlar), parse/parse_json (extrair), mv-expand (arrays), make-series e bin para agrupamento por tempo, render para criação de gráficos.
Padrões: Consumo do orçamento de erro (taxas de falha ponderadas pelo tempo), distribuições de latência p50/p95, detecção de outliers de dependência, taxa de sucesso de requisições vs. tráfego e detecção de anomalias usando series_decompose_anomalies para alertas cientes da sazonalidade.
Governança: Consultas e funções salvas promovem o reuso; o RBAC e o acesso em nível de tabela restringem conjuntos de dados sensíveis.
Entre recursos e entre workspaces: Use workspace("workspaceNameOrId").Table e a função workspaces() para combinar conjuntos de dados entre ambientes e assinaturas; use resource() para joins entre recursos. Aplique associações com let e materialize() para controlar o desempenho em joins grandes.

Visualização e Feedback Ágil no Azure DevOps

Os dashboards no Azure DevOps comunicam tanto a saúde operacional quanto a do processo. Dashboards de nível de equipe focam no backlog, iterações e WIP da equipe; dashboards de nível de projeto apresentam visões entre equipes e de portfólio. Os widgets incluem Sprint Burndown, Burnup, Velocity, Cumulative Flow Diagram (CFD), Cycle Time, Lead Time, Gráfico de Itens de Trabalho/Resultados de Consulta, resumos de Build/Release e Markdown para runbooks e status de SLO. Proteja os widgets com permissões de dashboard e restrinja o escopo das consultas a equipes/áreas para evitar o vazamento de informações entre equipes.

Consultas do Boards (através do construtor de consultas ou WIQL) alimentam muitos widgets. Parametrize as consultas por caminho de área/iteração da equipe para reutilização; prefira widgets baseados no Analytics quando disponíveis para maior precisão e desempenho. Métricas de fluxo chave:

Cycle time: Tempo decorrido de Ativo (em andamento) para Concluído; use o widget Cycle Time para acompanhar a eficiência da execução.
Lead time: Tempo decorrido da criação/comprometimento até a conclusão; sinaliza o atraso total do sistema conforme percebido pelos clientes.
Throughput: Itens concluídos por intervalo de tempo; compare com as políticas de WIP para detectar gargalos.
Cumulative Flow Diagram: Visualiza o tamanho das filas por estado ao longo do tempo; faixas que se alargam expõem restrições e troca de contexto. Para o acompanhamento de sprints, use o Burndown (tendência do trabalho restante em direção a zero) e o Burnup (escopo total vs. concluído, resiliente a mudanças de escopo). O Velocity informa a média de esforço concluído por sprint e orienta o planejamento de capacidade; agregue apenas unidades de estimativa semelhantes entre as equipes.

Onde a análise de produto for necessária, conecte o Azure DevOps Analytics ao Power BI para combinar métricas de entrega com telemetria operacional (por exemplo, lead time vs. taxa de escape de defeitos) para priorizar melhorias.

Confiabilidade, Alertas e Feedback Contínuo

SLI/SLO/SLA estabelecem a confiabilidade como uma feature de primeira classe:

SLIs: Medidas quantitativas da experiência do usuário, ex: taxa de sucesso de requisições, latência p95, disponibilidade de endpoints críticos ou taxa de conclusão de tarefas na UI.
SLOs: Metas ao longo de uma janela de tempo, ex: 99,9% de disponibilidade mensal ou p95 < 300 ms. Vincule os SLOs às jornadas do usuário, não à infraestrutura.
Orçamentos de erro (Error budgets): 1 − SLO; governam o risco de lançamento, os critérios de rollback e a resposta a incidentes. Implemente alertas de taxa de consumo (burn-rate) do orçamento (ex: consumo de 2x e 14x) usando KQL ou alertas de métrica para violações rápidas e lentas.
SLAs: Compromissos externos com os clientes; tipicamente mais flexíveis que os SLOs e incluem penalidades; orientam, mas não ditam, as diretrizes de engenharia (guardrails).

Alertas e plantão (on-call):

Use alertas de métrica para condições sensíveis à latência; use alertas de log para predicados complexos (ex: correlação de múltiplos sinais ou pontuações de anomalia).
Reduza a fadiga de alertas com desduplicação (regras de processamento de alertas), limiares dinâmicos, ajuste de severidade e supressão automática durante manutenções planejadas.
Integre com PagerDuty/OpsGenie via webhooks de grupos de ações usando o esquema de alerta comum; mapeie as chaves de correlação de alertas para desduplicação de incidentes e defina políticas de escalonamento por serviço.
Automatize a remediação com runbooks do Azure Automation, Functions ou Logic Apps (ex: escalar horizontalmente (scale-out) com base na profundidade da fila, reciclar uma instância com falha, alternar uma feature flag). Registre cada ação automática como um evento personalizado no Application Insights para fins de auditoria.

Feedback contínuo e experimentação:

Testes A/B e implantações graduais (rollouts): Use o Azure Front Door ou o Traffic Manager para divisão de tráfego na borda (edge), ou implemente feature flags com o Azure App Configuration Feature Manager para implantação por usuário ou baseada em coorte. Proteja os caminhos do código com flags e colete a telemetria de eventos por variante.
Telemetria do usuário: Emita um

undefined

com o estado da feature flag, propriedades do usuário (sem PII) e identificadores de cenário. Analise funis, fluxos de usuário, retenção e desempenho de coortes no Application Insights para validar hipóteses.

Análise de uso de features: Crie dashboards que monitoram DAU/WAU/MAU, adoção de features e métricas de conversão. Use os resultados para priorizar o backlog. Use gates do Azure Pipelines para bloquear o deployment em produção quando as baselines de SLI em staging falharem ou regressões de KPI do experimento forem detectadas.

Cenário de Problema Prático

O Spotify precisa melhorar a visibilidade de ponta a ponta e o feedback para seus serviços de ingestão e reprodução de podcasts implantados no Azure Kubernetes Service (AKS) e em APIs do Azure App Service. Os incidentes são detectados tardiamente, e as equipes de produto não têm métricas confiáveis de adoção para novas features de reprodução.

Instrumentar e correlacionar a telemetria da aplicação

Adicione os SDKs do Application Insights aos serviços .NET e Node.js; habilite o SDK JavaScript do Application Insights nos clientes web. Configure cloud_RoleName e as connection strings; habilite a propagação do trace-context do W3C entre microsserviços e filas de mensagens. Por quê: Garante IDs de correlação consistentes e rastreamento distribuído para visibilidade completa da transação, do navegador aos serviços e dependências.

Transmitir diagnósticos da plataforma para o Log Analytics

Aplique as configurações de diagnóstico via Azure Policy a todos os clusters AKS, planos do App Service, Application Gateways, Cosmos DB e contas de Storage, roteando para um workspace central de produção com retenção de 90 dias e arquivamento no Storage. Por quê: Garante cobertura uniforme de logs/métricas da plataforma para correlação com KQL e retenção de longo prazo com custo-benefício.

Definir SLIs, SLOs e orçamentos de erro

SLIs: latência p95 da API, taxa de sucesso de requisições, throughput do pipeline de ingestão e sucesso no início do player.
SLOs: 99,95% de sucesso mensal, início da reprodução p95 < 300 ms, atraso na ingestão < 2 minutos.
Crie alertas de taxa de consumo (burn-rate) do orçamento de erro baseados em KQL (rápidos/lentos) e alertas de métrica para latência com limiares dinâmicos. Por quê: Converte resultados de negócio em metas de confiabilidade mensuráveis e acionáveis com alertas oportunos.

Criar alertas acionáveis e integração de plantão (on-call)

Crie regras de alerta no Azure Monitor com agrupamento inteligente (smart grouping); roteie para um grupo de ações que aciona o PagerDuty via webhook usando o esquema de alerta comum. Anexe runbooks do Azure Automation para escalar automaticamente com base na profundidade da fila e reiniciar pods não íntegros (unhealthy). Por quê: Reduz o MTTA/MTTR por meio de um sistema de paginação (paging) confiável e remediação automática segura e auditável.

Estabelecer dashboards para engenharia e produto

Dashboards de nível de equipe no Azure DevOps: Cycle Time (Ativo→Concluído), Lead Time (Criado→Concluído), CFD, Velocity e Sprint Burndown para os squads. Dashboards de nível de projeto: Burnup para releases, throughput entre equipes e status de SLOs via widgets de Markdown/Analytics. Por quê: Oferece aos squads insights sobre a execução, ao mesmo tempo que fornece à liderança a saúde do portfólio e da confiabilidade.

Implementar experimentação e análise de uso

Use as feature flags do Azure App Configuration para implantar gradualmente uma nova feature “Smart Skip Silence”. Divida as coortes com regras do Front Door para testes A/B na borda, quando necessário. Emita um

undefined

com featureFlagState, coorte do usuário e métricas de resultado. Por quê: Valida o impacto com segurança enquanto captura telemetria de usuário de alta fidelidade para decisões baseadas em evidências.

Garantir a qualidade da release com gates

No Azure Pipelines, adicione gates que consultam o Application Insights/Log Analytics para obter KPIs de staging (latência p95, taxa de falha, desempenho da variante do experimento). Faça os gates falharem se as baselines ou os limiares alinhados ao SLO não forem atendidos. Por quê: Impede que regressões cheguem à produção e alinha as decisões de deployment com os KPIs de confiabilidade e de produto.

← Estratégia de Testes e Engenharia de Qualidade · Todos os domínios · Gerenciamento de Pacotes e Gerenciamento de Artefatos →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →