Project Flash - Usar a Integridade dos Recursos do Azure para monitorar a disponibilidade da Máquina Virtual do Azure

Artigo
02/21/2024

O Azure Resource Health é uma solução oferecida pelo Flash. Flash é o nome interno de um projeto dedicado à criação de um mecanismo robusto, confiável e rápido para os clientes monitorarem a integridade da máquina virtual (VM).

Este artigo aborda o uso da Integridade dos Recursos do Azure para monitorar a disponibilidade da Máquina Virtual do Azure. Para obter uma visão geral das soluções Flash, consulte a visão geral do Flash.

Para documentação específica para as outras soluções oferecidas pelo Flash, escolha um dos seguintes artigos:

Azure Resource Health

Oferece verificações de saúde imediatas e fáceis de usar para recursos individuais através do portal. Os clientes podem acessar rapidamente a folha de integridade do recurso no portal e também revisar um registro histórico de 30 dias de verificações de integridade, tornando-o uma excelente ferramenta para solução de problemas rápida e direta. O recurso existente de Integridade dos Recursos do Azure ajuda você a diagnosticar e obter suporte para problemas de serviço que afetam seus recursos do Azure. Ele informa sobre a integridade atual e passada de seus recursos, mostrando qualquer intervalo de tempo em que cada um dos seus recursos não esteja disponível.

Mas sabemos que nossos clientes e parceiros estão interessados em entender o que causa problemas técnicos subjacentes e em melhorar como eles podem receber comunicações sobre quaisquer problemas — para alimentar os processos de monitoramento, explicar soluços a outras partes interessadas e, finalmente, informar as decisões de negócios.

Causas básicas para problemas de VM no Azure Resource Health

Recentemente, enviamos uma melhoria na experiência de integridade de recursos que aprimorará as informações que compartilhamos com os clientes sobre falhas de VM e fornecerá mais contexto sobre a causa raiz que levou ao problema. Agora, além de receber uma notificação rápida quando a disponibilidade de uma VM é afetada, os clientes podem esperar que uma causa raiz seja adicionada em um ponto posterior, assim que nosso sistema automatizado de Análise de Causa Raiz (RCA) identificar o componente da plataforma Azure com falha que levou à falha da VM. Vamos dar um exemplo para ver como esse processo funciona na prática:

No momento T1, um rack de servidor fica offline devido a um problema de rede, fazendo com que as VMs no rack percam a conectividade. Melhorias recentes de confiabilidade relacionadas à arquitetura de rede serão compartilhadas em uma futura postagem no blog Advancing Reliability — assista a este espaço!

No momento T2, o monitoramento interno do Azure reconhece que não é possível alcançar VMs no rack e começa a atenuar reimplantando as VMs afetadas em um novo rack. Durante esse tempo, uma anotação é enviada para a integridade do recurso notificando os clientes de que sua VM está atualmente afetada e indisponível.

No momento T3, a telemetria da plataforma a partir do topo do switch de rack, a máquina host e os sistemas de monitoramento interno são correlacionados em nosso mecanismo RCA para derivar a causa raiz da falha. Uma vez calculado, o RCA é então publicado novamente na integridade dos recursos, juntamente com recomendações relevantes de resiliência arquitetônica que os clientes podem implementar para minimizar a probabilidade de impacto no futuro.

Embora a funcionalidade inicial de notificação de tempo de inatividade tenha vários anos, a publicação de uma declaração de causa raiz é uma nova adição. Agora, vamos mergulhar nos detalhes de como derivamos essas causas profundas.

Mecanismo de análise de causa raiz

Vamos dar uma olhada mais de perto no exemplo anterior e percorrer os detalhes de como o motor RCA funciona e a tecnologia por trás dele. No centro do nosso mecanismo RCA para VMs está o Azure Data Explorer (ADX), um serviço de big data otimizado para análises de telemetria de log de alto volume. O Azure Data Explorer permite a capacidade de analisar facilmente terabytes de telemetria de log de dispositivos e serviços que compõem a plataforma Azure, juntá-los e interpretar os fluxos de informações correlacionados para derivar uma causa raiz para diferentes cenários de falha. Isso acaba sendo um processo de engenharia de dados em várias etapas:

Fase 1: Deteção de tempo de inatividade

A primeira fase na análise de causa raiz é definir o gatilho sob o qual a análise é executada. Para Máquinas Virtuais, queremos determinar as causas raiz sempre que uma VM é reinicializada inesperadamente, portanto, o gatilho é uma VM em transição de um estado ascendente para um estado inativo. Identificar essas transições da telemetria de plataforma é simples na maioria dos cenários, mas mais complicado em torno de certos tipos de falha de infraestrutura, onde a telemetria de plataforma pode se perder devido a falha de dispositivo ou perda de energia. Para lidar com essas classes de falhas, outras técnicas são necessárias, como rastrear a perda de dados como uma possível indicação de uma transição de disponibilidade de VM. O Azure Data Explorer se destaca neste momento de análise de série, e uma visão mais detalhada das técnicas em torno desse processo pode ser encontrada na Microsoft Tech Community: Calculando o tempo de inatividade usando funções de janela e funções de série temporal no Azure Data Explorer.

