Monitorowanie przetwarzania zdarzeń bezserwerowych

Ten artykuł zawiera wskazówki dotyczące monitorowania architektur opartych na zdarzeniach bezserwerowych .

Monitorowanie zapewnia wgląd w zachowanie i kondycję systemów. Ułatwia to tworzenie całościowego widoku środowiska, pobieranie trendów historycznych, korelowanie różnych czynników i mierzenie zmian wydajności, zużycia lub współczynnika błędów. Możesz użyć monitorowania, aby zdefiniować alerty, gdy wystąpią warunki, które mogą mieć wpływ na jakość usługi lub kiedy wystąpią warunki szczególnego zainteresowania dla określonego środowiska.

W tym artykule przedstawiono używanie usługi Azure Monitor do monitorowania bezserwerowej aplikacji utworzonej przy użyciu usług Event Hubs i Azure Functions. W tym artykule omówiono przydatne metryki do monitorowania, opisano sposób integracji z usługą Application Insights i przechwytywania metryk niestandardowych oraz przedstawiono przykłady kodu.

Założenia

W tym artykule założono, że masz architekturę podobną do architektury opisanej w architekturze referencyjnej przetwarzania zdarzeń bezserwerowych. Zasadzie:

• Zdarzenia docierają do usługi Azure Event Hubs.
• Aplikacja funkcji jest wyzwalana w celu obsługi zdarzenia.
• Usługa Azure Monitor jest dostępna do użycia z twoją architekturą.

Metryki z usługi Azure Monitor

Najpierw musimy zdecydować, które metryki będą potrzebne, zanim zaczniemy formułować przydatne szczegółowe informacje na temat architektury. Każdy zasób wykonuje różne zadania, a z kolei generuje różne metryki.

Te metryki z centrum zdarzeń będą interesujące w celu uzyskania przydatnych szczegółowych informacji:

• Żądania przychodzące
• Żądania wychodzące
• Żądania ograniczone
• Żądania zakończone powodzeniem
• Wiadomości przychodzące
• Wiadomości wychodzące
• Przechwycone komunikaty
• Bajty przychodzące
• Bajty wychodzące
• Przechwycone bajty
• Błędy użytkownika

Podobnie te metryki z usługi Azure Functions będą interesujące w celu uzyskania przydatnych szczegółowych informacji:

• Liczba wykonań funkcji
• Połączenia
• Dane w
• Dane wychodzące
• Błędy serwera HTTP
• Żądania
• Żądania w kolejce aplikacji
• Czas odpowiedzi

Używanie rejestrowania diagnostycznego do przechwytywania szczegółowych informacji

Podczas analizowania razem powyższe metryki mogą służyć do formułowania i przechwytywania następujących szczegółowych informacji:

• Szybkość żądań przetwarzanych przez usługę Event Hubs
• Szybkość żądań przetwarzanych przez usługę Azure Functions
• Łączna przepływność centrum zdarzeń
• Błędy użytkownika
• Czas trwania usługi Azure Functions
• Kompleksowe opóźnienie
• Opóźnienie na każdym etapie
• Liczba utraconych komunikatów
• Liczba komunikatów przetworzonych więcej niż raz

Aby upewnić się, że usługa Event Hubs przechwytuje niezbędne metryki, musimy najpierw włączyć dzienniki diagnostyczne (które są domyślnie wyłączone). Następnie musimy wybrać żądane dzienniki i skonfigurować odpowiedni obszar roboczy usługi Log Analytics jako miejsce docelowe.

Kategorie dzienników i metryk, które nas interesują, to:

• Dzienniki operacyjne
• Dzienniki automatycznego skalowania
• KafkaCoordinatorLogs (dla obciążeń platformy Apache Kafka)
• KafkaUserErrorLogs (dla obciążeń platformy Apache Kafka)
• EventHubVNetConnectionEvent
• Wszystkie metryki

Dokumentacja platformy Azure zawiera instrukcje dotyczące konfigurowania dzienników diagnostycznych dla centrum zdarzeń platformy Azure. Poniższy zrzut ekranu przedstawia przykładowy panel konfiguracji ustawień diagnostycznych z wybranymi prawidłowymi kategoriami dzienników i metryk oraz obszarem roboczym usługi Log Analytics ustawionym jako miejsce docelowe. (Jeśli system zewnętrzny jest używany do analizowania dzienników, opcja Zamiast tego można użyć strumienia do centrum zdarzeń).

Uwaga

Aby korzystać z diagnostyki dzienników w celu przechwytywania szczegółowych informacji, należy utworzyć centra zdarzeń w różnych przestrzeniach nazw. Jest to spowodowane ograniczeniem na platformie Azure.

Usługa Event Hubs ustawiona w danej przestrzeni nazw usługi Event Hubs jest reprezentowana w metrykach usługi Azure Monitor w wymiarze o nazwie EntityName. W witrynie Azure Portal dane dla określonego centrum zdarzeń zwykle można wyświetlić w tym wystąpieniu usługi Azure Monitor. Jednak gdy dane metryk są kierowane do diagnostyki dzienników, obecnie nie ma możliwości wyświetlania danych dla centrum zdarzeń przez filtrowanie wymiaru EntityName .

Aby obejść ten problem, tworzenie centrów zdarzeń w różnych przestrzeniach nazw ułatwia lokalizowanie metryk dla określonego centrum.

Korzystanie z usługi Application Insights

Usługę Application Insights można włączyć do przechwytywania metryk i niestandardowych danych telemetrycznych z usługi Azure Functions. Dzięki temu można zdefiniować analizę, która odpowiada Twoim celom, zapewniając inny sposób uzyskiwania ważnych szczegółowych informacji dla scenariusza przetwarzania zdarzeń bezserwerowych.

Ten zrzut ekranu przedstawia przykładowe zestawienie metryk niestandardowych i telemetrii w usłudze Application Insights:

Domyślne metryki niestandardowe

W usłudze Application Insights metryki niestandardowe dla usługi Azure Functions są przechowywane w customMetrics tabeli. Zawiera następujące wartości obejmujące oś czasu dla różnych wystąpień funkcji:

• AvgDurationMs
• MaxDurationMs
• MinDurationMs
• Successes
• Failures
• SuccessRate
• Count

Te metryki mogą służyć do efektywnego obliczania zagregowanych średnich w wielu wystąpieniach funkcji wywoływanych w przebiegu.

Ten zrzut ekranu przedstawia, jak wyglądają te domyślne metryki niestandardowe po wyświetleniu w usłudze Application Insights:

Komunikaty niestandardowe

Komunikaty niestandardowe zarejestrowane w kodzie funkcji platformy Azure (przy użyciu elementu ILogger) są uzyskiwane z tabeli usługi Application Insights traces .

Tabela traces ma następujące ważne właściwości (między innymi):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Oto przykład tego, jak może wyglądać niestandardowy komunikat w interfejsie usługi Application Insights:

Jeśli przychodzący komunikat centrum zdarzeń lub EventData[] jest rejestrowany jako część tego ILogger niestandardowego komunikatu, zostanie on również udostępniony w usłudze Application Insights. Może to być bardzo przydatne.

W naszym scenariuszu przetwarzania zdarzeń bezserwerowych rejestrujemy serializowaną treść komunikatu JSON odebraną z centrum zdarzeń. Dzięki temu możemy przechwytywać nieprzetworzone tablice bajtów wraz z elementami SystemPropertiesx-opt-sequence-number, x-opt-offseti x-opt-enqueued-time. Aby określić, kiedy każdy komunikat został odebrany przez centrum zdarzeń, x-opt-enqueued-time używana jest właściwość .

Przykładowe zapytanie:

traces
| where timestamp between(min_t .. max_t)
| where message contains "Body"
| extend m = parse_json(message))
| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])

Przykładowe zapytanie zwróci komunikat podobny do poniższego przykładowego wyniku, który domyślnie jest rejestrowany w usłudze Application Insights. Właściwości Trigger Details obiektu mogą służyć do lokalizowania i przechwytywania dodatkowych szczegółowych informacji dotyczących odebranych komunikatów na PartitionId, Offseti SequenceNumber.

Przykładowy wynik przykładowego zapytania:

"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,

Ostrzeżenie

Biblioteka usługi Azure Java Functions ma obecnie problem uniemożliwiający dostęp do elementu PartitionID i PartitionContext podczas korzystania z usługi EventHubTrigger. Dowiedz się więcej w tym raporcie o problemach z usługą GitHub.

Śledzenie przepływu komunikatów przy użyciu identyfikatora transakcji w usłudze Application Insights

W usłudze Application Insights możemy wyświetlić wszystkie dane telemetryczne związane z określoną transakcją, wykonując zapytanie wyszukiwania transakcji na wartości transakcji Operation Id . Może to być szczególnie przydatne w przypadku przechwytywania wartości percentylu średniego czasu dla komunikatów, gdy transakcja przechodzi przez potok strumienia zdarzeń.

Poniższy zrzut ekranu przedstawia przykładowe wyszukiwanie transakcji w interfejsie usługi Application Insights. Żądany element Operation ID jest wprowadzany w polu zapytania, identyfikowany za pomocą ikony lupy (i pokazany tutaj w czerwonym polu). W dolnej części okienka głównego karta Results pokazuje pasujące zdarzenia w kolejności sekwencyjnej. W każdym wpisie zdarzenia wartość jest wyróżniona Operation ID w ciemnoniebieskim, aby ułatwić weryfikację.

Zapytanie wygenerowane dla określonego identyfikatora operacji będzie wyglądać następująco. Należy pamiętać, że Operation ID identyfikator GUID jest określony w klauzuli where * has trzeciego wiersza. W tym przykładzie dokładniej zawężamy zapytanie między dwoma różnymi datetimeselementami .

union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies
| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")
| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"
| order by timestamp desc
| take 100

Oto zrzut ekranu przedstawiający, jak zapytanie i jego pasujące wyniki mogą wyglądać w interfejsie usługi Application Insights:

Przechwytywanie metryk niestandardowych z usługi Azure Functions

Funkcje platformy .NET

Rejestrowanie strukturalne jest używane w funkcjach platformy Azure platformy .NET do przechwytywania wymiarów niestandardowych w tabeli śledzenia usługi Application Insights. Te wymiary niestandardowe mogą być następnie używane do wykonywania zapytań dotyczących danych.

Na przykład poniżej przedstawiono instrukcję dziennika na platformie .NET TransformingFunction:

log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +
    "partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +
    "inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +
    "transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",
    sensorDataJson,
    partitionId,
    offset,
    enqueuedTimeUtc,
    inputEH_enqueuedTime,
    processedTime,
    transformingLatency,
    processingLatency);

Wynikowe dzienniki utworzone w usłudze Application Insights zawierają powyższe parametry jako wymiary niestandardowe, jak pokazano na poniższym zrzucie ekranu:

Te dzienniki można wykonywać w następujący sposób:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name == "{Function_Name}"
| where message has "{Function_Name}: Processed"
| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)

Uwaga

Aby upewnić się, że nie wpływamy na wydajność tych testów, włączyliśmy ustawienia próbkowania dzienników funkcji platformy Azure dla usługi Application Insights przy użyciu host.json pliku, jak pokazano poniżej. Oznacza to, że wszystkie statystyki przechwycone z rejestrowania są uważane za średnie wartości, a nie rzeczywiste liczby.

host.json przykład:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Funkcje języka Java

Obecnie rejestrowanie strukturalne nie jest obsługiwane w funkcjach platformy Azure w języku Java na potrzeby przechwytywania wymiarów niestandardowych w tabeli śladów usługi Application Insights.

Na przykład poniżej przedstawiono instrukcję dziennika w języku Java TransformingFunction:

LoggingUtilities.logSuccessInfo(
    context.getLogger(), 
    "TransformingFunction", 
    "SuccessInfo", 
    offset, 
    processedTimeString, 
    dateformatter.format(enqueuedTime), 
    transformingLatency
);

Wynikowe dzienniki utworzone w usłudze Application Insights zawierają powyższe parametry w komunikacie, jak pokazano poniżej:

Te dzienniki można wykonywać w następujący sposób:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name in ("{Function name}") and message contains "SuccessInfo"
| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))

Uwaga

Aby upewnić się, że nie wpływamy na wydajność tych testów, włączyliśmy ustawienia próbkowania dzienników funkcji platformy Azure dla usługi Application Insights przy użyciu host.json pliku, jak pokazano poniżej. Oznacza to, że wszystkie statystyki przechwycone z rejestrowania są uważane za średnie wartości, a nie rzeczywiste liczby.

host.json przykład:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Współautorzy

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

Główny autor:

• Rajasa Savant | Starszy inżynier oprogramowania

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Powiązane zasoby

• Przetwarzanie zdarzeń bezserwerowych to architektura referencyjna, która szczegółowo opisuje typową architekturę tego typu, z przykładami kodu i omówieniem ważnych zagadnień.
• Scenariusz usługi Private Link w przetwarzaniu strumienia zdarzeń to rozwiązanie służące do implementowania podobnej architektury w sieci wirtualnej z prywatnymi punktami końcowymi w celu zwiększenia bezpieczeństwa.
• Usługa Azure Kubernetes w przetwarzaniu strumienia zdarzeń opisuje odmianę architektury opartej na zdarzeniach bezserwerowych działających na platformie Azure Kubernetes ze skalowaniem KEDA.