Editar

Compartilhar via

Crie sistemas observáveis e de monitoramento em tempo real para a mídia

Azure Data Explorer
Funções do Azure
Assistente de Métricas de IA do Azure
Armazenamento do Blobs do Azure
Hubs de eventos do Azure

Essa arquitetura descreve uma solução que fornece monitoramento em tempo real e observabilidade de sistemas e dados de telemetria do dispositivo do usuário final. Ele foca em um caso de uso para o setor de mídia.

Grafana é uma marca registrada da sua respectiva empresa. Nenhum endosso é implícito pelo uso dessa marca.

Arquitetura

Diagrama que mostra uma arquitetura que descreve uma solução que fornece monitoramento em tempo real e observabilidade de sistemas e dados de telemetria do dispositivo do usuário final.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados

No sistema observável mostrado no diagrama, a telemetria bruta é transmitida para o Armazenamento de Blobs do Azure via HTTP e conectores. A telemetria bruta é processada, transformada, normalizada e salva no Azure Data Explorer para análise. Sistemas como o Grafana e o Assistente de Métricas do Azure leem dados do Data Explorer e fornecem insights aos usuários finais.

Mais especificamente, esses são os elementos do sistema no diagrama:

  1. Instrumentação. A instrumentação ocorre por meio de investigações ou agentes que são instalados nos sistemas para monitorar dados. Esses agentes são oferecidos em várias formas. Por exemplo, em uma plataforma de streaming de vídeo sob demanda, uma empresa pode utilizar o padrão aberto dash.js para coletar métricas de Qualidade de Experiência dos clientes.
  2. Ingestão. Essa telemetria bruta pode vir diretamente dos clientes finais por meio de chamadas HTTP. Alternativamente, você pode fazer upload por meio de sistemas de terceiros para armazenamentos persistentes e data lakes, como o Armazenamento de Blobs. O Armazenamento do Microsoft Azure dá suporte à capacidade de invocar uma função do Azure quando um novo arquivo é carregado. Você pode utilizar esse mecanismo de gatilho para mover a telemetria bruta para data warehouses estruturados.
  3. Transformação e persistência. Talvez você precise de um sistema de transformação para normalizar seus dados. Um aplicativo do Azure Functions transforma os dados conforme necessário e os grava no Data Explorer. O Data Explorer é ideal para a análise de Big Data porque foi projetado para alto desempenho e taxa de transferência em grandes conjuntos de dados.
  4. Monitoramento. O Espaço Gerenciado do Azure para Grafana dá suporte à integração com o Data Explorer. Você pode utilizar os recursos arrastar e soltar do Grafana para rapidamente criar painéis e gráficos. O Grafana é uma boa opção para o monitoramento de mídia porque fornece atualização de subminutos dos blocos do painel e também pode ser utilizado para alertas.
  5. Detectar anomalias. O painel do Grafana fornece suporte para o monitoramento manual no NOC. Entretanto, com um grande conjunto de dados e uma base de usuários espalhada por várias regiões geográficas e utilizando vários dispositivos, a identificação manual de problemas por meio de gráficos e regras de alerta que têm limites embutidos em código torna-se ineficiente. Você pode utilizar a inteligência artificial para resolver esse problema. Serviços como o Assistente de Métricas usam algoritmos de aprendizado de máquina para entender e detectar automaticamente anomalias com base em dados de séries temporais. Além disso, a plataforma de dados Kusto tem funções internas de detecção de anomalias que levam em conta a sazonalidade e as tendências de linha de base nos dados.

Componentes

  • O Data Explorer é um serviço gerenciado de análise de dados para análise em tempo real de grandes volumes de dados. O Data Explorer é uma ótima ferramenta para o tratamento de grandes conjuntos de dados que exigem alta velocidade e taxa de transferência de recuperação de dados. Essa arquitetura utiliza o Data Explorer para armazenar e consultar conjuntos de dados para análise.
  • O Armazenamento de Blobs é utilizado para manter a telemetria bruta. Essa telemetria pode vir de seus aplicativos e serviços ou de fornecedores terceirizados. Os dados podem ser tratados como transitórios se você não precisar executar mais análises posteriormente. Os dados do armazenamento de blobs são ingeridos nos clusters do Data Explorer.
  • A Grade de Eventos do Azure é um sistema de fornecimento de eventos. É utilizado para escutar eventos publicados pelo Armazenamento de Blobs. Os eventos do Armazenamento do Microsoft Azure permitem que os aplicativos reajam a eventos como a criação e a exclusão de blobs. Uma função do Azure assina eventos que são publicados na Grade de Eventos do Azure.
  • O Hubs de Eventos do Azure é um serviço de ingestão de dados em tempo real que você pode utilizar para ingerir milhões de eventos por segundo de qualquer fonte. Os hubs de eventos representam a porta de entrada, geralmente chamada de ingestor de eventos, para um pipeline de eventos. Um ingestor de eventos é um componente ou serviço localizado entre os editores e consumidores de eventos. Ele desacopla a produção de um fluxo de eventos do consumo dos eventos.
  • O Azure Functions é uma solução sem servidor usada para analisar e transformar dados ingeridos por meio de pontos de extremidade HTTP e blob e gravar no cluster do Data Explorer.
  • O Espaço Gerenciado do Azure para Grafana conecta-se facilmente ao Data Explorer. Nessa arquitetura, ele gera gráficos e painéis que visualizam os dados de telemetria. O Espaço Gerenciado do Azure para Grafana fornece uma profunda integração com o Microsoft Entra ID para que você possa implementar o acesso baseado em função a painéis e exibições.
  • O Assistente de Métricas faz parte dos Serviços de IA Aplicada do Azure. Ele utiliza inteligência artificial para realizar o monitoramento de dados e a detecção de anomalias em dados de séries temporais. O Assistente de Métricas do Azure automatiza o processo de aplicação de modelos aos dados e fornece um conjunto de APIs e um espaço de trabalho baseado na Web para ingestão de dados, detecção de anomalias e diagnóstico. Você pode usá-lo mesmo que não tenha conhecimento de aprendizado de máquina.

Alternativas

O Azure Data Factory e o Azure Synapse Analytics fornecem ferramentas e espaços de trabalho para a criação de fluxos de trabalho de ETL e a capacidade de acompanhar e repetir trabalhos a partir de uma interface gráfica. Observe que o Data Factory e o Azure Synapse têm um atraso mínimo de cerca de 5 minutos entre o tempo de ingestão de dados e a persistência. Esse atraso pode ser aceitável em seu sistema de monitoramento. Se for, recomendamos que você considere estas alternativas.

Detalhes do cenário

As organizações geralmente implantam tecnologias variadas e em grande escala para resolver problemas de negócios. Esses sistemas e os dispositivos do usuário final geram grandes conjuntos de dados de telemetria.

Essa arquitetura é baseada em um caso de uso para o setor de mídia. O streaming de mídia para reprodução ao vivo e de vídeo sob demanda exige identificação e resposta quase em tempo real aos problemas do aplicativo. Para dar suporte a esse cenário em tempo real, as organizações precisam coletar um conjunto massivo de telemetria, o que exige uma arquitetura escalonável. Após a coleta dos dados, outros tipos de análise, como IA e detecção de anomalias, são necessários para identificar com eficiência os problemas em um conjunto de dados tão grande.

Quando tecnologias de larga escala são implantadas, o sistema e os dispositivos do usuário final que interagem com elas geram conjuntos maciços de dados de telemetria. Em cenários tradicionais, esses dados são analisados por meio de um sistema de data warehouse para gerar insights que podem ser utilizados para dar suporte a decisões de gerenciamento. Essa abordagem pode funcionar em alguns cenários, mas não é responsiva o suficiente para casos de uso de mídia de streaming. Para resolver esse problema, são exigidos insights em tempo real para os dados de telemetria gerados a partir de servidores de monitoramento, redes e dispositivos de usuários finais que interagem com eles. Sistemas de monitoramento que detectam falhas e erros são comuns, mas detectá-los quase em tempo real é difícil. Esse é o foco dessa arquitetura.

