Jak skonfigurować monitorowanie dla usługi Azure Functions
Usługa Azure Functions integruje się z usługą Application Insights, aby lepiej umożliwić monitorowanie aplikacji funkcji. Aplikacja Szczegółowe informacje, 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 Szczegółowe informacje aplikacji jest zwykle włączona podczas tworzenia aplikacji funkcji. Jeśli aplikacja nie ma ustawionego klucza instrumentacji, musisz najpierw włączyć integrację usługi Application Szczegółowe informacje.
Usługi Application Insights można używać bez żadnej konfiguracji niestandardowej. 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 aplikacji Szczegółowe informacje. Aby uzyskać informacje o kosztach Szczegółowe informacje aplikacji, zobacz Rozliczenia Szczegółowe informacje aplikacji. Aby uzyskać więcej informacji, zobacz Rozwiązania z dużą ilością danych telemetrycznych.
W dalszej części tego artykułu dowiesz się, jak skonfigurować i dostosować dane wysyłane przez funkcje do aplikacji Szczegółowe informacje. Typową konfigurację rejestrowania można ustawić w pliku host.json . Domyślnie te ustawienia zarządzają również dziennikami niestandardowymi emitowanych 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 Dzienniki aplikacji niestandardowych.
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 zmienić ustawienia pliku 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 aplikacji Szczegółowe informacje za pośrednictwem kategorii "Proces roboczy". Niektóre stosy języków umożliwiają zamiast tego wysyłanie dzienników bezpośrednio do aplikacji Szczegółowe informacje, co daje pełną kontrolę nad sposobem emitowania dzienników, które zapisujesz. Potok rejestrowania zmienia się z worker -> Functions host -> Application Insights
na worker -> Application Insights
.
Poniższa tabela zawiera podsumowanie opcji dostępnych dla każdego stosu:
Stos języka | Konfiguracja dzienników niestandardowych |
---|---|
.NET (model w procesie) | host.json |
.NET (model izolowany) | Domyślnie: host.json Opcja bezpośredniego wysyłania dzienników: Konfigurowanie Szczegółowe informacje aplikacji w programie HostBuilder |
Node.JS | host.json |
Python | host.json |
Java | Domyślnie: host.json Opcja bezpośredniego wysyłania dzienników: Konfigurowanie agenta aplikacji Szczegółowe informacje Java |
PowerShell | host.json |
Gdy dzienniki aplikacji niestandardowych są wysyłane bezpośrednio, host nie emituje ich i host.json
nie kontroluje już ich zachowania. Podobnie opcje udostępniane przez każdy stos dotyczą tylko dzienników niestandardowych i nie zmieniają zachowania innych dzienników środowiska uruchomieniowego opisanych w tym artykule. Aby kontrolować zachowanie wszystkich dzienników, może być konieczne wprowadzenie zmian dla obu konfiguracji.
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
.
Na poniższym wykresie 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. W przypadku filtrowania na Warning poziomie lub powyżej nie będą widoczne żadne 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. W przypadku filtrowania na Warning poziomie lub powyżej nie będą widoczne żadne 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. |
Kolumna Tabela wskazuje, która tabela w aplikacji Szczegółowe informacje dziennik jest zapisywany.
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 aplikacji Application Szczegółowe informacje.
Dla każdej kategorii należy wskazać minimalny poziom dziennika do wysłania. Ustawienia pliku 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
iHost.Results
są ustawione na niższe poziomy. Ustawienie tych wartości na zbyt wysoki poziom (szczególnie wyższy niżInformation
) może spowodować utratę metryk i danych wydajności.- Rejestrowanie przebiegów funkcji jest ustawione na
Information
wartość . Może to zostać zastąpione w lokalnym środowisku deweloperów doDebug
lubTrace
, w razie potrzeby.
{
"logging": {
"fileLoggingMode": "debugOnly",
"logLevel": {
"default": "Warning",
"Host.Aggregator": "Trace",
"Host.Results": "Information",
"Function": "Information"
}
}
}
Jeśli plik host.json zawiera wiele dzienników rozpoczynających się od tego samego ciągu, bardziej zdefiniowane dzienniki są najpierw dopasowywane. 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 Szczegółowe informacje przez przechowywanie zdarzeń telemetrii w tabelach usługi Application Szczegółowe informacje. Ustawienie poziomu dziennika kategorii na dowolną wartość inną niż Information
uniemożliwi przepływ danych telemetrycznych do tych tabel. W wyniku nie będzie można wyświetlić powiązanych danych na karcie Application Szczegółowe informacje lub Function Monitor.
Z powyższych przykładów:
Host.Results
Jeśli kategoria jest ustawiona naError
poziom dziennika, będzie zbierać tylko zdarzenia telemetryczne wykonywania hosta wrequests
tabeli w przypadku nieudanych wykonań funkcji, uniemożliwiając wyświetlanie szczegółów wykonywania hosta wykonań powodzenia zarówno na karcie Application Szczegółowe informacje iFunction Monitor.- Jeśli kategoria jest ustawiona
Function
naError
poziom dziennika, zatrzyma zbieranie danych telemetrycznych funkcji związanych zdependencies
elementami ,customMetrics
icustomEvents
dla wszystkich funkcji, co uniemożliwia wyświetlanie dowolnego z tych danych w aplikacji Szczegółowe informacje. Będzie on zbieranytraces
tylko przy użyciuError
poziomu.
W obu przypadkach będziesz nadal zbierać błędy i dane wyjątków na karcie Aplikacja Szczegółowe informacje 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. Oto przykład:
{
"aggregator": {
"batchSize": 1000,
"flushTimeout": "00:00:30"
}
}
Konfigurowanie próbkowania
Aplikacja Szczegółowe informacje ma funkcję próbkowania, która może chronić cię przed generowaniem zbyt dużej ilości danych telemetrycznych na ukończonych wykonaniach w godzinach 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 pliku 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. Zapewni to, że wszystkie wykonania funkcji (żądania) i wyjątki są rejestrowane, podczas gdy inne typy telemetrii pozostają poddane próbkowaniu.
Jeśli projekt przyjmuje zależność od zestawu SDK usługi Application Szczegółowe informacje do ręcznego śledzenia danych telemetrycznych, może wystąpić dziwne 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 Szczegółowe informacje aplikacji.
Włączanie zbierania zapytań SQL
Aplikacja Szczegółowe informacje 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. Możesz użyć dependencyTrackingOptions.enableSqlCommandTextInstrumentation
polecenia , aby włączyć rejestrowanie tekstu zapytania SQL, ustawiając (co najmniej) następujące ustawienia 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 Szczegółowe informacje lub Do usługi Blob Storage, aby lepiej zrozumieć decyzje podejmowane przez kontroler skalowania dla aplikacji funkcji.
Aby włączyć tę funkcję, możesz dodać ustawienie aplikacji o nazwie SCALE_CONTROLLER_LOGGING_ENABLED
do ustawień aplikacji funkcji. Następująca wartość ustawienia musi mieć format <DESTINATION>:<VERBOSITY>
:
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 programu AppInsights upewnij się, że aplikacja Szczegółowe informacje jest włączona w aplikacji funkcji.Po ustawieniu miejsca docelowego na Blob wartość 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 , Warning i Verbose .W przypadku ustawienia wartości Verbose kontroler 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 aplikacji Szczegółowe informacje:
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 Szczegółowe informacje, musi połączyć się z zasobem Application Szczegółowe informacje przy użyciu tylko jednego z następujących ustawień aplikacji:
Nazwa ustawienia | opis |
---|---|
APPLICATIONINSIGHTS_CONNECTION_STRING | Jest to zalecane ustawienie, które jest wymagane, gdy wystąpienie aplikacji Szczegółowe informacje działa w suwerennej chmurze. Parametry połączenia obsługuje inne nowe możliwości. |
APPINSIGHTS_INSTRUMENTATIONKEY | Starsze ustawienie, które jest przestarzałe przez aplikację Szczegółowe informacje 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 aplikacji Szczegółowe informacje jest domyślnie włączona. Zasób Application Szczegółowe informacje ma taką samą nazwę jak aplikacja funkcji i jest tworzony w tym samym regionie lub w najbliższym regionie.
Nowa aplikacja funkcji w portalu
Aby przejrzeć tworzony zasób Application Szczegółowe informacje, wybierz go, aby rozwinąć okno Aplikacja Szczegółowe informacje. Możesz zmienić nazwę nowego zasobu lub wybrać inną lokalizację w lokalizacji geograficznej platformy Azure, w której chcesz przechowywać dane.
Po wybraniu pozycji Utwórz zasób aplikacji Szczegółowe informacje zostanie utworzony za pomocą aplikacji funkcji, która ma APPLICATIONINSIGHTS_CONNECTION_STRING
ustawienie w ustawieniach aplikacji. Wszystko jest gotowe do zrobienia.
Dodawanie do istniejącej aplikacji funkcji
Jeśli zasób aplikacji Szczegółowe informacje 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.
W witrynie Azure Portal wyszukaj i wybierz aplikację funkcji, a następnie wybierz aplikację funkcji.
Wybierz baner Szczegółowe informacje aplikacji nie jest skonfigurowany w górnej części okna. Jeśli nie widzisz tego baneru, aplikacja może już mieć włączoną Szczegółowe informacje aplikacji.
Rozwiń węzeł Zmień zasób i utwórz zasób aplikacji Szczegółowe informacje 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 Europa Zachodnia Jeśli to możliwe, użyj tego samego regionu co aplikacja funkcji lub regionu, który znajduje się blisko tego regionu. Wybierz Zastosuj.
Zasób Application Szczegółowe informacje jest tworzony w tej samej grupie zasobów i subskrypcji co aplikacja funkcji. Po utworzeniu zasobu zamknij okno Aplikacja Szczegółowe informacje.
W aplikacji funkcji wybierz pozycję Konfiguracja w obszarze Ustawienia, a następnie wybierz pozycję Ustawienia aplikacji. Jeśli zobaczysz ustawienie o nazwie
APPLICATIONINSIGHTS_CONNECTION_STRING
, integracja aplikacji Szczegółowe informacje jest włączona dla aplikacji funkcji uruchomionej na platformie Azure. Jeśli z jakiegoś powodu to ustawienie nie istnieje, dodaj je przy użyciu Szczegółowe informacje parametry połączenia aplikacji jako wartości.
Uwaga
Starsze aplikacje funkcji mogą używać APPINSIGHTS_INSTRUMENTATIONKEY
zamiast APPLICATIONINSIGHTS_CONNECTION_STRING
. Jeśli to możliwe, należy zaktualizować aplikację tak, aby korzystała z 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 Szczegółowe informacje aplikacji 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 Szczegółowe informacje aplikacji. Jeśli wbudowane rejestrowanie jest używane 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ę zmniejszenia ilości generowanych danych. Ta strategia umożliwia prawidłowe monitorowanie, działanie i diagnozowanie aplikacji funkcji w środowisku produkcyjnym. Możesz wziąć pod uwagę następujące opcje:
Użyj próbkowania: jak wspomniano wcześniej, pomoże to 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 lubError
jako wartości domyślnej dla wszystkich kategorii telemetrii. Teraz możesz zdecydować, które kategorie chcesz ustawić naInformation
poziomie, aby umożliwić prawidłowe monitorowanie i diagnozowanie funkcji.Dostrajanie danych telemetrycznych funkcji: przy domyślnym poziomie dziennika ustawionym na
Error
lubWarning
nie zostaną zebrane żadne szczegółowe informacje z każdej funkcji (zależności, metryki niestandardowe, zdarzenia niestandardowe i ślady). W przypadku tych funkcji, które są kluczem do monitorowania produkcji, zdefiniuj jawny wpis dlaFunction.<YOUR_FUNCTION_NAME>
kategorii i ustaw go naInformation
wartość , aby można było zebrać szczegółowe informacje. W tym momencie, aby uniknąć zbierania dzienników generowanych przez użytkownika naInformation
poziomie, ustaw kategorięFunction.<YOUR_FUNCTION_NAME>.User
naError
lubWarning
poziom dziennika.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 Application Szczegółowe informacje
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 wystąpi opóźnienie określone przezflushTimeout
element , w zebranych danych telemetrycznych. Jeśli ustawisz tę kategorię na inną wartość niżInformation
, zatrzymasz zbieranie danych wcustomMetrics
tabeli i nie wyświetlisz metryk na karcie Przegląd funkcji.Poniższy zrzut ekranu przedstawia
Host.Aggregator
dane telemetryczne wyświetlane na karcie Przegląd funkcji:Poniższy zrzut ekranu przedstawia
Host.Aggregator
dane telemetryczne w tabeli application Szczegółowe informacjecustomMetrics
: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 Application Szczegółowe informacje
requests
i są wyświetlane na karcie Monitor funkcji i na różnych pulpitach nawigacyjnych usługi Application Szczegółowe informacje (wydajność, błędy itd.). Jeśli ustawisz tę kategorię na inną wartość inną niżInformation
, zbierzesz tylko dane telemetryczne wygenerowane na zdefiniowanym poziomie dziennika (lub wyższym). Na przykład ustawienie go powodujeerror
śledzenie danych żądań tylko w przypadku nieudanych wykonań.Poniższy zrzut ekranu przedstawia
Host.Results
dane telemetryczne wyświetlane na karcie Monitor funkcji:Poniższy zrzut ekranu przedstawia
Host.Results
dane telemetryczne wyświetlane na pulpicie nawigacyjnym application Szczegółowe informacje Performance: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"
}
}
}
}
W przypadku tej konfiguracji będziesz mieć następujące elementy:
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 naError
, więc dla wszystkich funkcji domyślnie będą zbierane tylko wyjątki i dzienniki błędów (zależności, metryki generowane przez użytkownika i zdarzenia generowane przez użytkownika zostaną pominięte).Host.Aggregator
W przypadku kategorii, ponieważ jest ona ustawiona naError
poziom dziennika, zagregowane informacje z wywołań funkcji nie będą zbierane wcustomMetrics
tabeli Application Szczegółowe informacje, a informacje o liczbach wykonań (łącznie, powodzeniu i niepomyślnie) nie będą wyświetlane na pulpicie nawigacyjnym przeglądu funkcji.Host.Results
Dla kategorii wszystkie informacje o wykonywaniu hosta są zbierane wrequests
tabeli Application Szczegółowe informacje. Wszystkie wyniki wywołań zostaną wyświetlone na pulpicie nawigacyjnym Monitor funkcji i na pulpitach nawigacyjnych usługi Application Szczegółowe informacje.Dla funkcji o nazwie
Function1
, ustawiliśmy poziom dziennika naInformation
. W przypadku tej konkretnej funkcji wszystkie dane telemetryczne są zbierane (zależność, metryki niestandardowe i zdarzenia niestandardowe). Dla tej samej funkcjiFunction1.User
kategoria (ślady generowane przez użytkownika) jest ustawiona naError
wartość , więc zbierane będą tylko niestandardowe rejestrowanie błędów.Uwaga
Konfiguracja na funkcję nie jest obsługiwana w wersji 1.x.
Próbkowanie jest skonfigurowane do wysyłania jednego elementu telemetrii na sekundę na typ, z wyłączeniem wyjątków. To próbkowanie będzie miało miejsce dla każdego hosta serwera, na którym działa nasza aplikacja funkcji. Dlatego jeśli mamy cztery wystąpienia, ta konfiguracja będzie emitować 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 w pliku host.json ), 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 kropka (.
) używana do wskazania hierarchii JSON jest zastępowana podwójnym podkreśleniem (__
). Możesz na przykład użyć poniższych ustawień aplikacji, aby skonfigurować poszczególne poziomy dziennika funkcji, jak pokazano host.json
powyżej.
Ścieżka Host.json | Ustawienia aplikacji |
---|---|
logging.logLevel.default | AzureFunctionsJobHost__logging__logLevel__default |
logging.logLevel.Host.Aggregator | AzureFunctionsJobHost__logging__logLevel__Host__Aggregator |
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 bloku 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 może służyć do monitorowania 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 kodem stanu HTTP 200 w tym samym punkcie końcowym, co skonfigurowano w parametrze "Path" 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ą.
Następne kroki
Aby uzyskać więcej informacji na temat monitorowania, zobacz: