Editar

Partilhar via

Crie sistemas de monitoramento e observação em tempo real para mídia

Azure Data Explorer
Azure Functions
Assistente de Métricas de IA do Azure
Azure Blob Storage
Azure Event Hubs

Essa arquitetura descreve uma solução que fornece monitoramento em tempo real e observabilidade de sistemas e dados de telemetria de dispositivos do usuário final. Ele se concentra em um caso de uso para a indústria de mídia.

Grafana é uma marca registada da respetiva empresa. O uso desta marca não implica qualquer endosso.

Arquitetura

Diagrama que mostra uma arquitetura que fornece monitoramento em tempo real e observabilidade de sistemas e dados de telemetria de dispositivos do usuário final.

Transfira um ficheiro do Visio desta 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 Azure Metrics Advisor leem dados do Data Explorer e fornecem informações aos usuários finais.

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

  1. Instrumentação. A instrumentação ocorre por meio de sondas ou agentes instalados em sistemas para monitorar dados. Estes agentes apresentam-se de várias formas. Por exemplo, em uma plataforma de streaming de vídeo sob demanda, uma empresa pode usar dash.js de padrões abertos para coletar métricas de Qualidade de Experiência dos clientes.
  2. Ingestão. Essa telemetria bruta pode vir diretamente de clientes finais por meio de chamadas HTTP. Como alternativa, você pode carregá-lo por meio de sistemas de terceiros para armazenamento persistente e data lakes, como o Blob Storage. O Armazenamento de Blogues suporta a capacidade de invocar uma função do Azure quando um novo ficheiro é carregado. Você pode usar esse mecanismo de gatilho para mover a telemetria bruta para armazéns de dados estruturados.
  3. Transformação e persistência. Você pode precisar 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 análise de big data porque foi projetado para alto desempenho e taxa de transferência em grandes conjuntos de dados.
  4. Monitorização. O Azure Managed Grafana suporta a integração com o Data Explorer. Você pode usar os recursos de arrastar e soltar do Grafana para criar rapidamente painéis e gráficos. O Grafana é uma boa opção para monitoramento de mídia porque fornece atualização sub-minuto de blocos do painel e também pode ser usado para alertas.
  5. Deteção de anomalias. O painel do Grafana fornece suporte para monitoramento manual no NOC. No entanto, com um grande conjunto de dados e uma base de usuários espalhados por geografias e usando vários dispositivos, a identificação manual de problemas por meio de gráficos e regras de alerta que têm limites codificados torna-se ineficiente. Você pode usar a IA para resolver esse problema. Serviços como o Metrics Advisor usam algoritmos de aprendizado de máquina para entender e detetar automaticamente anomalias com base em dados de séries cronológicas. Além disso, a plataforma de dados Kusto tem funções integradas de deteçã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 de análise de dados gerenciado para análise em tempo real de grandes volumes de dados. O Data Explorer é uma ótima ferramenta para lidar com grandes conjuntos de dados que exigem alta velocidade e taxa de transferência de recuperação de dados. Essa arquitetura usa o Data Explorer para armazenar e consultar conjuntos de dados para análise.
  • O armazenamento de Blob é usado para armazenar 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 realizar mais análises posteriormente. Os dados do Armazenamento de Blob são ingeridos em clusters do Data Explorer.
  • A Grade de Eventos do Azure é um sistema de entrega de eventos. Ele é usado para ouvir eventos publicados pelo Armazenamento de Blobs. Os eventos do Armazenamento do 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 publicados pela Grade de Eventos.
  • Os Hubs de Eventos do Azure são um serviço de ingestão de dados em tempo real que pode utilizar para ingerir milhões de eventos por segundo a partir de qualquer origem. Os hubs de eventos representam a porta de entrada, muitas vezes chamada de ingestor de eventos, para um pipeline de eventos. Um ingestor de eventos é um componente ou serviço localizado entre editores de eventos e consumidores de eventos. Dissocia 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 Azure Managed Grafana liga-se facilmente ao Data Explorer. Nessa arquitetura, ele gera gráficos e painéis que visualizam dados de telemetria. O Azure Managed Grafana fornece integração profunda com o Microsoft Entra ID para que você possa implementar o acesso baseado em função a painéis e exibições.
  • O Consultor de Métricas faz parte dos Serviços de IA Aplicada do Azure. Ele usa IA para realizar monitoramento de dados e deteção de anomalias em dados de séries temporais. O Metrics Advisor 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, deteçã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 criar fluxos de trabalho ETL e a capacidade de controlar 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 desde o momento da ingestão até a persistência. Esse atraso pode ser aceitável em seu sistema de monitoramento. Se for, recomendamos que considere estas alternativas.

Detalhes do cenário

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

Esta arquitetura é baseada em um caso de uso para a indústria de mídia. O streaming de mídia para reprodução ao vivo e de vídeo sob demanda requer identificação e resposta quase em tempo real a problemas de aplicativos. Para dar suporte a esse cenário em tempo real, as organizações precisam coletar um conjunto de telemetria massivo, que requer arquitetura escalável. Depois que os dados são coletados, outros tipos de análise, como IA e deteção de anomalias, são necessários para identificar problemas de forma eficiente em um conjunto de dados tão grande.

Quando tecnologias de grande escala são implantadas, o sistema e os dispositivos do usuário final que interagem com eles 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 usados para apoiar decisões de gerenciamento. Essa abordagem pode funcionar em alguns cenários, mas não é responsiva o suficiente para casos de uso de streaming de mídia. Para resolver esse problema, são necessárias informações 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 detetam falhas e erros são comuns, mas detetá-los quase em tempo real é difícil. Esse é o foco desta arquitetura.

Em uma configuração de streaming ao vivo ou vídeo sob demanda, os dados de telemetria são gerados a partir de sistemas e clientes heterogêneos (dispositivos móveis, desktop e TV). A solução envolve pegar dados brutos e associar contexto aos 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. Você pode usar a IA para entender os dados e automatizar os processos manuais de observação e alerta. Você pode usar sistemas como o Grafana e o Metrics Advisor 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ê pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

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

Os aplicativos críticos para os negócios precisam continuar em execução mesmo durante eventos disruptivos, como interrupções na região do Azure ou na CDN. Há duas estratégias principais e uma estratégia híbrida para criar redundância em seu sistema:

  • Modo ativo/ativo. Código duplicado e funções estão em execução. Qualquer um dos sistemas pode assumir o controle durante uma falha.
  • Ativo/em espera. Apenas um nó é ativo/primário. O outro está pronto para assumir caso o nó principal caia.
  • Misto. Alguns componentes/serviços estão na configuração ativa/ativa e outros estão na ativa/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ção 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 acionadas (HTTP versus pub/sub).

O aplicativo de função 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/espera.

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

Otimização de custos

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

O custo dessa arquitetura depende do número de eventos de telemetria de entrada, do armazenamento de telemetria bruta no Armazenamento de Blobs e no Data Explorer, de um custo por hora para o Azure Managed Grafana e de um custo estático para o número de gráficos de séries cronológicas no Metrics Advisor.

Você pode usar a calculadora de preços do Azure para estimar seus custos horários ou mensais.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

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

  • Arranque a frio. O arranque a frio é uma consequência de execuções sem servidor. Refere-se ao tempo de programação e configuração necessário para girar um ambiente antes que a função comece a ser executada. No máximo, o tempo necessário é de alguns segundos.
  • Frequência dos pedidos. Digamos que você tenha 1.000 solicitações HTTP, mas apenas um servidor de thread único para lidar com elas. Você não poderá 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 Dedicados para:

  • Elimine o arranque a frio.
  • Manipule os requisitos para solicitações simultâneas dimensionando o número de máquinas virtuais de serviço para cima ou para baixo.

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

Implementar este cenário

Para obter informações sobre como implantar esse cenário, consulte monitoramento em tempo real e observabilidade para mídia no GitHub. Este exemplo de código inclui a infraestrutura como código (IaC) necessária para inicializar o desenvolvimento e as funções do Azure para ingerir e transformar os dados de pontos de extremidade HTTP e blob.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

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

Próximos passos