Monitorowanie Azure Functions i usługi Event Hubs

Monitorowanie zapewnia wgląd w zachowanie i kondycję systemów oraz pomaga w tworzeniu całościowego widoku środowiska, historycznych trendów, korelowania różnych czynników oraz mierzenia zmian wydajności, zużycia lub szybkości błędów.

Azure Functions oferuje wbudowaną integrację z usługą Application Insights. W usłudze Application Insights można uzyskać informacje, takie jak liczba wystąpień aplikacji funkcji lub telemetria żądań i zależności funkcji. Podczas pracy z usługami Functions i Event Hubs usługa Application Insights może również śledzić wychodzące dane telemetryczne zależności do centrum zdarzeń, obliczając czas spędzony w kolejce i pokazujący pełny przepływ systemu połączonego za pośrednictwem usługi Event Hubs.

W tej sekcji przedstawiono przydatne funkcje i szczegółowe informacje, które można pobrać z usługi Application Insights dla usługi Event Hubs i rozwiązania usługi Functions.

Mapa aplikacji

Mapa aplikacji pokazuje, jak składniki w systemie współdziałają ze sobą. Ze względu na dane telemetryczne zależności zapewniane przez usługę Application Insights są mapowane przepływ zdarzeń między Azure Functions a usługą Event Hubs, w tym średni średni czas wykonywania każdej funkcji i średni czas trwania zdarzenia w usłudze Event Hubs, a także przedstawia transakcje zawierające błędy oznaczone kolorem czerwonym.

Po wysłaniu oczekiwanego obciążenia do systemu możesz przejść do usługi Application Insights w Azure Portal, a na pasku bocznym wybierz pozycję Mapa aplikacji. Oto mapa przedstawiająca trzy funkcje, trzy centra zdarzeń i widoczne błędy podczas zapisywania w podrzędnej bazie danych:

Szczegóły transakcji kompleksowej

Szczegółowe informacje o transakcji kompleksowej pokazują, jak składniki systemu współdziałają ze sobą w kolejności chronologicznej. Ten widok pokazuje również, jak długo zdarzenie zostało spędzone w kolejce. Możesz również przejść do szczegółów telemetrii każdego składnika z tego widoku, co ułatwia rozwiązywanie problemów między składnikami w ramach tego samego żądania po wystąpieniu problemu.

Metryki i telemetria platformy

Metryki generowane przez platformę w usłudze Azure Monitor dla usługi Event Hubs i Azure Functions mogą być używane do ogólnego monitorowania zachowania i kondycji rozwiązania:

• Azure Event Hubs metryki w usłudze Azure Monitor są interesujące w celu przechwycenia przydatnych szczegółowych informacji dotyczących usługi Event Hubs (na przykład agregacji żądań przychodzących, żądań wychodzących, żądań ograniczonych, żądań zakończonych powodzeniem, komunikatów przychodzących, przechwyconych komunikatów, bajtów przychodzących, bajtów wychodzących, przechwyconych bajtów, błędów użytkownika).

• Azure Functions metryki współdzielą wiele metryk z Azure App Service, a dodanie liczby wykonywania funkcji i jednostek wykonywania funkcji, których można użyć do zrozumienia wykorzystania i kosztu planu zużycie. Inne metryki zainteresowania to Połączenia, Dane w, Dane wychodzące, Średni zestaw roboczy pamięci, Liczba wątków, Żądania i Czas odpowiedzi.

Azure Functions integruje się z usługą Application Insights, aby zapewnić zaawansowane i szczegółowe dane telemetryczne oraz szczegółowe informacje o hostach i wykonaniach funkcji usługi Functions. Aby dowiedzieć się więcej, zobacz Analizowanie Azure Functions telemetrii w usłudze Application Insights. W przypadku korzystania z usługi Application Insights do monitorowania topologii dostępnych jest wiele konfiguracji. Aby dowiedzieć się więcej, zobacz Jak skonfigurować monitorowanie dla Azure Functions.

Poniżej przedstawiono przykład dodatkowych danych telemetrycznych dla funkcji wyzwalanych przez usługę Event Hubs wygenerowanych w tabeli śladów :

Trigger Details: PartionId: 6, Offset: 3985758552064-3985758624640, EnqueueTimeUtc: 2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00, SequenceNumber: 3712266-3712275, Count: 10

Te informacje wymagają użycia rozszerzenia Event Hubs w wersji 4.2.0 lub nowszej. Te dane są bardzo przydatne, ponieważ zawierają informacje o komunikacie, który wyzwolił wykonywanie funkcji i może służyć do wykonywania zapytań i szczegółowych informacji. Zawiera ona następujące dane za każdym razem, gdy funkcja jest wyzwalana:

• Identyfikator partycji (6)
• Zakres przesunięcia partycji (3985758552064-3985758624640)
• Zakres czasu kolejki w formacie UTC (2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00)
• Zakres numerów sekwencji 3712266-3712275
• Liczba komunikatów (10)

Zapoznaj się z sekcją Przykładowe zapytania usługi Application Insights , aby zapoznać się z przykładami dotyczącymi używania tej telemetrii.

Niestandardowa telemetria jest również możliwa dla różnych języków (biblioteka klas C#, C# Izolowane, Skrypt języka C#, JavaScript, Java, PowerShell i Python). To rejestrowanie jest wyświetlane w tabeli śladów w usłudze Application Insights. Możesz utworzyć własne wpisy w usłudze Application Insights i dodać niestandardowe wymiary, których można użyć do wykonywania zapytań o dane i tworzenia niestandardowych pulpitów nawigacyjnych.

Na koniec, gdy aplikacja funkcji łączy się z centrum zdarzeń przy użyciu powiązania wyjściowego, wpisy są również zapisywane w tabeli Zależności usługi Application Insights.

W przypadku usługi Event Hubs korelacja jest wprowadzana do ładunku zdarzenia, a właściwość Diagnostic-Id jest widoczna w zdarzeniach:

Jest to zgodne z formatem kontekstu śledzenia W3C , który jest również używany jako łącza identyfikatora operacji i operacji w telemetrii utworzonej przez funkcje, co umożliwia usłudze Application Insights konstruowanie korelacji między zdarzeniami centrum zdarzeń i wykonywaniami funkcji, nawet w przypadku ich dystrybucji.

Przykładowe zapytania usługi Application Insights

Poniżej znajduje się lista przydatnych zapytań usługi Application Insights podczas monitorowania usługi Event Hubs za pomocą Azure Functions. To zapytanie wyświetla szczegółowe informacje dotyczące funkcji wyzwalanej przez centrum zdarzeń przy użyciu telemetrii emitowanej przez rozszerzenie usługi Event Hubs w wersji 4.2.0 i nowszej.

Po włączeniu próbkowania w usłudze Application Insights mogą występować luki w danych.

Szczegółowe informacje o przetwarzaniu zdarzeń

Dane są emitowane tylko w poprawnym formacie, gdy jest używana wysyłka wsadowa. Wysyłanie wsadowe oznacza, że funkcja akceptuje wiele zdarzeń dla każdego wykonania, co jest zalecane w celu zapewnienia wydajności. Należy pamiętać o następujących kwestiach:

• Wartość dispatchTimeMilliseconds jest przybliżona czas między zapisem zdarzenia w centrum zdarzeń a odebraniem go przez aplikację funkcji do przetwarzania.
• dispatchTimeMilliseconds może być ujemne lub w inny sposób niedokładne z powodu dryfu zegara między serwerem centrum zdarzeń a aplikacją funkcji.
• Partycje usługi Event Hubs są przetwarzane sekwencyjnie. Komunikat nie zostanie wysłany do kodu funkcji do przetworzenia do momentu przetworzenia wszystkich poprzednich komunikatów. Monitorowanie czasu wykonywania funkcji w miarę dłuższych czasów wykonywania spowoduje opóźnienia wysyłania.
• Obliczenie używa enqueueTime pierwszego komunikatu w partii. Czasy wysyłania mogą być niższe dla innych komunikatów w partii.
• dispatchTimeMilliseconds jest oparta na punkcie w czasie.
• Numery sekwencji są na partycje, a przetwarzanie duplikatów może wystąpić, ponieważ usługa Event Hubs nie gwarantuje dokładnie jednokrotnego dostarczania komunikatów.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| project timestamp, cloud_RoleInstance, operation_Name, processId =
customDimensions.ProcessId, partitionId, messageCount, sequenceNumberStart,
sequenceNumberEnd, enqueueTimeStart, enqueueTimeEnd, dispatchTimeMilliseconds

Wizualizacja opóźnienia wysyłania

To zapytanie wizualizuje 50. i 90. percentylowe opóźnienie wysyłania zdarzeń dla danej funkcji wyzwalanej przez centrum zdarzeń. Zobacz powyższe zapytanie, aby uzyskać więcej szczegółów i notatek.

traces
| where operation_Name == "<ENTER THE NAME OF YOUR FUNCTION HERE>"
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize percentiles(dispatchTimeMilliseconds, 50, 90) by bin(timestamp, 5m)
| render timechart

Podsumowanie opóźnienia wysyłania

To zapytanie jest podobne do powyższego, ale wyświetla widok podsumowania.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize messageCount = sum(messageCount),
percentiles(dispatchTimeMilliseconds, 50, 90, 99, 99.9, 99.99) by operation_Name

Dystrybucja komunikatów między partycjami

To zapytanie pokazuje, jak wizualizować dystrybucję komunikatów między partycjami.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked

Dystrybucja komunikatów między wystąpieniami

To zapytanie pokazuje, jak wizualizować dystrybucję komunikatów między wystąpieniami.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked

Wykonywanie wystąpień i przydzielonych wystąpień

To zapytanie pokazuje, jak wizualizować liczbę wystąpień Azure Functions, które przetwarzają zdarzenia z usługi Event Hubs, oraz łączną liczbę wystąpień (przetwarzanie i oczekiwanie na dzierżawę). Większość czasu powinna być taka sama.

traces
| where message startswith "Trigger Details: Parti"
| summarize type = "Executing Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
| union (
    traces
    | summarize type = "Allocated Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
)
| project timestamp, type, Count
| render timechart

Wszystkie dane telemetryczne dla określonego wykonywania funkcji

Pole operation_Id można używać w różnych tabelach w usłudze Application Insights. W przypadku usługi Event Hubs wyzwolonych Azure Functions następujące zapytanie spowoduje na przykład wyświetlenie informacji o wyzwalaczu, dane telemetryczne z dzienników wewnątrz kodu funkcji oraz zależności i wyjątki:

union isfuzzy=true requests, exceptions, traces, dependencies
| where * has "<ENTER THE OPERATION_ID OF YOUR FUNCTION EXECUTION HERE>"
| order by timestamp asc

Kompleksowe opóźnienie zdarzenia

Ponieważ właściwość enqueueTimeUtc w śladzie szczegółów wyzwalacza pokazuje czas kolejkowania tylko pierwszego zdarzenia każdej partii przetworzonej przez funkcję, bardziej zaawansowane zapytanie może służyć do obliczania kompleksowego opóźnienia zdarzeń między dwiema funkcjami z usługą Event Hubs między. To zapytanie rozszerzy łącza operacji (jeśli istnieją) w żądaniu drugiej funkcji i zamapuje czas zakończenia na ten sam odpowiadający identyfikator operacji pierwszego uruchomienia funkcji.

let start = view(){
requests
| where operation_Name == "FirstFunction"
| project start_t = timestamp, first_operation_Id = operation_Id
};
let link = view(){
requests
| where operation_Name == "SecondFunction"
| mv-expand ex = parse_json(tostring(customDimensions["_MS.links"]))
| extend parent = case(isnotempty(ex.operation_Id), ex.operation_Id, operation_Id )
| project first_operation_Id = parent, second_operation_Id = operation_Id
};
let finish = view(){
traces
| where customDimensions["EventName"] == "FunctionCompleted" and operation_Name
== "SecondFunction"
| project end_t = timestamp, second_operation_Id = operation_Id
};
start
| join kind=inner (
link
| join kind=inner finish on second_operation_Id
) on first_operation_Id
| project start_t, end_t, first_operation_Id, second_operation_Id
| summarize avg(datetime_diff('second', end_t, start_t))

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• David Barkol | Główny specjalista ds. rozwiązań GBB

Aby wyświetlić niepubliowe profile usługi LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Aby dowiedzieć się więcej, rozważ przejrzenie następujących powiązanych artykułów:

• Monitorowanie przetwarzania zdarzeń bezserwerowych
• Analizowanie danych telemetrycznych Azure Functions w usłudze Application Insights
• Konfigurowanie monitorowania dla Azure Functions
• Analizowanie danych telemetrycznych Azure Functions w usłudze Application Insights
• Metryki w usłudze Azure Monitor — Azure Event Hubs
• Język zapytań Kusto

Powiązane zasoby

• Monitorowanie przetwarzania zdarzeń bezserwerowych zawiera wskazówki dotyczące monitorowania architektur opartych na zdarzeniach bezserwerowych.
• Przetwarzanie zdarzeń bezserwerowych to architektura referencyjna opisując typową architekturę tego typu, z przykładami kodu i omówieniem ważnych zagadnień.
• De-batching and filtering in serverless event processing with Event Hubs (Odsadanie i filtrowanie w przetwarzaniu zdarzeń bezserwerowych za pomocą usługi Event Hubs ) opisuje bardziej szczegółowo sposób działania tych fragmentów architektury referencyjnej.