Em uma configuração de transmissão ao vivo ou vídeo sob demanda, os dados de telemetria são gerados a partir de sistemas e clientes heterogêneos (para dispositivos móveis, desktop e TV). A solução envolve a obtenção de dados brutos e a associação do contexto com os pontos de dados, por exemplo, dimensões como geografia, sistema operacional do usuário final, ID de conteúdo e provedor de CDN. A telemetria bruta é coletada, transformada e salva no Data Explorer para análise. Em seguida, você pode utilizar a IA para dar sentido aos dados e automatizar os processos manuais de observação e alertas. Você pode utilizar sistemas como o Grafana e o Assistente de Métricas para ler dados do Data Explorer para mostrar painéis interativos e disparar alertas.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, um conjunto de princípios orientadores que você poderá usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

Os aplicativos comercialmente críticos precisam continuar sendo executados mesmo durante eventos disruptivos, como interrupções na região do Azure ou na CDN. Existem duas estratégias principais e uma estratégia híbrida para a criação de redundância no seu sistema:

  • Ativa/ativa. Código e funções duplicados estão sendo executados. Qualquer um dos sistemas pode assumir durante uma falha.
  • Ativo/em espera. Apenas um nó está ativo/primário. O outro está pronto para assumir o controle caso o nó primário esteja inoperante.
  • Misto. Alguns componentes/serviços estão na configuração ativo/ativo, e outros estão em ativo/em espera.

Lembre-se de que nem todos os serviços do Azure têm redundância interna. Por exemplo, o Azure Functions executa um aplicativo de funções somente em uma região específica. A recuperação de desastres geográficos do Azure Functions descreve várias estratégias que você pode implementar, dependendo de como suas funções são disparadas (HTTP versus pub/sub).

O aplicativo de funções de ingestão e transformação pode ser executado no modo ativo/ativo. Você pode executar o Data Explorer nas configurações ativa/ativa e ativa/em espera.

O Espaço Gerenciado do Azure para Grafana dá suporte à redundância de zona de disponibilidade. Uma estratégia para criar redundância entre regiões é configurar o Grafana em cada região em que seu cluster do Data Explorer estiver implantado.

Otimização de custo

A otimização de custos consiste em reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

O custo dessa arquitetura depende do número de eventos de telemetria de entrada, do seu armazenamento de telemetria bruta no Armazenamento de Blobs do Azure e no Data Explorer, de um custo por hora para o Espaço Gerenciado do Azure para Grafana e de um custo estático para o número de gráficos de séries temporais no Assistente de Métricas.

Você pode usar a Calculadora de preços do Azure para estimar seus custos por hora ou mensais.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.

Dependendo da escala e da frequência das solicitações de entrada, o aplicativo de funções pode ser um gargalo, por dois motivos principais:

  • Inicialização a frio. A inicialização a frio é uma consequência das execuções sem servidor. Refere-se ao tempo de agendamento e configuração exigido para ativar um ambiente antes que a função seja executada pela primeira vez. No máximo, o tempo exigido é de alguns segundos.
  • Frequência das solicitações. Digamos que você tenha 1.000 solicitações HTTP, mas somente um servidor de thread único para lidar com elas. Não será possível atender a todas as 1.000 solicitações HTTP simultaneamente. Para atender a essas solicitações em tempo hábil, você precisa implantar mais servidores. Ou seja, você precisa escalar horizontalmente.

Recomendamos que você use SKUs Premium ou Dedicadas para:

  • Eliminar a partida a frio.
  • Atenda aos requisitos de solicitações simultâneas escalando ou reduzindo verticalmente o número de máquinas virtuais em serviço.

Para obter mais informações, consulte Selecionar uma SKU para seu cluster do Azure Data Explorer.

Implantar este cenário

Para obter informações sobre a implantação desse cenário, consulte real-time-monitoring-and-observability-for-media no GitHub. Esse código de exemplo inclui a infraestrutura como código (IaC) necessária para iniciar o desenvolvimento e as funções do Azure Functions para ingerir e transformar os dados de pontos de extremidade HTTP e blobs.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas