Źródła zdarzeń usługi Azure Time Series Insights Gen2

Uwaga

Usługa Time Series Insights zostanie wycofana 7 lipca 2024 r. Rozważ migrację istniejących środowisk do alternatywnych rozwiązań tak szybko, jak to możliwe. Aby uzyskać więcej informacji na temat wycofywania i migracji, odwiedź naszą dokumentację.

Środowisko usługi Azure Time Series Insights Gen2 może mieć maksymalnie dwa źródła zdarzeń przesyłania strumieniowego. Dwa typy zasobów platformy Azure są obsługiwane jako dane wejściowe:

• Azure IoT Hub
• Azure Event Hubs

Zdarzenia muszą być wysyłane jako kodowane w formacie UTF-8 JSON.

Tworzenie lub edytowanie źródeł zdarzeń

Źródłem zdarzeń jest połączenie między centrum i środowiskiem usługi Azure Time Series Insights Gen2, a w grupie zasobów zostanie utworzony oddzielny zasób typu Time Series Insights event source . Zasoby usługi IoT Hub lub Event Hub mogą znajdować się w tej samej subskrypcji platformy Azure co środowisko usługi Azure Time Series Insights Gen2 lub inna subskrypcja. Jednak najlepszym rozwiązaniem jest house your Azure Time Series Insights environment and the IoT Hub or Event Hub w tym samym regionie świadczenia usługi Azure.

Za pomocą witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, szablonów usługi Azure Resource Manager i interfejsu API REST można tworzyć, edytować lub usuwać źródła zdarzeń środowiska.

Ostrzeżenie

Nie ograniczaj publicznego dostępu do Internetu do centrum lub źródła zdarzeń używanego przez usługę Time Series Insights lub wymagane połączenie zostanie przerwane.

Opcje uruchamiania

Podczas tworzenia źródła zdarzeń można określić, jakie dane mają być zbierane wstępnie istniejące. To ustawienie jest opcjonalne. Dostępne są następujące opcje:

Nazwa/nazwisko	opis	Przykład szablonu usługi Azure Resource Manager
Najwcześniejsza niedostępna	Pozyskiwanie wszystkich istniejących wcześniej danych przechowywanych w rozwiązaniu IoT lub centrum zdarzeń	"ingressStartAt": {"type": "EarliestAvailable"}
EventSourceCreationTime	Rozpoczęcie pozyskiwania danych dostarczonych po utworzeniu źródła zdarzenia. Wszystkie istniejące wcześniej dane, które były przesyłane strumieniowo przed utworzeniem źródła zdarzenia, zostaną zignorowane. Jest to ustawienie domyślne w witrynie Azure Portal	"ingressStartAt": {"type": "EventSourceCreationTime"}
CustomEnqueuedTime	Twoje środowisko pozyska dane z niestandardowego czasu dodania do kolejki (UTC) do przodu. Wszystkie zdarzenia, które zostały dodane do kolejki rozwiązania IoT lub centrum zdarzeń w trakcie lub po upływie niestandardowego czasu dodania do kolejki, zostaną przechowane i zapisane. Wszystkie zdarzenia, które zostały dostarczone przed rozpoczęciem niestandardowego czasu dodania do kolejki, zostaną zignorowane. Należy pamiętać, że "czas w kolejce" odnosi się do czasu (w formacie UTC), o który zdarzenie dotarło do usługi IoT lub Event Hub. Różni się to od niestandardowej właściwości znacznika czasu, która znajduje się w treści zdarzenia.	"ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"}

Ważne

• Jeśli wybierzesz pozycję Najwcześniejsza dostępność i masz wiele wstępnie istniejących danych, może wystąpić duże opóźnienie początkowe, ponieważ środowisko usługi Azure Time Series Insights Gen2 przetwarza wszystkie dane.
• To duże opóźnienie powinno ostatecznie ustąpić w miarę indeksowania danych. Prześlij bilet pomocy technicznej za pośrednictwem witryny Azure Portal, jeśli występują ciągłe duże opóźnienia.

• Najwcześniejsza niedostępna

• EventSourceCreationTime

• CustomEnqueuedTime

Najlepsze rozwiązania dotyczące pozyskiwania danych przesyłanych strumieniowo

• Zawsze twórz unikatową grupę odbiorców dla środowiska usługi Azure Time Series Insights Gen2, aby korzystać z danych ze źródła zdarzeń. Ponowne wykorzystanie grup odbiorców może spowodować losowe rozłączenia i może spowodować utratę danych.

• Skonfiguruj środowisko usługi Azure Time Series Insights Gen2 oraz usługę IoT Hub i/lub Event Hubs w tym samym regionie świadczenia usługi Azure. Chociaż możliwe jest skonfigurowanie źródła zdarzeń w osobnym regionie, ten scenariusz nie jest obsługiwany i nie możemy zagwarantować wysokiej dostępności.

• Nie przekraczaj limitu szybkości przepływności środowiska ani limitu liczby partycji.

• Skonfiguruj alert opóźnienia, aby otrzymywać powiadomienia, jeśli środowisko ma problemy z przetwarzaniem danych. Zobacz Obciążenia produkcyjne poniżej, aby uzyskać sugerowane warunki alertu.

• Użyj pozyskiwania danych przesyłanych strumieniowo tylko w czasie zbliżonym do rzeczywistego i ostatnich, przesyłanie strumieniowe danych historycznych nie jest obsługiwane.

• Dowiedz się, w jaki sposób właściwości zostaną usunięte i dane JSON spłaszczone i przechowywane.

• Przestrzegaj zasady najniższych uprawnień podczas udostępniania parametry połączenia źródła zdarzeń. W przypadku usługi Event Hubs skonfiguruj zasady dostępu współdzielonego tylko z oświadczeniem wysyłania, a w przypadku usługi IoT Hub użyj tylko uprawnień połączenia z usługą.

Uwaga

Jeśli usuniesz centrum IoT Hub lub centrum zdarzeń i ponownie utworzysz nowy zasób o tej samej nazwie, musisz utworzyć nowe źródło zdarzeń i dołączyć nowe centrum IoT Hub lub centrum zdarzeń. Dane nie zostaną pozyskane do momentu ukończenia tego kroku.

Obciążenia produkcyjne

Oprócz powyższych najlepszych rozwiązań zalecamy zaimplementowanie następujących rozwiązań w przypadku obciążeń o krytycznym znaczeniu dla działania firmy.

• Zwiększ czas przechowywania danych usługi IoT Hub lub centrum zdarzeń do maksymalnie siedmiu dni.

• Tworzenie alertów środowiska w witrynie Azure Portal. Alerty oparte na metrykach platformy umożliwiają weryfikowanie zachowania kompleksowego potoku. Instrukcje dotyczące tworzenia alertów i zarządzania nimi znajdują się tutaj. Sugerowane warunki alertu:

  • IngressReceivedMessagesTimeLag jest dłuższy niż 5 minut
  • Liczba bajtów ruchu przychodzącego to 0

• Zachowaj równowagę obciążenia pozyskiwania między partycjami usługi IoT Hub lub Centrum zdarzeń.

Pozyskiwanie danych historycznych

Importowanie danych historycznych przy użyciu potoku przesyłania strumieniowego nie jest obecnie obsługiwane w usłudze Azure Time Series Insights Gen2. Jeśli musisz zaimportować wcześniejsze dane do środowiska, postępuj zgodnie z poniższymi wytycznymi:

• Nie przesyłaj strumieniowo danych na żywo i historycznych równolegle. Pozyskiwanie danych z zamówienia spowoduje obniżenie wydajności zapytań.
• Pozyskiwanie danych historycznych w sposób uporządkowany w czasie w celu uzyskania najlepszej wydajności.
• Bądź w granicach poniższych limitów szybkości przepływności pozyskiwania.
• Wyłącz ciepły magazyn, jeśli dane są starsze niż okres przechowywania ciepłego magazynu.

Sygnatura czasowa źródła zdarzeń

Podczas konfigurowania źródła zdarzeń zostanie wyświetlony monit o podanie właściwości identyfikatora sygnatury czasowej. Właściwość znacznika czasu służy do śledzenia zdarzeń w czasie. Jest to czas, który będzie używany jako znacznik $ts czasu w interfejsach API zapytań i do kreślenia serii w Eksploratorze usługi Azure Time Series Insights. Jeśli w czasie tworzenia nie podano żadnej właściwości lub jeśli w zdarzeniu brakuje właściwości sygnatury czasowej, zostanie użyta wartość domyślna dla usługi IoT Hub lub Events Hubs. Wartości właściwości sygnatury czasowej są przechowywane w formacie UTC.

Ogólnie rzecz biorąc, użytkownicy zdecydują się dostosować właściwość znacznika czasu i użyć czasu, gdy czujnik lub tag wygenerował odczyt, zamiast używać domyślnego czasu w kolejce koncentratora. Jest to szczególnie konieczne, gdy urządzenia mają sporadyczną utratę łączności, a partia opóźnionych komunikatów jest przesyłana do usługi Azure Time Series Insights Gen2.

Jeśli niestandardowy znacznik czasu znajduje się w zagnieżdżonym obiekcie JSON lub tablicy, musisz podać poprawną nazwę właściwości zgodnie z naszą spłaszczaną konwencją nazewnictwa i ucieczką. Na przykład sygnatura czasowa źródła zdarzeń dla ładunku JSON pokazanego tutaj powinna zostać wprowadzona jako "values.time".

Przesunięcia strefy czasowej

Znaczniki czasu muszą być wysyłane w formacie ISO 8601 i będą przechowywane w formacie UTC. Jeśli zostanie podane przesunięcie strefy czasowej, przesunięcie zostanie zastosowane, a następnie czas przechowywany i zwracany w formacie UTC. Jeśli przesunięcie jest nieprawidłowo sformatowane, zostanie zignorowane. W sytuacjach, w których rozwiązanie może nie mieć kontekstu oryginalnego przesunięcia, możesz wysłać dane przesunięcia w dodatkowej oddzielnej właściwości zdarzenia, aby upewnić się, że jest ona zachowana i że aplikacja może odwoływać się do odpowiedzi na zapytanie.

Przesunięcie strefy czasowej powinno być sformatowane jako jedno z następujących elementów:

±HMMZ
±HH:MM
±HH:MMZ

Następne kroki

• Przeczytaj reguły spłaszczania i ucieczki w formacie JSON, aby dowiedzieć się, jak będą przechowywane zdarzenia.

• Omówienie ograniczeń przepływności środowiska