Esaminare il routing dei messaggi
Il routing dei messaggi consente di inviare messaggi dai dispositivi ai servizi cloud in modo automatizzato, scalabile e affidabile. Il routing dei messaggi può essere usato per:
Invio di messaggi ed eventi di telemetria del dispositivo all'endpoint predefinito e agli endpoint personalizzati. Gli eventi che possono essere indirizzati includono eventi relativi al ciclo di vita del dispositivo, eventi di modifica del dispositivo gemello, eventi di modifica del dispositivo digitale ed eventi dello stato della connessione del dispositivo.
Filtrare i dati prima del routing a vari endpoint applicando query complesse. Il routing dei messaggi consente di eseguire query sulle proprietà dei messaggi e sul corpo del messaggio, nonché sui tag e sulle proprietà del dispositivo gemello.
Come descritto nell'unità precedente, l'hub IoT di Azure definisce un set comune di funzionalità per tutta la messaggistica da dispositivo a cloud per l'interoperabilità tra i protocolli.
Nota
Alcune delle funzionalità indicate in questa unità, ad esempio la messaggistica da cloud a dispositivo, i dispositivi gemelli e la gestione dei dispositivi, sono disponibili solo nel livello standard dell'hub IoT di Azure.
Endpoint di routing
Ogni hub IoT di Azure dispone di un endpoint predefinito (messaggi/eventi) compatibile con Hub eventi. È anche possibile creare endpoint personalizzati che puntano ad altri servizi nella Sottoscrizione di Azure.
Ogni messaggio viene indirizzato a tutti gli endpoint le cui query di routing gli corrispondono. In altre parole, un messaggio può essere indirizzato a più endpoint. Se un messaggio corrisponde a più route che puntano allo stesso endpoint, l'hub IoT di Azure invia il messaggio a tale endpoint una sola volta.
Endpoint predefinito
È possibile usare l'integrazione standard di Hub eventi e gli SDK per ricevere i messaggi da dispositivo a cloud dall'endpoint predefinito (messaggi/eventi). Una volta creata una route, i dati non vengono più trasmessi all'endpoint predefinito, a meno che non venga creata una route verso tale endpoint. Anche se non viene creata alcuna route, è necessario abilitare una route di fallback per indirizzare i messaggi all'endpoint predefinito. Se si crea l'hub tramite il portale o l’interfaccia della riga di comando, il fallback è abilitato per impostazione predefinita.
L'endpoint predefinito viene descritto in modo più dettagliato nell'unità successiva.
Endpoint personalizzati
Oltre all'endpoint predefinito, l'hub IoT di Azure supporta gli endpoint personalizzati seguenti:
- Contenitori di archiviazione
- Code del bus di servizio
- Argomenti del bus di servizio
- Hub eventi
- Cosmos DB (anteprima)
L'hub IoT di Azure richiede l'accesso in scrittura a questi endpoint di servizio per il funzionamento del routing dei messaggi. Se si configurano gli endpoint tramite il Portale di Azure, verranno aggiunte le autorizzazioni necessarie. Se si configurano gli endpoint usando PowerShell o l'interfaccia della riga di comando di Azure, è necessario fornire l'autorizzazione di accesso in scrittura.
Accertarsi di configurare i servizi per supportare la velocità effettiva prevista. Ad esempio, se si usa Hub eventi come endpoint personalizzato, è necessario configurare le unità elaborate per l'hub eventi in modo che possa gestire l'ingresso degli eventi che si prevede di inviare tramite il routing dei messaggi dell'hub IoT di Azure. In modo analogo, quando si usa una coda di Bus di servizio come endpoint, è necessario configurarne la dimensione massima per garantire che la coda possa contenere tutti i dati in ingresso, fino a quando non vengono eliminati dai consumer. Durante la prima configurazione della soluzione IoT, potrebbe essere necessario monitorare gli altri endpoint e quindi apportare le modifiche necessarie per il carico effettivo.
Contenitori di Archiviazione di Azure come endpoint di routing
Esistono due servizi di archiviazione a cui hub IoT di Azure può indirizzare i messaggi:
- Archiviazione BLOB di Azure
- Azure Data Lake Storage Gen2 (ADLS Gen2)
Gli account di Azure Data Lake Storage sono account di archiviazione abilitati per gli spazi dei nomi gerarchici basati sull'archiviazione BLOB. Entrambi usano i BLOB per l'archiviazione.
Per informazioni su come leggere da questo tipo di endpoint, vedere Archiviazione BLOB.
Code del bus di servizio di Azure e argomenti del bus di servizio come endpoint di routing
Nelle code e negli argomenti del bus di servizio usati come endpoint dell’hub IoT di Azure non devono essere abilitate le sessioni o il rilevamento di duplicati. Se una di queste opzioni è abilitata, l'endpoint risulta non raggiungibile nel portale di Azure.
Per informazioni su come leggere da questi tipi di endpoint, vedere:
Leggere dalle code del bus di servizio.
Leggere dagli argomenti del bus di servizio.
Hub eventi come endpoint di routing
Hub eventi è un servizio che consente di elaborare grandi quantità di dati di telemetria sugli eventi da applicazioni e dispositivi connessi. Dopo aver raccolto i dati in Hub eventi, è possibile archiviarli usando un cluster di archiviazione o trasformarli usando un provider di analisi in tempo reale. Questa funzionalità di raccolta ed elaborazione di eventi su larga scala è un componente chiave delle architetture di applicazioni moderne, tra cui IoT.
Vedere leggere da Hub eventi per informazioni su come leggere i messaggi da Hub eventi.
Azure Cosmos DB come endpoint di routing (anteprima)
È possibile inviare dati ad Azure Cosmos DB direttamente dall'hub IoT di Azure. Cosmos DB è un servizio di database multi-modello iperscalabile completamente gestito. Offre bassa latenza e disponibilità elevata, il che lo rende un'ottima scelta per scenari come le soluzioni connesse e la produzione che richiedono un'analisi dei dati downstream approfondita.
Eseguire il routing a un endpoint in un'altra sottoscrizione
Se la risorsa endpoint si trova in una sottoscrizione diversa rispetto all'hub IoT di Azure, è necessario configurare l'hub IoT di Azure come servizio Microsoft attendibile prima di creare un endpoint personalizzato. Quando si crea l'endpoint personalizzato, impostare il tipo di Autenticazione sull'identità assegnata dall'utente.
Per altre informazioni, vedere Connettività in uscita dall'hub IoT ad altre risorse di Azure.
Route di fallback
La route di fallback invia tutti i messaggi che non soddisfano le condizioni di query su una delle route esistenti all'endpoint predefinito (messaggi/eventi), che è compatibile con Hub eventi. Se il routing dei messaggi è abilitato, è possibile abilitare la funzionalità di route di fallback. Una volta creata una route, i dati non vengono più trasmessi all'endpoint predefinito, a meno che non venga creata una route verso tale endpoint. Se non sono presenti route all'endpoint predefinito ed è abilitata una route di fallback, solo i messaggi che non corrispondono ad alcuna condizione di query sulle route vengono inviati all'endpoint predefinito. Inoltre, se tutte le route esistenti vengono eliminate, è necessario abilitare la capacità di route di fallback per ricevere tutti i dati nell'endpoint predefinito.
È possibile abilitare o disabilitare la route di fallback nel portale di Azure dal pannello Routing dei messaggi. È anche possibile usare Azure Resource Manager per FallbackRouteProperties in modo da usare un endpoint personalizzato per la route di fallback.
Eventi non di telemetria
Oltre ai dati di telemetria del dispositivo, il routing dei messaggi consente anche l'invio di eventi non telemetrici, tra cui:
- Eventi di modifica del dispositivo gemello
- Eventi relativi al ciclo di vita del dispositivo
- Eventi relativi al ciclo di vita dei processo del dispositivo
- Eventi di modifica del gemello digitale
- Eventi dello stato della connessione del dispositivo
Ad esempio, se viene creata una route con l'origine dati impostata su Eventi di modifica del dispositivo gemello, l'hub IoT di Azure invia messaggi all'endpoint che contengono la modifica nel dispositivo gemello. In modo analogo, se viene creata una route con origine dati impostata su Eventi relativi al ciclo di vita del dispositivo, l'hub IoT di Azure invia un messaggio che indica se il dispositivo o il modulo è stato eliminato o creato. Quando si usa Azure IoT Plug and Play, uno sviluppatore può creare route con l'origine dati impostata su Eventi di modifica del gemello digitale in modo che l'hub IoT di Azure invii messaggi ogni volta che una proprietà del gemello digitale viene impostata o modificata, un gemello digitale viene sostituito o in caso di evento di modifica relativo al dispositivo gemello sottostante. Infine, se viene creata una route con origine dati impostata su Eventi dello stato della connessione del dispositivo, l'hub IoT di Azure invia un messaggio che indica se il dispositivo è stato connesso o disconnesso.
L'hub IoT di Azure si integra anche con Griglia di eventi di Azure per pubblicare gli eventi dei dispositivi supportando le integrazioni in tempo reale e l'automazione dei flussi di lavoro in base a questi eventi.
Limitazioni per gli eventi dello stato della connessione del dispositivo
Gli eventi dello stato della connessione del dispositivo sono disponibili per i dispositivi che si connettono usando il protocollo MQTT o AMQP, oppure usando uno di questi protocolli su WebSockets. Le richieste effettuate solo con HTTPS non attivano le notifiche sullo stato della connessione del dispositivo. Affinché l’hub IoT di Azure inizi a inviare eventi sullo stato della connessione del dispositivo, dopo l'apertura di una connessione il dispositivo deve chiamare l'operazione di ricezione del messaggio da cloud a dispositivo o l'operazione di invio della telemetria da dispositivo a cloud. Al di fuori degli SDK di Azure IoT, in MQTT queste operazioni equivalgono alle operazioni SUBSCRIBE o PUBLISH negli argomenti di messaggistica appropriati. Nel protocollo AMQP queste operazioni equivalgono al collegamento o al trasferimento di un messaggio nei percorsi del collegamento appropriati.
L'hub IoT di Azure non segnala le connessioni e le disconnessioni di ogni singolo dispositivo, ma pubblica invece lo stato corrente della connessione in uno snapshot periodico di 60 secondi. La ricezione dello stesso evento dello stato della connessione con numeri di sequenza diversi o di eventi dello stato della connessione diversi significa che si è verificato un cambiamento nello stato della connessione del dispositivo durante la finestra di 60 secondi.
Testare le route
Quando si crea una nuova route o si modifica una route esistente, è consigliabile testare la query di route con un messaggio di esempio. È possibile testare singole route o testarle tutte contemporaneamente. Nessuno messaggio viene indirizzato agli endpoint durante il test. Per i test è possibile usare il portale di Azure, Azure Resource Manager, Azure PowerShell e l'interfaccia della riga di comando di Azure. I risultati consentono di identificare se il messaggio di esempio corrisponde o meno alla query, oppure se il test non è stato eseguito perché il messaggio di esempio o la sintassi della query non sono corretti. Per altre informazioni, vedere Testare la route e Testare tutte le route.
Latenza
Quando si indirizzano i messaggi di telemetria da dispositivo a cloud usando gli endpoint predefiniti, si verifica un leggero aumento della latenza end-to-end dopo la creazione della prima route.
Nella maggior parte dei casi, l'aumento medio della latenza è inferiore a 500 millisecondi. Tuttavia, la latenza riscontrata può variare ed essere maggiore, a seconda del livello dell'hub IoT di Azure e dell'architettura della soluzione. È possibile monitorare la latenza usando le metriche dell’hub IoT di Azure Routing: message latency for messages/events o d2c.endpoints.latency.builtIn.events. La creazione o l'eliminazione di qualsiasi route dopo la prima non ha alcun impatto sulla latenza end-to-end.
Monitorare e risolvere i problemi
L'hub IoT di Azure fornisce diverse metriche correlate al routing e agli endpoint per offrire una panoramica dell'integrità dell'hub e dei messaggi inviati. Per un elenco di tutte le metriche dell'hub IoT di Azure suddivise per categoria funzionale, vedere la sezione Metriche di Monitoraggio delle informazioni di riferimento relative ai dati dell'hub IoT di Azure. È possibile tenere traccia degli errori che si verificano durante la valutazione di una query di routing e dell'integrità dell'endpoint in base a quanto rilevato dall'hub IoT di Azure tramite la categoria route nei registri delle risorse dell'hub IoT. Per altre informazioni sull'uso di metriche e log delle risorse con l'hub IoT di Azure, vedere Monitoraggio dell'hub IoT di Azure.
È possibile usare l'API REST Ottieni integrità endpoint per ottenere lo stato di integrità degli endpoint.
Usare la guida alla risoluzione dei problemi per il routing per altri dettagli e il supporto per la risoluzione dei problemi di routing.