Azure Time Series Insights Gen2-Ereignisquellen
Anmerkung
Der Time Series Insights-Dienst wird am 7. Juli 2024 eingestellt. Erwägen Sie, vorhandene Umgebungen so schnell wie möglich zu alternativen Lösungen zu migrieren. Weitere Informationen zur Einstellung und zur Migration finden Sie in unserer Dokumentation.
Ihre Azure Time Series Insights Gen2-Umgebung kann bis zu zwei Streaming-Ereignisquellen enthalten. Zwei Arten von Azure-Ressourcen werden als Eingaben unterstützt:
Ereignisse müssen als UTF-8-codiertes JSON gesendet werden.
Erstellen oder Bearbeiten von Ereignisquellen
Die Ereignisquelle ist die Verbindung zwischen Ihrem Hub und Ihrer Azure Time Series Insights Gen2-Umgebung, und eine separate Ressource vom Typ Time Series Insights event source
wird in Ihrer Ressourcengruppe erstellt. Die IoT Hub- oder Event Hub-Ressource(n) kann entweder im selben Azure-Abonnement wie Ihre Azure Time Series Insights Gen2-Umgebung untergebracht sein oder sich in einem anderen Abonnement befinden. Es ist jedoch eine bewährte Methode, Ihre Azure Time Series Insights-Umgebung und den IoT Hub oder Event Hub in derselben Azure-Region zu speichern.
Sie können das Azure-Portal, Azure CLI, Azure Resource Manager-Vorlagenund die REST-API- verwenden, um Ereignisquellen Ihrer Umgebung zu erstellen, zu bearbeiten oder zu entfernen.
Warnung
Beschränken Sie den öffentlichen Internetzugang nicht auf einen Hub oder eine Ereignisquelle, die von Time Series Insights verwendet wird, da sonst die notwendige Verbindung unterbrochen wird.
Startoptionen
Beim Erstellen einer Ereignisquelle können Sie angeben, welche bereits vorhandenen Daten erfasst werden sollen. Diese Einstellung ist optional. Die folgenden Optionen stehen zur Verfügung:
Name | Beschreibung | Azure Resource Manager-Vorlage (Beispiel) |
---|---|---|
Frühestverfügbar | Aufnehmen aller bereits vorhandenen Daten, die im IoT-Hub oder Event Hub gespeichert sind | "ingressStartAt": {"type": "EarliestAvailable"} |
EreignisquelleErstellungszeit | Starten Sie die Erfassung von Daten, die eingehen, nachdem die Ereignisquelle erstellt wurde. Alle bereits vorhandenen Daten, die vor der Erstellung der Ereignisquelle gestreamt wurden, werden ignoriert. Dies ist die Standardeinstellung im Azure-Portal. | "ingressStartAt": {"type": "EventSourceCreationTime"} |
BenutzerdefinierteWarteschlangenzeit | Ab Ihrer benutzerdefinierten eingereihten Zeit (UTC) werden Ihre Umgebung Daten erfassen. Alle Ereignisse, die in Ihrem IoT- oder Event Hub zu oder nach der benutzerdefinierten Einreihungszeit eingereiht wurden, werden aufgenommen und gespeichert. Alle Ereignisse, die vor Ihrer benutzerdefinierten eingereihten Zeit eintreffen, werden ignoriert. Beachten Sie, dass sich "enqueued time" auf den Zeitpunkt (in UTC) bezieht, zu dem das Ereignis in Ihrem IoT- oder Event Hub eingetroffen ist. Dies unterscheidet sich von einer benutzerdefinierten Timestamp-Eigenschaft, die sich im Textkörper Ihres Ereignisses befindet. | "ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"} |
Wichtig
- Wenn Sie "EarliestAvailable" auswählen und viele bereits vorhandene Daten haben, kann dies eine hohe anfängliche Latenz verursachen, da Ihre Azure Time Series Insights Gen2-Umgebung alle Ihre Daten verarbeitet.
- Diese hohe Latenz sollte im Laufe der Zeit nachlassen, da die Daten indiziert werden. Übermitteln Sie ein Supportticket über das Azure-Portal, wenn sie eine fortlaufende hohe Latenz erleben.
- Frühest verfügbar
- EreignisquelleErstellungszeit
- CustomEnqueuedTime
Bewährte Methoden für die Streaming-Datenaufnahme
Erstellen Sie immer eine eindeutige Verbrauchergruppe für Ihre Azure Time Series Insights Gen2-Umgebung, um Daten aus Ihrer Ereignisquelle zu nutzen. Die erneute Verwendung von Consumergruppen kann zu zufälligen Trennungen und Datenverlust führen.
Konfigurieren Sie Ihre Azure Time Series Insights Gen2-Umgebung und Ihre IoT Hub- und/oder Event Hubs in derselben Azure-Region. Obwohl es möglich ist, eine Ereignisquelle in einer separaten Region zu konfigurieren, wird dieses Szenario nicht unterstützt und wir können keine hohe Verfügbarkeit garantieren.
Gehen Sie nicht über die Durchsatzgrenze ihrer Umgebung hinaus, oder pro Partitionsgrenze.
Konfigurieren Sie eine Warnung für Verzögerung , um benachrichtigt zu werden, wenn in Ihrer Umgebung Probleme beim Verarbeiten von Daten auftreten. Unter Produktionsworkloads finden Sie unten Vorschläge für Alarmbedingungen.
Verwenden Sie Streaming-Aufnahme nur für nahezu Echtzeit- und aktuelle Daten; das Streamen historischer Daten wird nicht unterstützt.
Verstehen Sie, wie Eigenschaften maskiert werden und JSON--Daten abgeflacht und gespeichert werden.
Befolgen Sie das Prinzip der geringsten Berechtigungen beim Bereitstellen von Ereignisquellverbindungszeichenfolgen. Konfigurieren Sie für Event Hubs eine Richtlinie für den freigegebenen Zugriff nur mit dem senden Anspruch, und verwenden Sie für IoT Hub nur die Service Connect Berechtigung.
Vorsicht
Wenn Sie Ihren IoT Hub oder Event Hub löschen und eine neue Ressource mit demselben Namen erneut erstellen, müssen Sie eine neue Ereignisquelle erstellen und den neuen IoT Hub oder Event Hub anfügen. Daten werden erst aufgenommen, wenn Sie diesen Schritt abgeschlossen haben.
Produktionslasten
Zusätzlich zu den oben beschriebenen bewährten Methoden empfehlen wir, Folgendes für geschäftskritische Workloads zu implementieren.
Erhöhen Sie die Aufbewahrungszeit für IoT Hub- oder Event Hub-Daten auf maximal sieben Tage.
Erstellen Sie Umgebungswarnungen im Azure-Portal. Warnungen basierend auf plattformbasierten Metriken ermöglichen es Ihnen, das End-to-End-Pipelineverhalten zu überprüfen. Die Anweisungen zum Erstellen und Verwalten von Benachrichtigungen finden Sie hier. Vorgeschlagene Warnungsbedingungen:
- IngressReceivedMessagesTimeLag ist größer als 5 Minuten
- IngressReceivedBytes ist 0
Halten Sie die Belastung zwischen Ihren IoT Hub- oder Event Hub-Partitionen ausgeglichen.
Historische Datenintegration
Die Verwendung der Streamingpipeline zum Importieren von Verlaufsdaten wird derzeit in Azure Time Series Insights Gen2 nicht unterstützt. Wenn Sie vergangene Daten in Ihre Umgebung importieren müssen, befolgen Sie die folgenden Richtlinien:
- Streamen Sie live- und historische Daten nicht parallel. Das Verarbeiten von nicht in der richtigen Reihenfolge vorliegenden Daten führt zu einer beeinträchtigten Abfrageleistung.
- Historische Daten zeitlich geordnet aufnehmen, um die beste Leistung zu erzielen.
- Halten Sie sich an die Grenzwerte für die Aufnahmedurchsatzrate.
- Deaktivieren Sie "Warm Store", wenn die Daten älter als der Aufbewahrungszeitraum für den Warm Store sind.
Zeitstempel der Ereignisquelle
Beim Konfigurieren einer Ereignisquelle werden Sie aufgefordert, eine Timestamp-ID-Eigenschaft anzugeben. Die Timestamp-Eigenschaft wird verwendet, um Ereignisse im Laufe der Zeit zu verfolgen. Dies ist die Zeit, die als Zeitstempel $ts
in den Abfrage-APIs und zum Zeichnen von Datenreihen im Azure Time Series Insights-Explorer verwendet wird. Wenn zur Erstellungszeit keine Eigenschaft bereitgestellt wird oder die Timestamp-Eigenschaft in einem Ereignis fehlt, wird die Zeit, zu der das Ereignis in die Warteschlange des IoT-Hubs oder Event Hubs eingereiht wurde, als Standard verwendet. Zeitstempel-Eigenschaftswerte werden in UTC gespeichert.
Im Allgemeinen entscheiden sich Benutzer dafür, die Timestamp-Eigenschaft anzupassen und die Zeit zu verwenden, zu der der Sensor oder tag den Lesevorgang generiert hat, anstatt die standard-Hub-Queuedzeit zu verwenden. Dies ist besonders erforderlich, wenn Geräte zeitweiligen Verbindungsverlust haben und eine Reihe verzögerter Nachrichten an Azure Time Series Insights Gen2 weitergeleitet werden.
Wenn sich Ihr benutzerdefinierter Zeitstempel in einem geschachtelten JSON-Objekt oder einem Array befindet, müssen Sie den richtigen Eigenschaftsnamen gemäß unseren Flattening- und Escaping-Benennungskonventionenangeben. Der Zeitstempel der Ereignisquelle für die JSON-Nutzlast, die hier angezeigt wird, sollte beispielsweise als "values.time"
eingegeben werden.
Zeitzonenabweichungen
Zeitstempel müssen im ISO 8601-Format gesendet werden und werden in UTC gespeichert. Wenn ein Zeitzonenoffset bereitgestellt wird, wird der Offset angewendet, und die Zeit wird dann im UTC-Format gespeichert und zurückgegeben. Wenn der Offset nicht ordnungsgemäß formatiert ist, wird er ignoriert. In Situationen, in denen Ihre Lösung möglicherweise keinen Kontext des ursprünglichen Offsets aufweist, können Sie die Offset-Daten in einer zusätzlichen separaten Ereigniseigenschaft senden, damit sie beibehalten werden und damit Ihre Anwendung in einer Abfrageantwort darauf verweisen kann.
Der Zeitzonenoffset sollte wie folgt formatiert werden:
±HHMMZ
±HH:MM
±HH:MMZ
Nächste Schritte
Lesen Sie die Regeln für JSON-Flattening und Escaping und, um zu verstehen, wie Ereignisse gespeichert werden.