Projeto Flash - Use o Azure Resource Health para monitorar a disponibilidade da Máquina Virtual do Azure

  • Artigo

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

Esse artigo aborda a utilização do Azure Resource Health para monitorizar a disponibilidade da Máquina Virtual Azure. Para obter uma visão geral das soluções Flash, veja o Visão geral do Flash.

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

Azure Resource Health

Oferece verificações de integridade imediatas e fáceis de usar para recursos individuais por meio do portal. Os clientes podem acessar rapidamente o painel integridade dos recursos no portal e também revisar um registro histórico de verificações de integridade de 30 dias, tornando-o uma excelente ferramenta para solução de problemas rápida e direta. A funcionalidade existente do Azure Resource Health ajuda-o a diagnosticar e obter suporte para problemas de serviço que afetam os seus recursos do Azure. A funcionalidade existente do Azure Resource Health ajuda-o a diagnosticar e obter suporte para problemas de serviço que afetam os seus recursos do Azure. Ele informa sobre a integridade atual e passada dos seus recursos, mostrando quaisquer intervalos de tempo em que cada um dos seus recursos esteve indisponível.

Mas sabemos que os nossos clientes e parceiros estão interessados em compreender as causas dos problemas técnicos subjacentes e em melhorar a forma como podem receber comunicações sobre quaisquer problemas—para alimentar os processos de monitorização, para explicar problemas a outras partes interessadas e, em última análise, para informar as decisões de negócios.

Causas raiz de problemas de VM no Azure Resource Health

Recentemente, lançamos uma melhoria na experiência de integridade dos 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 for afetada, os clientes podem esperar que uma causa raiz seja adicionada posteriormente, assim que nosso sistema automatizado de Análise de Causa Raiz (RCA) identificar o componente da plataforma Azure com falha que levou à VM falha. Vejamos 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 Avançando a Confiabilidade—observe esse espaço!

No momento T2, a monitorização interna do Azure reconhece que não consegue alcançar os VMs no rack e começa a mitigar, reimplantando os VMs impactados para um novo rack. Durante esse período, uma anotação é enviada para a saúde dos recursos notificando os clientes de que o seu VM está atualmente afetado e indisponível.

Captura de tela da folha de integridade do recurso do portal do Azure mostrando o histórico de integridade de um recurso.

No momento T3, a telemetria da plataforma do switch do topo do 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. Depois de computado, o RCA é publicado novamente na integridade dos recursos, juntamente com recomendações relevantes de resiliência arquitetural que os clientes podem implementar para minimizar a probabilidade de impacto no futuro.

Captura de tela da folha do histórico de integridade do portal do Azure mostrando detalhes da causa raiz para um exemplo de problema de VM.

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 novidade. Agora, vamos mergulhar nos detalhes de como derivamos essas causas raízes.

Mecanismo de análise de causa raiz

Vamos dar uma olhada no exemplo anterior e examinar os detalhes de como o mecanismo 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álise de telemetria de log de alto volume. O Azure Data Explorer permite analisar facilmente terabytes de telemetria de registo de dispositivos e serviços que compõem a plataforma Azure, juntá-los e interpretar os fluxos de informação correlacionados para derivar uma causa raiz para diferentes cenários de falha. Isso acaba sendo um processo de engenharia de dados de várias etapas:

Fase 1: Detectando tempo de inatividade

A primeira fase da análise de causa raiz é definir o gatilho sob o qual a análise é executada. Para Máquinas Virtuais do Microsoft Azure, queremos determinar as causas raiz sempre que uma VM é reinicializada inesperadamente, portanto, o gatilho é uma VM em transição de um estado ativo para um estado inativo. Identificar essas transições da telemetria da plataforma é simples na maioria dos cenários, mas é mais complicado em certos tipos de falha de infraestrutura, onde a telemetria da plataforma pode ser perdida devido a falha do dispositivo ou perda de energia. Para lidar com essas classes de falhas, outras técnicas são necessárias—como o rastreamento da perda de dados como uma possível indicação de uma transição de disponibilidade da VM. O Azure Data Explorer é excelente nesse momento de análise de série, e uma visão mais detalhada das técnicas 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

Depois que um evento acionador for definido (nesse caso, uma VM em transição para um estado não íntegro), a próxima fase é a análise de correlação. Nessa etapa, utilizamos a presença do evento gatilho para correlacionar a telemetria de pontos na plataforma Azure, como:

  • Host do Azure: o blade físico que hospeda VMs.
  • TOR: switch de rede superior do rack.
  • Armazenamento do Microsoft Azure: o serviço que hospeda discos virtuais para máquinas virtuais do Azure.

Cada um desses sistemas tem os seus próprios feeds de telemetria que precisam de ser analisados e correlacionados com o evento de gatilho de tempo de inatividade da VM. Esse processo é feito através da compreensão do gráfico de dependência de uma VM e dos sistemas subjacentes que podem causar a falha de uma VM e, em seguida, da união da 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 junção de janela de tempo *para correlacionar fluxos de telemetria temporal. No final desse processo de correlação, temos um conjunto de dados que representa transições de tempo de inatividade da VM com telemetria de plataforma correlacionada de todos os sistemas dependentes que poderiam causar ou poderiam ter informações úteis para determinar o que levou à falha da VM.

Fase 3: Atribuição de causa raiz

A próxima etapa do processo é a atribuição. Agora que coletamos 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 falha do TOR, após nossa análise de correlação poderemos ter muitas informações interessantes para interpretar. Por exemplo, os sistemas que monitorizam os anfitriões do Azure podem ter registos indicando que perderam a conectividade com os anfitriões durante esse período. Também podemos ter sinais relacionados a problemas de conectividade do disco virtual e sinais explícitos do dispositivo TOR sobre a falha. Todas essas informações são agora examinadas e o sinal explícito de falha do TOR é priorizado sobre os outros sinais como a causa raiz. Esse processo de priorização e as regras por trás dele são construídos com especialistas de domínio e modificados à medida que a plataforma Azure evolui. Os mecanismos de aprendizado de máquina e detecção de anomalias baseiam-se nessas causas raiz atribuídas, para ajudar a identificar oportunidades para melhorar essas regras de classificação e detectar mudanças de padrão na taxa dessas falhas para realimentar pipelines de implantação seguros.

Fase 4: Publicação RCA

A última etapa é publicar as 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ções podem chegar com vários atrasos de dados, as RCAs podem ocasionalmente ser atualizadas nesse processo para refletir a chegada de melhores fontes de informação, levando a uma causa raiz mais específica do que a que foi originalmente publicada.

A partir de agora

Identificar e comunicar a causa raiz de quaisquer problemas aos nossos clientes e parceiros é apenas o começo. Nossos clientes podem precisar pegar esses RCAs e compartilhá-los com seus clientes e colegas de trabalho. Queremos aproveitar o trabalho aqui para facilitar a identificação e o rastreamento de 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 combinar facilmente os tempos de inatividade com seus RCAs. Também estamos trabalhando em novos recursos para facilitar o envio de RCAs por email e, eventualmente, a assinatura de RCAs para suas VMs. Esse recurso tornará possível inscrever-se em RCAs diretamente em sua caixa de entrada após um evento de indisponibilidade, sem necessidade de nenhuma ação adicional de sua parte.

Próximas etapas

Para saber mais sobre as soluções oferecidas, consulte o artigo de solução correspondente:

Para obter uma visão geral de como monitorar Máquinas Virtuais do Azure, veja Monitorar máquinas virtuais do Azure e Referência de monitoramento de máquinas virtuais do Azure.