Udostępnij za pośrednictwem

Jak skonfigurować monitorowanie dla usługi Azure Functions

  • Artykuł

Usługa Azure Functions integruje się z usługą Application Insights, aby lepiej umożliwić monitorowanie aplikacji funkcji. Application Insights, funkcja usługi Azure Monitor, to rozszerzalna usługa zarządzania wydajnością aplikacji (APM), która zbiera dane generowane przez aplikację funkcji, w tym informacje zapisywane w dziennikach przez aplikację. Integracja z usługą Application Insights jest zwykle włączona podczas tworzenia aplikacji funkcji. Jeśli aplikacja nie ma ustawionego klucza instrumentacji, musisz najpierw włączyć integrację usługi Application Insights.

Usługi Application Insights można używać bez żadnej konfiguracji niestandardowej. Jednak domyślna konfiguracja może spowodować duże ilości danych. Jeśli używasz subskrypcji platformy Azure programu Visual Studio, możesz osiągnąć limit danych dla usługi Application Insights. Aby uzyskać informacje o kosztach usługi Application Insights, zobacz Rozliczenia usługi Application Insights. Aby uzyskać więcej informacji, zobacz Rozwiązania z dużą ilością danych telemetrycznych.

Z tego artykułu dowiesz się, jak skonfigurować i dostosować dane wysyłane przez funkcje do usługi Application Insights. Typowe konfiguracje rejestrowania można ustawić w pliku host.json. Domyślnie te ustawienia określają również dzienniki niestandardowe emitowane przez kod. Jednak w niektórych przypadkach takie zachowanie może być wyłączone na rzecz opcji, które zapewniają większą kontrolę nad rejestrowaniem. Aby uzyskać więcej informacji, zobacz Niestandardowe dzienniki aplikacji.

Uwaga

Możesz użyć specjalnie skonfigurowanych ustawień aplikacji do reprezentowania określonych ustawień w pliku host.json dla określonego środowiska. Dzięki temu można skutecznie zmieniać ustawienia host.json bez konieczności ponownego publikowania pliku host.json w projekcie. Aby uzyskać więcej informacji, zobacz Zastępowanie wartości pliku host.json.

Niestandardowe dzienniki aplikacji

Domyślnie zapisywane dzienniki aplikacji niestandardowych są wysyłane do hosta usługi Functions, który następnie wysyła je do usługi Application Insights w kategorii Proces roboczy. Niektóre stosy języków umożliwiają zamiast tego wysyłanie dzienników bezpośrednio do usługi Application Insights, co zapewnia pełną kontrolę nad sposobem emitowania dzienników. W takim przypadku potok rejestrowania zmienia się z worker -> Functions host -> Application Insights na worker -> Application Insights.

Poniższa tabela zawiera podsumowanie opcji konfiguracji dostępnych dla każdego stosu:

Stos języka Gdzie skonfigurować dzienniki niestandardowe
.NET (model w procesie) host.json
.NET (model izolowany) Ustawienie domyślne (wysyłanie dzienników niestandardowych do hosta usługi Functions): host.json
Aby wysyłać dzienniki bezpośrednio do usługi Application Insights, zobacz: Konfigurowanie usługi Application Insights w programie HostBuilder
Node.js host.json
Python host.json
Java Ustawienie domyślne (wysyłanie dzienników niestandardowych do hosta usługi Functions): host.json
Aby wysyłać dzienniki bezpośrednio do usługi Application Insights, zobacz: Konfigurowanie agenta Java usługi Application Insights
PowerShell host.json

Podczas konfigurowania dzienników aplikacji niestandardowych, które mają być wysyłane bezpośrednio, host nie emituje ich i host.json nie kontroluje już ich zachowania. Podobnie opcje uwidocznione przez każdy stos dotyczą tylko dzienników niestandardowych i nie zmieniają zachowania innych dzienników środowiska uruchomieniowego opisanych w tym artykule. W takim przypadku, aby kontrolować zachowanie wszystkich dzienników, może być konieczne wprowadzenie zmian w obu konfiguracjach.

Konfigurowanie kategorii

Rejestrator usługi Azure Functions zawiera kategorię dla każdego dziennika. Kategoria wskazuje, którą część kodu środowiska uruchomieniowego lub kodu funkcji zapisał dziennik. Kategorie różnią się w zależności od wersji 1.x i nowszych.

Nazwy kategorii są przypisywane inaczej w usłudze Functions w porównaniu z innymi platformami .NET. Na przykład w przypadku użycia ILogger<T> w ASP.NET kategoria jest nazwą typu ogólnego. Funkcje języka C# używają również funkcji ILogger<T>, ale zamiast ustawiać ogólną nazwę typu jako kategorię, środowisko uruchomieniowe przypisuje kategorie na podstawie źródła. Na przykład:

  • Wpisy związane z uruchamianiem funkcji są przypisywane do kategorii Function.<FUNCTION_NAME>.
  • Wpisy utworzone przez kod użytkownika wewnątrz funkcji, takie jak podczas wywoływania logger.LogInformation()metody , mają przypisaną kategorię Function.<FUNCTION_NAME>.User.

W poniższej tabeli opisano główne kategorie dzienników tworzonych przez środowisko uruchomieniowe:

Kategoria Table opis
Function Ślady Obejmuje uruchomione i ukończone dzienniki funkcji dla wszystkich przebiegów funkcji. W przypadku pomyślnych przebiegów te dzienniki są na Information poziomie. Wyjątki są rejestrowane na Error poziomie. Środowisko uruchomieniowe tworzy Warning również dzienniki na poziomie, takie jak w przypadku wysyłania komunikatów kolejki do kolejki trucizny.
Function.<YOUR_FUNCTION_NAME> Zależności Dane zależności są zbierane automatycznie dla niektórych usług. W przypadku pomyślnych przebiegów te dzienniki są na Information poziomie. Aby uzyskać więcej informacji, zobacz Zależności. Wyjątki są rejestrowane na Error poziomie. Środowisko uruchomieniowe tworzy Warning również dzienniki na poziomie, takie jak w przypadku wysyłania komunikatów kolejki do kolejki trucizny.
Function.<YOUR_FUNCTION_NAME> customMetrics
customEvents		 Zestawy SDK języka C# i JavaScript umożliwiają zbieranie metryk niestandardowych i rejestrowanie zdarzeń niestandardowych. Aby uzyskać więcej informacji, zobacz Niestandardowe dane telemetryczne.
Function.<YOUR_FUNCTION_NAME> Ślady Obejmuje uruchomione i ukończone dzienniki funkcji dla określonych przebiegów funkcji. W przypadku pomyślnych przebiegów te dzienniki są na Information poziomie. Wyjątki są rejestrowane na Error poziomie. Środowisko uruchomieniowe tworzy Warning również dzienniki na poziomie, takie jak w przypadku wysyłania komunikatów kolejki do kolejki trucizny.
Function.<YOUR_FUNCTION_NAME>.User Ślady Dzienniki generowane przez użytkownika, które mogą być dowolnym poziomem dziennika. Aby uzyskać więcej informacji na temat zapisywania dzienników z funkcji, zobacz Zapisywanie w dziennikach.
Host.Aggregator customMetrics Te dzienniki generowane przez środowisko uruchomieniowe zapewniają liczbę i średnie wywołań funkcji w konfigurowalnym okresie. Domyślny okres to 30 sekund lub 1000 wyników, w zależności od tego, co nastąpi wcześniej. Przykłady to liczba przebiegów, współczynnik powodzenia i czas trwania. Wszystkie te dzienniki są zapisywane na Information poziomie. Jeśli filtrujesz przy Warning lub wyższym poziomie, nie widzisz żadnych z tych danych.
Host.Results Żądania Te dzienniki generowane przez środowisko uruchomieniowe wskazują powodzenie lub niepowodzenie funkcji. Wszystkie te dzienniki są zapisywane na Information poziomie. Jeśli filtrujesz przy Warning lub wyższym poziomie, nie widzisz żadnych z tych danych.
Microsoft Ślady W pełni kwalifikowana kategoria dziennika, która odzwierciedla składnik środowiska uruchomieniowego platformy .NET wywoływany przez hosta.
Worker Ślady Dzienniki generowane przez proces roboczy języka dla języków non-.NET. Dzienniki procesów roboczych języka mogą być również rejestrowane w Microsoft.* kategorii, takiej jak Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. Te dzienniki są zapisywane na Information poziomie.

Uwaga

W przypadku funkcji biblioteki klas platformy .NET te kategorie zakładają, że używasz elementu ILogger , a nie ILogger<T>. Aby uzyskać więcej informacji, zobacz dokumentację usługi Functions ILogger.

Kolumna Tabela wskazuje, która tabela w usłudze Application Insights jest zapisywana w dzienniku.

Konfigurowanie poziomów dziennika

Poziom dziennika jest przypisywany do każdego dziennika. Wartość jest liczbą całkowitą wskazującą względną ważność:

PoziomRejestrowania Kod opis
Śledzenie 0 Dzienniki zawierające najbardziej szczegółowe komunikaty. Te komunikaty mogą zawierać poufne dane aplikacji. Te komunikaty są domyślnie wyłączone i nigdy nie powinny być włączone w środowisku produkcyjnym.
Debugowanie 1 Dzienniki używane do interaktywnego badania podczas opracowywania. Te dzienniki powinny zawierać przede wszystkim informacje przydatne do debugowania i nie mają długoterminowej wartości.
Informacja 2 Dzienniki śledzące ogólny przepływ aplikacji. Te dzienniki powinny mieć wartość długoterminową.
Ostrzeżenie 3 Dzienniki, które podkreślają nietypowe lub nieoczekiwane zdarzenie w przepływie aplikacji, ale nie powodują zatrzymania wykonywania aplikacji.
Błąd 100 Dzienniki, które podkreślają, kiedy bieżący przepływ wykonywania jest zatrzymany z powodu awarii. Te błędy powinny wskazywać błąd w bieżącym działaniu, a nie awarii całej aplikacji.
Krytyczne 5 Dzienniki opisujące nieodwracalną awarię aplikacji lub systemu albo katastrofalne awarie, które wymagają natychmiastowej uwagi.
Brak 6 Wyłącza rejestrowanie dla określonej kategorii.

Konfiguracja pliku host.json określa, ile rejestrowania aplikacja funkcji wysyła do usługi Application Insights.

Dla każdej kategorii należy wskazać minimalny poziom dziennika do wysłania. Ustawienia host.json różnią się w zależności od wersji środowiska uruchomieniowego usługi Functions.

W poniższych przykładach zdefiniowano rejestrowanie na podstawie następujących reguł:

  • Domyślny poziom rejestrowania jest ustawiony tak, aby Warning zapobiec nadmiernemu rejestrowaniu dla nieprzewidzianych kategorii.
  • Host.Aggregator i Host.Results są ustawione na niższe poziomy. Ustawienie zbyt wysokich poziomów rejestrowania (szczególnie wyższych niż Information) może spowodować utratę metryk i danych wydajności.
  • Rejestrowanie przebiegów funkcji jest ustawione na Informationwartość . W razie potrzeby można zastąpić to ustawienie w środowisku lokalnym do Debug lub Trace.
{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

Jeśli host.json zawiera wiele dzienników rozpoczynających się od tego samego ciągu, bardziej zdefiniowane dzienniki są najpierw dopasowane. Rozważmy następujący przykład, który rejestruje wszystkie elementy w środowisku uruchomieniowym, z wyjątkiem Host.Aggregator, na Error poziomie :

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Information",
      "Host": "Error",
      "Function": "Error",
      "Host.Aggregator": "Information"
    }
  }
}

Możesz użyć ustawienia poziomu dziennika , None aby zapobiec zapisywaniu dzienników dla kategorii.

Uwaga

Usługa Azure Functions integruje się z usługą Application Insights, przechowując zdarzenia telemetrii w tabelach usługi Application Insights. Jeśli ustawisz poziom dziennika kategorii na dowolną wartość inną niż Information, uniemożliwia to przepływ danych telemetrycznych do tych tabel i nie będzie można wyświetlić powiązanych danych na kartach Application Insights i Monitor funkcji.

Na przykład dla poprzednich przykładów:

  • Jeśli ustawisz kategorię Host.Results na Error poziom dziennika, platforma Azure zbiera tylko zdarzenia telemetrii wykonywania hosta w requests tabeli dla nieudanych wykonań funkcji, co uniemożliwia wyświetlanie szczegółów wykonywania hosta zakończonych powodzeniem zarówno na kartach Application Insights , jak i Monitor funkcji.
  • Jeśli ustawisz kategorię Function na Error poziom dziennika, zatrzyma zbieranie danych telemetrycznych funkcji związanych z dependencieselementami , customMetricsi customEvents dla wszystkich funkcji, co uniemożliwia wyświetlanie dowolnego z tych danych w usłudze Application Insights. Platforma Azure zbiera tylko traces zarejestrowane dane na Error poziomie.

W obu przypadkach platforma Azure nadal zbiera błędy i dane wyjątków na kartach Application Insights i Monitor funkcji. Aby uzyskać więcej informacji, zobacz Rozwiązania z dużą ilością danych telemetrycznych.

Konfigurowanie agregatora

Jak wspomniano w poprzedniej sekcji, środowisko uruchomieniowe agreguje dane dotyczące wykonywania funkcji w danym okresie. Domyślny okres to 30 sekund lub 1000 przebiegów, w zależności od tego, co nastąpi wcześniej. To ustawienie można skonfigurować w pliku host.json. Na przykład:

{
    "aggregator": {
      "batchSize": 1000,
      "flushTimeout": "00:00:30"
    }
}

Konfigurowanie próbkowania

Usługa Application Insights ma funkcję próbkowania , która może chronić cię przed generowaniem zbyt dużej ilości danych telemetrycznych na ukończonych wykonaniach w okresach szczytowego obciążenia. Gdy szybkość przychodzących wykonań przekracza określony próg, usługa Application Insights zaczyna losowo ignorować niektóre z przychodzących wykonań. Ustawieniem domyślnym maksymalnej liczby wykonań na sekundę jest 20 (pięć w wersji 1.x). Próbkowanie można skonfigurować w host.json. Oto przykład:

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

Niektóre typy danych telemetrycznych można wykluczyć z próbkowania. W tym przykładzie dane typu Request i Exception są wykluczone z próbkowania. Gwarantuje to, że wszystkie wykonania funkcji (żądania) i wyjątki są rejestrowane, podczas gdy inne typy telemetrii pozostają poddane próbkowaniu.

Jeśli projekt używa zależności od zestawu SDK usługi Application Insights do ręcznego śledzenia telemetrii, może wystąpić nietypowe zachowanie, jeśli konfiguracja próbkowania różni się od konfiguracji próbkowania w aplikacji funkcji. W takich przypadkach należy użyć tej samej konfiguracji próbkowania co aplikacja funkcji. Aby uzyskać więcej informacji, zobacz Próbkowanie w usłudze Application Insights.

Włączanie zbierania zapytań SQL

Usługa Application Insights automatycznie zbiera dane dotyczące zależności żądań HTTP, wywołań bazy danych i kilku powiązań. Aby uzyskać więcej informacji, zobacz Zależności. W przypadku wywołań SQL nazwa serwera i bazy danych jest zawsze zbierana i przechowywana, ale tekst zapytania SQL nie jest domyślnie zbierany. Aby włączyć rejestrowanie tekstu zapytania SQL, możesz użyć dependencyTrackingOptions.enableSqlCommandTextInstrumentation następujących ustawień (co najmniej) w pliku host.json:

"logging": {
    "applicationInsights": {
        "enableDependencyTracking": true,    
        "dependencyTrackingOptions": {
            "enableSqlCommandTextInstrumentation": true
        }
    }
}

Aby uzyskać więcej informacji, zobacz Zaawansowane śledzenie SQL, aby uzyskać pełne zapytanie SQL.

Konfigurowanie dzienników kontrolera skalowania

Ta funkcja jest dostępna w wersji zapoznawczej.

Kontroler skalowania usługi Azure Functions może emitować dzienniki do usługi Application Insights lub usługi Blob Storage, aby lepiej zrozumieć decyzje podejmowane przez kontroler skalowania dla aplikacji funkcji.

Aby włączyć tę funkcję, dodaj ustawienie aplikacji o nazwie SCALE_CONTROLLER_LOGGING_ENABLED do ustawień aplikacji funkcji. Następująca wartość ustawienia musi mieć format <DESTINATION>:<VERBOSITY>. Aby uzyskać więcej informacji, zobacz następującą tabelę:

Właściwości opis
<DESTINATION> Miejsce docelowe, do którego są wysyłane dzienniki. Prawidłowe wartości to AppInsights i Blob.
W przypadku korzystania z usługi AppInsightsupewnij się, że usługa Application Insights jest włączona w aplikacji funkcji.
Po ustawieniu miejsca docelowego na Blobwartość dzienniki są tworzone w kontenerze obiektów blob o nazwie azure-functions-scale-controller w domyślnym koncie magazynu ustawionym w ustawieniu AzureWebJobsStorage aplikacji.
<VERBOSITY> Określa poziom rejestrowania. Obsługiwane wartości to None, Warningi Verbose.
W przypadku ustawienia wartości Verbosekontroler skalowania rejestruje przyczynę każdej zmiany liczby procesów roboczych oraz informacje o wyzwalaczach, które uwzględniają te decyzje. Pełne dzienniki obejmują ostrzeżenia wyzwalacza i skróty używane przez wyzwalacze przed uruchomieniem kontrolera skalowania i po nim.

Napiwek

Należy pamiętać, że pozostawienie włączonego rejestrowania kontrolera skalowania wpływa na potencjalne koszty monitorowania aplikacji funkcji. Rozważ włączenie rejestrowania, dopóki nie zebrano wystarczającej ilości danych, aby zrozumieć, jak działa kontroler skalowania, a następnie wyłączyć go.

Na przykład następujące polecenie interfejsu wiersza polecenia platformy Azure włącza pełne rejestrowanie z kontrolera skalowania do usługi Application Insights:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose

W tym przykładzie zastąp <FUNCTION_APP_NAME> wartości i <RESOURCE_GROUP_NAME> nazwą aplikacji funkcji oraz odpowiednio nazwą grupy zasobów.

Następujące polecenie interfejsu wiersza polecenia platformy Azure wyłącza rejestrowanie przez ustawienie szczegółowości na None:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None

Rejestrowanie można również wyłączyć, usuwając SCALE_CONTROLLER_LOGGING_ENABLED ustawienie przy użyciu następującego polecenia interfejsu wiersza polecenia platformy Azure:

az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED

Po włączeniu rejestrowania kontrolera skalowania można wykonywać zapytania dotyczące dzienników kontrolera skalowania.

Enable Application Insights integration (Włączanie integracji z usługą Application Insights)

Aby aplikacja funkcji wysyłała dane do usługi Application Insights, musi połączyć się z zasobem usługi Application Insights przy użyciu tylko jednego z następujących ustawień aplikacji:

Nazwa ustawienia opis
APPLICATIONINSIGHTS_CONNECTION_STRING To ustawienie jest zalecane i jest wymagane, gdy wystąpienie usługi Application Insights działa w suwerennej chmurze. Parametry połączenia obsługuje inne nowe możliwości.
APPINSIGHTS_INSTRUMENTATIONKEY Starsze ustawienie, które usługa Application Insights jest przestarzała na rzecz ustawienia parametry połączenia.

Po utworzeniu aplikacji funkcji w witrynie Azure Portal z poziomu wiersza polecenia przy użyciu narzędzi Azure Functions Core Tools lub Visual Studio Code integracja usługi Application Insights jest domyślnie włączona. Zasób usługi Application Insights ma taką samą nazwę jak aplikacja funkcji i jest tworzony w tym samym regionie lub w najbliższym regionie.

Wymaganie uwierzytelniania entra firmy Microsoft

Możesz użyć APPLICATIONINSIGHTS_AUTHENTICATION_STRING tego ustawienia, aby włączyć połączenia z usługą Application Insights przy użyciu uwierzytelniania firmy Microsoft Entra. Spowoduje to utworzenie spójnego środowiska uwierzytelniania we wszystkich potokach usługi Application Insights, w tym profilera i debugera migawek, a także na hoście usługi Functions i agentach specyficznych dla języka.

Uwaga

Nie ma obsługi uwierzytelniania Entra na potrzeby programowania lokalnego.

Wartość zawiera Authorization=AAD tożsamość zarządzaną przypisaną przez system lub ClientId=<YOUR_CLIENT_ID>;Authorization=AAD tożsamość zarządzaną przypisaną przez użytkownika. Tożsamość zarządzana musi być już dostępna dla aplikacji funkcji z przypisaną rolą równoważną wydawcy metryk monitorowania. Aby uzyskać więcej informacji, zobacz Microsoft Entra authentication for Application Insights (Uwierzytelnianie entra firmy Microsoft dla usługi Application Insights).

Ustawienie APPLICATIONINSIGHTS_CONNECTION_STRING jest nadal wymagane.

Uwaga

W przypadku używania polecenia APPLICATIONINSIGHTS_AUTHENTICATION_STRING w celu nawiązania połączenia z usługą Application Insights przy użyciu uwierzytelniania entra firmy Microsoft należy również wyłączyć uwierzytelnianie lokalne dla usługi Application Insights. Ta konfiguracja wymaga uwierzytelnienia firmy Microsoft w celu pozyskiwania danych telemetrycznych do obszaru roboczego.

Nowa aplikacja funkcji w portalu

Aby przejrzeć tworzony zasób usługi Application Insights, wybierz go, aby rozwinąć okno usługi Application Insights . Możesz zmienić nazwę nowego zasobu lub wybrać inną lokalizację w lokalizacji geograficznej platformy Azure, w której chcesz przechowywać dane.

Zrzut ekranu przedstawiający sposób włączania usługi Application Insights podczas tworzenia aplikacji funkcji.

Po wybraniu pozycji Utwórz zasób usługi Application Insights zostanie utworzony za pomocą aplikacji funkcji, który ma APPLICATIONINSIGHTS_CONNECTION_STRING zestaw w ustawieniach aplikacji. Wszystko jest gotowe do zrobienia.

Dodawanie do istniejącej aplikacji funkcji

Jeśli zasób usługi Application Insights nie został utworzony w aplikacji funkcji, wykonaj następujące kroki, aby utworzyć zasób. Następnie możesz dodać parametry połączenia z tego zasobu jako ustawienie aplikacji w aplikacji funkcji.

  1. W witrynie Azure Portal wyszukaj i wybierz aplikację funkcji, a następnie wybierz aplikację funkcji.

  2. Wybierz baner Application Insights nieskonfigurowane w górnej części okna. Jeśli ten baner nie jest widoczny, aplikacja może już mieć włączoną usługę Application Insights.

    Zrzut ekranu przedstawiający sposób włączania usługi Application Insights z portalu.

  3. Rozwiń węzeł Zmień zasób i utwórz zasób usługi Application Insights przy użyciu ustawień określonych w poniższej tabeli:

    Ustawienie Sugerowana wartość opis
    Nowa nazwa zasobu Unikatowa nazwa aplikacji Najłatwiej jest użyć tej samej nazwy co aplikacja funkcji, która musi być unikatowa w subskrypcji.
    Lokalizacja West Europe Jeśli to możliwe, użyj tego samego regionu co aplikacja funkcji lub regionu, który znajduje się blisko tego regionu.

    Zrzut ekranu przedstawiający sposób tworzenia zasobu usługi Application Insights.

  4. Wybierz Zastosuj.

    Zasób usługi Application Insights jest tworzony w tej samej grupie zasobów i subskrypcji co aplikacja funkcji. Po utworzeniu zasobu zamknij okno usługi Application Insights .

  5. W aplikacji funkcji rozwiń węzeł Ustawienia, a następnie wybierz pozycję Zmienne środowiskowe. Jeśli na karcie Ustawienia aplikacji zostanie wyświetlone ustawienie aplikacji o nazwie APPLICATIONINSIGHTS_CONNECTION_STRING, integracja usługi Application Insights jest włączona dla aplikacji funkcji uruchomionej na platformie Azure. Jeśli to ustawienie nie istnieje, dodaj je przy użyciu parametry połączenia usługi Application Insights jako wartości.

Uwaga

Starsze aplikacje funkcji mogą używać APPINSIGHTS_INSTRUMENTATIONKEY zamiast APPLICATIONINSIGHTS_CONNECTION_STRING. Jeśli to możliwe, zaktualizuj aplikację, aby używała parametry połączenia zamiast klucza instrumentacji.

Wyłączanie wbudowanego rejestrowania

Wczesne wersje funkcji korzystały z wbudowanego monitorowania, co nie jest już zalecane. Po włączeniu usługi Application Insights wyłącz wbudowane rejestrowanie korzystające z usługi Azure Storage. Wbudowane rejestrowanie jest przydatne do testowania przy użyciu lekkich obciążeń, ale nie jest przeznaczone do użycia w środowisku produkcyjnym o dużym obciążeniu. W przypadku monitorowania produkcji zalecamy usługę Application Insights. Jeśli używasz wbudowanego rejestrowania w środowisku produkcyjnym, rekord rejestrowania może być niekompletny z powodu ograniczania przepustowości w usłudze Azure Storage.

Aby wyłączyć wbudowane rejestrowanie, usuń AzureWebJobsDashboard ustawienie aplikacji. Aby uzyskać więcej informacji na temat usuwania ustawień aplikacji w witrynie Azure Portal, zobacz sekcję Ustawienia aplikacji w temacie Jak zarządzać aplikacją funkcji. Przed usunięciem ustawienia aplikacji upewnij się, że żadne istniejące funkcje w tej samej aplikacji funkcji nie używają ustawienia dla wyzwalaczy lub powiązań usługi Azure Storage.

Rozwiązania z dużą ilością danych telemetrycznych

Aplikacje funkcji są istotną częścią rozwiązań, które mogą powodować duże ilości danych telemetrycznych, takich jak rozwiązania IoT, szybkie rozwiązania sterowane zdarzeniami, systemy finansowe o dużym obciążeniu i systemy integracji. W takim przypadku należy rozważyć dodatkową konfigurację, aby zmniejszyć koszty przy zachowaniu zauważalności.

Wygenerowane dane telemetryczne mogą być używane na pulpitach nawigacyjnych w czasie rzeczywistym, alertach, szczegółowej diagnostyce itd. W zależności od sposobu użycia wygenerowanej telemetrii należy zdefiniować strategię w celu zmniejszenia ilości generowanych danych. Ta strategia umożliwia prawidłowe monitorowanie, obsługę i diagnozowanie aplikacji funkcji w środowisku produkcyjnym. Rozważ następujące opcje:

  • Użyj próbkowania: jak wspomniano wcześniej, próbkowanie pomaga znacznie zmniejszyć ilość zdarzeń telemetrii pozyskanych przy zachowaniu statystycznie poprawnej analizy. Może się zdarzyć, że nawet przy użyciu próbkowania nadal uzyskujesz dużą ilość danych telemetrycznych. Sprawdź opcje, które zapewnia próbkowanie adaptacyjne. Na przykład ustaw maxTelemetryItemsPerSecond wartość na wartość, która równoważy wolumin wygenerowany zgodnie z potrzebami monitorowania. Należy pamiętać, że próbkowanie telemetrii jest stosowane dla każdego hosta wykonującego aplikację funkcji.

  • Domyślny poziom dziennika: użyj Warning wartości domyślnej lub Error jako wartości domyślnej dla wszystkich kategorii telemetrii. Później możesz zdecydować, które kategorie chcesz ustawić na Information poziomie, aby można było prawidłowo monitorować i diagnozować funkcje.

  • Dostrajanie danych telemetrycznych funkcji: przy domyślnym poziomie dziennika ustawionym na Error lub Warningnie są zbierane żadne szczegółowe informacje z każdej funkcji (zależności, metryki niestandardowe, zdarzenia niestandardowe i ślady). Dla tych funkcji, które są kluczem do monitorowania produkcji, zdefiniuj jawny wpis dla Function.<YOUR_FUNCTION_NAME> kategorii i ustaw go na Information, aby można było zebrać szczegółowe informacje. Aby uniknąć zbierania dzienników generowanych przez użytkownika na Information poziomie, ustaw kategorię Function.<YOUR_FUNCTION_NAME>.User Error na poziom dziennika lub Warning .

  • Kategoria Host.Aggregator: zgodnie z opisem w temacie Konfigurowanie kategorii ta kategoria zawiera zagregowane informacje o wywołaniach funkcji. Informacje z tej kategorii są zbierane w tabeli usługi Application Insights customMetrics i są wyświetlane na karcie Przegląd funkcji w witrynie Azure Portal. W zależności od sposobu konfigurowania agregatora należy wziąć pod uwagę, że może wystąpić opóźnienie określone przez flushTimeout ustawienie w zebranych danych telemetrycznych. Jeśli ustawisz tę kategorię na wartość inną niż Information, zatrzymasz zbieranie danych w customMetrics tabeli i nie wyświetlasz metryk na karcie Przegląd funkcji.

    Poniższy zrzut ekranu przedstawia Host.Aggregator dane telemetryczne wyświetlane na karcie Przegląd funkcji:

    Zrzut ekranu przedstawiający dane telemetryczne Host.Aggregator wyświetlane na karcie Przegląd funkcji.

    Poniższy zrzut ekranu przedstawia Host.Aggregator dane telemetryczne w tabeli usługi Application Insights customMetrics :

    Zrzut ekranu przedstawiający dane telemetryczne Host.Aggregator w tabeli customMetrics Application Insights.

  • Kategoria Host.Results: zgodnie z opisem w temacie Konfigurowanie kategorii ta kategoria zawiera dzienniki generowane przez środowisko uruchomieniowe wskazujące powodzenie lub niepowodzenie wywołania funkcji. Informacje z tej kategorii są zbierane w tabeli usługi Application Insights requests i są wyświetlane na karcie Monitor funkcji oraz na różnych pulpitach nawigacyjnych usługi Application Insights (wydajność, błędy itd.). Jeśli ustawisz tę kategorię na wartość inną niż Information, zbierzesz tylko dane telemetryczne wygenerowane na zdefiniowanym poziomie dziennika (lub wyższym). Na przykład ustawienie go powoduje error śledzenie danych żądań tylko w przypadku nieudanych wykonań.

    Poniższy zrzut ekranu przedstawia Host.Results dane telemetryczne wyświetlane na karcie Monitor funkcji:

    Zrzut ekranu przedstawiający dane telemetryczne Host.Results na karcie Monitor funkcji.

    Poniższy zrzut ekranu przedstawia Host.Results dane telemetryczne wyświetlane na pulpicie nawigacyjnym wydajności usługi Application Insights:

    Zrzut ekranu przedstawiający dane telemetryczne Host.Results na pulpicie nawigacyjnym wydajności usługi Application Insights.

  • Host.Aggregator vs Host.Results: Obie kategorie zapewniają dobre informacje o wykonywaniu funkcji. W razie potrzeby możesz usunąć szczegółowe informacje z jednej z tych kategorii, aby można było używać ich do monitorowania i zgłaszania alertów. Oto przykład:

{
  "version": "2.0",  
  "logging": {
    "logLevel": {
      "default": "Warning",
      "Function": "Error",
      "Host.Aggregator": "Error",
      "Host.Results": "Information", 
      "Function.Function1": "Information",
      "Function.Function1.User": "Error"
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 1,
        "excludedTypes": "Exception"
      }
    }
  }
}

Z tą konfiguracją:

  • Wartość domyślna dla wszystkich funkcji i kategorii telemetrii jest ustawiona na Warning (w tym kategorie firmy Microsoft i procesów roboczych). Domyślnie zbierane są wszystkie błędy i ostrzeżenia generowane przez środowisko uruchomieniowe i rejestrowanie niestandardowe.

  • Poziom Function dziennika kategorii jest ustawiony na Error, więc dla wszystkich funkcji domyślnie zbierane są tylko wyjątki i dzienniki błędów. Pominięto zależności, metryki generowane przez użytkownika i zdarzenia generowane przez użytkownika.

  • Host.Aggregator Dla kategorii, ponieważ jest ona ustawiona na Error poziom dziennika, zagregowane informacje z wywołań funkcji nie są zbierane w customMetrics tabeli usługi Application Insights, a informacje o liczbach wykonań (suma, powodzenie i niepowodzenie) nie są wyświetlane na pulpicie nawigacyjnym przeglądu funkcji.

  • Host.Results Dla kategorii wszystkie informacje o wykonywaniu hosta są zbierane w requests tabeli usługi Application Insights. Wszystkie wyniki wywołań są wyświetlane na pulpicie nawigacyjnym Monitor funkcji i na pulpitach nawigacyjnych usługi Application Insights.

  • Dla funkcji o nazwie Function1ustawiamy poziom dziennika na Information. W przypadku tej konkretnej funkcji wszystkie dane telemetryczne są zbierane (zależność, metryki niestandardowe i zdarzenia niestandardowe). Dla tej samej funkcji ustawiliśmy kategorię Function1.User (ślady generowane przez użytkownika) na Error, więc zbierane są tylko niestandardowe rejestrowanie błędów.

    Uwaga

    Konfiguracja na funkcję nie jest obsługiwana w wersji 1.x środowiska uruchomieniowego usługi Functions.

  • Próbkowanie jest skonfigurowane do wysyłania jednego elementu telemetrii na sekundę na typ, z wyłączeniem wyjątków. To próbkowanie odbywa się dla każdego hosta serwera, na którym działa nasza aplikacja funkcji. Dlatego jeśli mamy cztery wystąpienia, ta konfiguracja emituje cztery elementy telemetryczne na sekundę na typ i wszystkie wyjątki, które mogą wystąpić.

    Uwaga

    Liczniki metryk, takie jak częstotliwość żądań i częstotliwość wyjątków, są dostosowywane w celu zrekompensowania częstotliwości próbkowania, tak aby były wyświetlane w przybliżeniu poprawne wartości w Eksploratorze metryk.

Napiwek

Poeksperymentuj z różnymi konfiguracjami, aby upewnić się, że spełnisz wymagania dotyczące rejestrowania, monitorowania i alertów. Upewnij się również, że masz szczegółową diagnostykę w przypadku nieoczekiwanych błędów lub awarii.

Zastępowanie konfiguracji monitorowania w czasie wykonywania

Na koniec mogą wystąpić sytuacje, w których trzeba szybko zmienić zachowanie rejestrowania określonej kategorii w środowisku produkcyjnym i nie chcesz wprowadzać całego wdrożenia tylko w celu zmiany w pliku host.json . W takich przypadkach można zastąpić wartości host.json.

Aby skonfigurować te wartości na poziomie ustawień aplikacji (i uniknąć ponownego wdrażania tylko host.json zmian), należy zastąpić określone host.json wartości, tworząc równoważną wartość jako ustawienie aplikacji. Gdy środowisko uruchomieniowe znajdzie ustawienie aplikacji w formacie AzureFunctionsJobHost__path__to__setting, zastępuje równoważne host.json ustawienie znajdujące się w path.to.setting pliku JSON. W przypadku wyrażenia jako ustawienia aplikacji podwójne podkreślenie () zastępuje kropkę (__.) używaną do wskazywania hierarchii JSON. Na przykład można użyć następujących ustawień aplikacji, aby skonfigurować poszczególne poziomy dziennika funkcji w programie host.json.

ścieżka Host.json Ustawienia aplikacji
logging.logLevel.default AzureFunctionsJobHost__logging__logLevel__default
logging.logLevel.Host.Aggregator AzureFunctionsJobHost__logging__logLevel__Host.Agregator
logging.logLevel.Function AzureFunctionsJobHost__logging__logLevel__Function
logging.logLevel.Function.Function1 AzureFunctionsJobHost__logging__logLevel__Function.Function1
logging.logLevel.Function.Function1.User AzureFunctionsJobHost__logging__logLevel__Function.Function1.User

Ustawienia można zastąpić bezpośrednio w okienku Konfiguracja aplikacji funkcji witryny Azure Portal lub za pomocą interfejsu wiersza polecenia platformy Azure lub skryptu programu PowerShell.

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host.Aggregator=Information"

Uwaga

host.json Zastąpienie zmian ustawień aplikacji spowoduje ponowne uruchomienie aplikacji funkcji. Ustawienia aplikacji, które zawierają okres, nie są obsługiwane w przypadku uruchamiania w systemie Linux w planie Elastic Premium lub w planie dedykowanej usługi App Service. W tych środowiskach hostingu należy nadal używać pliku host.json .

Monitorowanie aplikacji funkcji przy użyciu kontroli kondycji

Funkcja Kontroli kondycji umożliwia monitorowanie aplikacji funkcji w planach Premium (Elastic Premium) i Dedicated (App Service). Sprawdzanie kondycji nie jest opcją dla planu Zużycie. Aby dowiedzieć się, jak ją skonfigurować, zobacz Monitorowanie wystąpień usługi App Service przy użyciu kontroli kondycji. Aplikacja funkcji powinna mieć funkcję wyzwalacza HTTP, która odpowiada za pomocą kodu stanu HTTP 200 w tym samym punkcie końcowym, co skonfigurowano w Path parametrze kontroli kondycji. Możesz również mieć funkcję wykonującą dodatkowe kontrole, aby upewnić się, że usługi zależne są osiągalne i działają.

Powiązana zawartość

Aby uzyskać więcej informacji na temat monitorowania, zobacz: