.
Uma implantação de código para aplicativos de contêiner do Azure que continha uma configuração incorreta desencadeou problemas prolongados de acesso a dados de log, de acordo com um relatório de incidente técnico da Microsoft.
O incidente, que começou às 23h15 UTC de 6 de julho e durou até as 09h do dia seguinte, significou que um subconjunto de dados do Azure Monitor Log Analytics e do Microsoft Sentinel “falha ao ingerir”.
Além disso, os logs de plataformas coletados por meio da Configuração de diagnóstico não encaminhavam alguns dados para “destinos do cliente”, incluindo Log Analytics Storage, Event Hub e Marketplace.
E a funcionalidade do Security Operations Center no Sentinel “incluindo consultas de busca, pastas de trabalho com consultas personalizadas e notebooks que consultaram tabelas afetadas com intervalo de dados incluindo os dados de logs que falhamos ao ingerir, podem ter retornado resultados parciais ou vazios”.
O relatório acrescenta: “Nos casos em que as tabelas de eventos ou eventos de segurança foram afetadas, as investigações de um incidente correlacionado podem ter mostrado resultados parciais ou vazios. Infelizmente, esse problema afetou um ou mais de seus recursos do Azure.”
Então, o que deu errado e por quê?
“Uma implantação de código para o serviço Azure Container Apps foi iniciada em 3 de julho de 2023 por meio das Práticas de implantação seguras (SDP) normais, primeiro implantando no canário do Azure e nas regiões de teste. Esta versão continha uma configuração incorreta que impedia o início normal do serviço. Devido devido à configuração incorreta, o código de bootstrap do serviço lançou uma exceção e foi reiniciado automaticamente.”
Isso resultou no serviço de inicialização “preso em um loop”, o que significava que estava sendo reiniciado a cada cinco a dez segundos. Sempre que o serviço era reiniciado, ele fornecia informações de configuração para os agentes de telemetria que também estão instalados nos hosts do serviço, e eles interpretavam isso como uma alteração na configuração, saindo automaticamente do processo existente e reiniciando também.
“Três instâncias separadas do host de telemetria do agente, por host de aplicativos, agora também reiniciavam a cada cinco a dez segundos”, acrescenta a Microsoft no relatório.
Em cada inicialização, o agente de telemetria se comunicava com o plano de controle para baixar a versão mais recente da configuração de telemetria – algo que normalmente só acontecia uma vez durante vários dias. No entanto, à medida que a implantação do Container App Service prosseguia, várias centenas de hosts tiveram seu agente de telemetria irritante repetidamente.
O bug na implantação foi finalmente detectado e interrompido antes de ser liberado para as regiões de produção, com a equipe do Container Apps iniciando a implantação de seu novo serviço no canário e na região de preparação para lidar com a configuração incorreta.
“No entanto, a taxa agregada de solicitações dos serviços que receberam a compilação com a configuração incorreta esgotou a capacidade no plano de controle de telemetria. O plano de controle de telemetria é um serviço global, usado por serviços em execução em todas as regiões públicas do Azure.
“Como a capacidade no plano de controle estava saturada, outros serviços envolvidos na ingestão de telemetria, como as portas frontais de ingestão e os serviços de pipeline que roteiam dados entre os serviços internamente, começaram a falhar, pois suas operações contra o plano de controle de telemetria eram rejeitadas ou expirou. O design do plano de controle de telemetria como um único ponto de falha é um risco conhecido, e o investimento para eliminar esse risco está em andamento no Azure Monitor para projetar esse risco fora do sistema.”
Portanto, o código mal configurado não foi implantado na produção, mas afetou a produção. A Micfrosoft diz que às 23h15 de 6 de julho, “o impacto do cliente externo começou, pois os dados em cache começaram a expirar”.
Fechando o mea culpa, a Microsoft disse estar ciente de que “a confiança é conquistada e deve ser mantida” e que “a retenção de dados é uma responsabilidade fundamental da nuvem da Microsoft, incluindo todos os engenheiros que trabalham em todos os serviços de nuvem”.
Para tornar esse tipo de incidente menos provável, o fornecedor diz que tentou garantir que os serviços do plano de controle de telemetria estejam sendo executados com capacidade extra e se comprometeu a criar mais alertas sobre métricas que apontam para padrões de falha incomuns em chamadas de API.
A Microsoft também disse que está adicionando novos caches positivos e negativos ao plano de controle; estabelecerá mais padrões de estrangulamento e disjuntor para APIs de plano de controle de telemetria central; e criar “isolamento” entre serviços internos e externos que usam o plano de controle de telemetria.
É bom saber o que está acontecendo dentro da máquina Azure e a Microsoft é altamente transparente nessas situações. Seria melhor se relatórios como este não fossem exigidos em primeira instância – mas podemos viver com esperança. ®
.