Fase 2: Análise de correlação

Uma vez definido um evento de gatilho (neste caso, uma VM em transição para um estado não íntegro), a próxima fase é a análise de correlação. Nesta etapa, usamos a presença do evento trigger para correlacionar a telemetria de pontos na plataforma Azure, como:

Host do Azure: a folha física que hospeda VMs.
TOR: a parte superior do switch de rede de rack.
Armazenamento do Azure: o serviço que hospeda Discos Virtuais para Máquinas Virtuais do Azure.

Cada um desses sistemas tem seus próprios feeds de telemetria que precisam ser analisados e correlacionados com o evento de gatilho de tempo de inatividade da VM. Esse processo é feito por meio da compreensão do gráfico de dependência de uma VM e dos sistemas subjacentes que podem fazer com que uma VM falhe e, em seguida, juntando a telemetria de integridade de todos esses sistemas dependentes, filtrada em eventos que ocorreram perto do momento da transição da VM. A linguagem de consulta intuitiva e poderosa do Azure Data Explorer ajuda oferecendo padrões documentados, como a junção de janelas de tempo, para correlacionar fluxos de telemetria temporal. No final desse processo de correlação, temos um conjunto de dados que representa as transições de tempo de inatividade da VM com a telemetria de plataforma correlacionada de todos os sistemas dependentes que podem causar ou podem ter informações úteis para determinar o que levou à falha da VM.

Fase 3: Atribuição da causa raiz

O próximo passo do processo é a atribuição. Agora que reunimos todos os dados relevantes em um único conjunto de dados, as regras de atribuição são aplicadas para interpretar as informações e traduzi-las em uma declaração de causa raiz voltada para o cliente. Se você voltar ao nosso exemplo original de uma falha de TOR, após nossa análise de correlação, podemos ter muitas informações interessantes para interpretar. Por exemplo, os sistemas que monitoram os hosts do Azure podem ter logs indicando que perderam a conectividade com os hosts durante esse período. Também podemos ter sinais relacionados a problemas de conectividade de disco virtual e sinais explícitos do dispositivo TOR sobre a falha. Todas essas informações agora são verificadas, e o sinal explícito de falha TOR é priorizado sobre os outros sinais como a causa raiz. Esse processo de priorização e as regras por trás dele são criados com especialistas em domínio e modificados à medida que a plataforma Azure evolui. O aprendizado de máquina e os mecanismos de deteção de anomalias se baseiam nessas causas raiz atribuídas, para ajudar a identificar oportunidades de melhorar essas regras de classificação e detetar mudanças de padrão na taxa dessas falhas para retroalimentar pipelines de implantação seguros.

Fase 4: Publicação RCA

A última etapa é publicar causas raiz no Azure Resource Health, onde elas se tornam visíveis para os clientes. A publicação é feita por um aplicativo simples do Azure Functions , que consulta periodicamente os dados de causa raiz processados no Azure Data Explorer e emite os resultados para o back-end de integridade do recurso. Como os fluxos de informação podem chegar com vários atrasos de dados, os RCAs podem ocasionalmente ser atualizados neste processo para refletir melhores fontes de informação que chegaram levando a uma causa raiz mais específica do que o que foi originalmente publicado.

Rumo ao futuro

Identificar e comunicar a causa raiz de quaisquer problemas aos nossos clientes e parceiros é apenas o começo. Os nossos clientes poderão ter de pegar nestes RCAs e partilhá-los com os seus clientes e colegas de trabalho. Queremos desenvolver o trabalho aqui para tornar mais fácil identificar e rastrear RCAs de recursos, e compartilhá-los facilmente. Para conseguir isso, estamos trabalhando em alterações de back-end para gerar IDs de rastreamento exclusivos por recurso e por tempo de inatividade que podemos expor a você, para que você possa facilmente combinar os tempos de inatividade com seus RCAs. Estamos também a trabalhar em novas funcionalidades para tornar mais fácil enviar RCAs por e-mail e, eventualmente, subscrever RCAs para as suas VMs. Esta funcionalidade permitirá inscrever-se nos RCAs diretamente na sua caixa de entrada após um evento de indisponibilidade, sem necessidade de qualquer ação adicional da sua parte.

Próximos passos

Para saber mais sobre as soluções oferecidas, prossiga para o artigo da solução correspondente:

Para obter uma visão geral de como monitorar máquinas virtuais do Azure, consulte Monitorar máquinas virtuais do Azure e a referência Monitorando máquinas virtuais do Azure.

Partilhar via