Questa architettura descrive una soluzione che fornisce il monitoraggio in tempo reale e l'osservabilità dei sistemi e dei dati di telemetria dei dispositivi degli utenti finali. Si concentra su un caso d'uso per il settore dei media.
Grafana è un marchio della rispettiva azienda. Nessuna verifica dell'autenticità è implicita nell'uso di questo marchio.
Architettura
Scaricare un file di Visio di questa architettura.
Flusso di dati
Nel sistema osservabile illustrato nel diagramma, i dati di telemetria non elaborati vengono trasmessi a Archiviazione BLOB di Azure tramite HTTP e connettori. I dati di telemetria non elaborati vengono elaborati, trasformati, normalizzati e salvati in Azure Esplora dati per l'analisi. I sistemi come Grafana e Azure Metrics Advisor leggono i dati da Esplora dati e forniscono informazioni dettagliate agli utenti finali.
In particolare, questi sono gli elementi del sistema nel diagramma:
- Strumentazione. La strumentazione avviene tramite probe o agenti installati nei sistemi per monitorare i dati. Questi agenti sono disponibili in varie forme. Ad esempio, in una piattaforma di streaming video on demand, un'azienda potrebbe usare standard aperti dash.js per raccogliere le metriche di qualità dell'esperienza dai clienti.
- Inserimento. Questi dati di telemetria non elaborati possono provenire direttamente dai client finali tramite chiamate HTTP. In alternativa, è possibile caricarlo tramite sistemi di terze parti in un archivio permanente e in data lake come l'archiviazione BLOB. Archiviazione blog supporta la possibilità di richiamare una funzione di Azure quando viene caricato un nuovo file. È possibile usare questo meccanismo di trigger per spostare i dati di telemetria non elaborati in data warehouse strutturati.
- Trasformazione e persistenza. Potrebbe essere necessario un sistema di trasformazione per normalizzare i dati. Un'app Funzioni di Azure trasforma i dati in base alle esigenze e quindi lo scrive in Esplora dati. Esplora dati è ideale per l'analisi dei Big Data perché è progettata per prestazioni elevate e velocità effettiva in set di dati di grandi dimensioni.
- Monitoraggio. Grafana gestito di Azure supporta l'integrazione con Esplora dati. È possibile usare le funzionalità di trascinamento della selezione di Grafana per creare rapidamente dashboard e grafici. Grafana è un'ottima soluzione per il monitoraggio multimediale perché fornisce un aggiornamento secondario dei riquadri del dashboard e può essere usato anche per gli avvisi.
- Rilevamento delle anomalie. Il dashboard di Grafana fornisce supporto per il monitoraggio manuale nel NOC. Tuttavia, con un set di dati di grandi dimensioni e una base utente distribuita tra aree geografiche e usando vari dispositivi, l'identificazione manuale dei problemi tramite grafici e regole di avviso con soglie hardcoded diventa inefficiente. È possibile usare l'intelligenza artificiale per risolvere questo problema. Servizi come Advisor metriche usano algoritmi di Machine Learning per comprendere e rilevare automaticamente le anomalie in base ai dati delle serie temporali. Inoltre, la piattaforma dati Kusto dispone di funzioni di rilevamento anomalie predefinite che rappresentano le tendenze di stagionalità e baseline nei dati.
Componenti
- Esplora dati è un servizio di analisi dei dati gestito per l'analisi in tempo reale di grandi volumi di dati. Esplora dati è un ottimo strumento per la gestione di set di dati di grandi dimensioni che richiedono velocità elevata e velocità effettiva del recupero dei dati. Questa architettura usa Esplora dati per archiviare ed eseguire query sui set di dati per l'analisi.
- L'archiviazione BLOB viene usata per contenere dati di telemetria non elaborati. Questi dati di telemetria possono provenire da applicazioni e servizi o da fornitori di terze parti. I dati possono essere considerati temporanei se non è necessario eseguire più analisi in un secondo momento. I dati di Archiviazione BLOB vengono inseriti in cluster Esplora dati.
- Griglia di eventi di Azure è un sistema di recapito degli eventi. Viene usato per ascoltare gli eventi pubblicati da Archiviazione BLOB. Archiviazione di Azure eventi consentono alle applicazioni di reagire a eventi come la creazione e l'eliminazione di BLOB. Una funzione di Azure sottoscrive gli eventi pubblicati da Griglia di eventi.
- Hub eventi di Azure è un servizio di inserimento dati in tempo reale che è possibile usare per inserire milioni di eventi al secondo da qualsiasi origine. Gli hub eventi rappresentano la frontdoor, spesso denominata ingestor di eventi, per una pipeline di eventi. Un evento ingestor è un componente o un servizio che si trova tra autori di eventi e consumer di eventi. Separa la produzione di un flusso di eventi dall'utilizzo degli eventi.
- Funzioni di Azure è una soluzione serverless usata per analizzare e trasformare i dati inseriti tramite endpoint HTTP e BLOB e scrivere nel cluster Esplora dati.
- Grafana gestito di Azure si connette facilmente a Esplora dati. In questa architettura vengono generati grafici e dashboard che visualizzano i dati di telemetria. Grafana gestito di Azure offre un'integrazione approfondita con Microsoft Entra ID in modo da poter implementare l'accesso in base al ruolo ai dashboard e alle visualizzazioni.
- Metrics Advisor fa parte dei servizi di intelligenza artificiale di Azure. Usa l'intelligenza artificiale per eseguire il monitoraggio dei dati e il rilevamento anomalie nei dati delle serie temporali. Advisor metriche automatizza il processo di applicazione di modelli ai dati e fornisce un set di API e un'area di lavoro basata sul Web per l'inserimento dei dati, il rilevamento anomalie e la diagnostica. È possibile usarlo anche se non si ha alcuna conoscenza dell'apprendimento automatico.
Alternative
Azure Data Factory e Azure Synapse Analytics forniscono strumenti e aree di lavoro per la creazione di flussi di lavoro ETL e la possibilità di tenere traccia dei processi e riprovare da un'interfaccia grafica. Si noti che Data Factory e Azure Synapse hanno un ritardo minimo di circa 5 minuti dal momento dell'inserimento alla persistenza. Questo ritardo potrebbe essere accettabile nel sistema di monitoraggio. In caso affermativo, è consigliabile prendere in considerazione queste alternative.
Dettagli dello scenario
Le organizzazioni spesso distribuiscono tecnologie varie e su larga scala per risolvere i problemi aziendali. Questi sistemi e i dispositivi degli utenti finali generano grandi set di dati di telemetria.
Questa architettura si basa su un caso d'uso per il settore multimediale. Lo streaming multimediale per la riproduzione live e video su richiesta richiede l'identificazione quasi in tempo reale di e la risposta ai problemi dell'applicazione. Per supportare questo scenario in tempo reale, le organizzazioni devono raccogliere un set di dati di telemetria di grandi dimensioni, che richiede un'architettura scalabile. Dopo la raccolta dei dati, sono necessari altri tipi di analisi, ad esempio intelligenza artificiale e rilevamento anomalie, per identificare in modo efficiente i problemi in un set di dati di grandi dimensioni.
Quando vengono distribuite tecnologie su larga scala, il sistema e i dispositivi degli utenti finali che interagiscono con essi generano enormi set di dati di telemetria. Negli scenari tradizionali, questi dati vengono analizzati tramite un sistema di data warehouse per generare informazioni dettagliate che possono essere usate per supportare le decisioni di gestione. Questo approccio potrebbe funzionare in alcuni scenari, ma non è abbastanza reattivo per i casi d'uso dei contenuti multimediali di streaming. Per risolvere questo problema, sono necessarie informazioni dettagliate in tempo reale per i dati di telemetria generati dai server di monitoraggio, dalle reti e dai dispositivi degli utenti finali che interagiscono con essi. I sistemi di monitoraggio che rilevano errori ed errori sono comuni, ma per intercettarli quasi in tempo reale è difficile. Questo è l'obiettivo di questa architettura.
In un'impostazione di streaming live o video su richiesta, i dati di telemetria vengono generati da sistemi e client eterogenei (dispositivi mobili, desktop e TV). La soluzione prevede l'acquisizione di dati non elaborati e l'associazione del contesto ai punti dati, ad esempio dimensioni come geography, sistema operativo dell'utente finale, ID contenuto e provider di rete CDN. I dati di telemetria non elaborati vengono raccolti, trasformati e salvati in Esplora dati per l'analisi. È quindi possibile usare l'intelligenza artificiale per comprendere i dati e automatizzare i processi manuali di osservazione e avviso. È possibile usare sistemi come Grafana e Advisor metriche per leggere i dati da Esplora dati per visualizzare dashboard interattivi e attivare avvisi.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.
Le applicazioni critiche per l'azienda devono continuare a essere in esecuzione anche durante eventi di interruzione, ad esempio l'area di Azure o le interruzioni della rete CDN. Esistono due strategie principali e una strategia ibrida per la creazione della ridondanza nel sistema:
- Attivo/attivo. Il codice e le funzioni duplicati sono in esecuzione. Entrambi i sistemi possono assumere il controllo durante un errore.
- Attivo/standby. Un solo nodo è attivo/primario. L'altro è pronto per assumere il controllo nel caso in cui il nodo primario sia inattivo.
- Mista. Alcuni componenti/servizi sono nella configurazione attiva/attiva e alcuni sono attivi/standby.
Tenere presente che non tutti i servizi di Azure hanno ridondanza predefinita. Ad esempio, Funzioni di Azure esegue un'app per le funzioni solo in un'area specifica. Funzioni di Azure ripristino di emergenza geografico descrive varie strategie che è possibile implementare, a seconda della modalità di attivazione delle funzioni (HTTP e pub/sub).
L'app per le funzioni di inserimento e trasformazione può essere eseguita in modalità attiva/attiva. È possibile eseguire Esplora dati in configurazioni attive/attive e di standby.
Grafana gestito di Azure supporta la ridondanza della zona di disponibilità. Una strategia per la creazione della ridondanza tra aree consiste nel configurare Grafana in ogni area in cui viene distribuito il cluster Esplora dati.
Ottimizzazione costi
L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.
Il costo di questa architettura dipende dal numero di eventi di telemetria in ingresso, dall'archiviazione di dati di telemetria non elaborati in Archiviazione BLOB e Esplora dati, da un costo orario per Grafana gestito di Azure e da un costo statico per il numero di grafici di serie temporali in Advisor metriche.
È possibile usare il calcolatore prezzi di Azure per stimare i costi orari o mensili.
Efficienza delle prestazioni
L'efficienza delle prestazioni è la capacità del carico di lavoro di ridimensionarsi per soddisfare le esigenze poste dagli utenti in modo efficiente. Per altre informazioni, vedere Elenco di controllo per l'efficienza delle prestazioni.
A seconda della scalabilità e della frequenza delle richieste in ingresso, l'app per le funzioni potrebbe essere un collo di bottiglia, per due motivi principali:
- Avvio a freddo. L'avvio a freddo è una conseguenza delle esecuzioni serverless. Si riferisce al tempo di pianificazione e configurazione necessario per avviare un ambiente prima che la funzione inizi l'esecuzione. Al massimo, il tempo necessario è di pochi secondi.
- Frequenza delle richieste. Si supponga di avere 1.000 richieste HTTP, ma solo un server a thread singolo per gestirle. Non sarà possibile gestire contemporaneamente tutte le 1.000 richieste HTTP. Per gestire queste richieste in modo tempestivo, è necessario distribuire più server. Vale a dire, è necessario ridimensionare orizzontalmente.
È consigliabile usare SKU Premium o Dedicati per:
- Elimina l'avvio a freddo.
- Gestire i requisiti per le richieste simultanee ridimensionando il numero di macchine virtuali di manutenzione verso l'alto o verso il basso.
Per altre informazioni, vedere Selezionare uno SKU per il cluster Esplora dati di Azure.
Distribuire lo scenario
Per informazioni sulla distribuzione di questo scenario, vedere real-time-monitoring-and-observability-for-media in GitHub. Questo esempio di codice include l'infrastruttura come codice (IaC) necessaria per avviare lo sviluppo e le funzioni di Azure per inserire e trasformare i dati dagli endpoint HTTP e BLOB.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- John Hauppa | Senior Technical Program Manager
- Uffaz Nathaniel | Principal Software Engineer
Altri contributori:
- Mick Alberts | Writer tecnico
- Dilmurod Makhaintuneliev | Software Engineer
- Omeed Musavi | Responsabile principale del software engineer
- Ayo Mustapha | Principal Technical Program Manager
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Esempi di codice supplementari
- Documentazione di Azure Esplora dati
- Introduzione ad Azure Esplora dati - Training
- Introduzione a Funzioni di Azure