Sdílet prostřednictvím

Konfigurace monitorování pro Azure Functions

  • Článek

Integrace služby Azure Functions s Application Insights umožňuje lépe monitorovat aplikace funkcí. Application Insights, funkce služby Azure Monitor, je rozšiřitelná služba APM (Application Performance Management), která shromažďuje data vygenerovaná vaší aplikací funkcí, včetně informací, které aplikace zapisuje do protokolů. Integrace Application Insights je obvykle povolená při vytváření vaší aplikace funkcí. Pokud vaše aplikace nemá nastavený instrumentační klíč, musíte nejprve povolit integraci Application Insights.

Application Insights můžete používat bez jakékoli vlastní konfigurace. Výchozí konfigurace ale může mít za následek velké objemy dat. Pokud používáte předplatné Azure sady Visual Studio, možná dosáhnete limitu dat pro Application Insights. Informace o nákladech na Application Insights najdete v tématu Fakturace Application Insights. Další informace najdete v tématu Řešení s velkým objemem telemetrie.

V tomto článku se dozvíte, jak nakonfigurovat a přizpůsobit data, která vaše funkce odesílají do Application Insights. V souboru host.json můžete nastavit běžné konfigurace protokolování. Ve výchozím nastavení tato nastavení řídí také vlastní protokoly generované vaším kódem. V některých případech však toto chování může být zakázáno ve prospěch možností, které vám dávají větší kontrolu nad protokolováním. Další informace najdete v tématu Vlastní protokoly aplikací.

Poznámka:

Můžete použít speciálně nakonfigurovaná nastavení aplikace, která představují konkrétní nastavení v souboru host.json pro konkrétní prostředí. Díky tomu můžete efektivně měnit nastavení host.json, aniž byste museli soubor host.json v projektu znovu publikovat. Další informace najdete v tématu Přepsání hodnot host.json.

Vlastní protokoly aplikací

Ve výchozím nastavení se vlastní protokoly aplikace, které zapisujete, posílají hostiteli Functions, který je pak odešle do Application Insights v kategorii Pracovní proces. Některé zásobníky jazyka umožňují místo toho odesílat protokoly přímo do Application Insights, což vám dává úplnou kontrolu nad tím, jak se protokoly generují. V tomto případě se kanál protokolování změní z worker -> Functions host -> Application Insights na worker -> Application Insights.

Následující tabulka shrnuje možnosti konfigurace dostupné pro jednotlivé zásobníky:

Zásobník jazyků Kde konfigurovat vlastní protokoly
.NET (model v procesu) host.json
.NET (izolovaný model) Výchozí (odesílání vlastních protokolů hostiteli Functions): host.json
Pokud chcete odesílat protokoly přímo do Application Insights, přečtěte si téma: Konfigurace Application Insights v nástroji HostBuilder
Node.JS host.json
Python host.json
Java Výchozí (odesílání vlastních protokolů hostiteli Functions): host.json
Pokud chcete odesílat protokoly přímo do Application Insights, přečtěte si téma: Konfigurace agenta Application Insights v Javě
PowerShell host.json

Když nakonfigurujete vlastní protokoly aplikací tak, aby se odesílaly přímo, hostitel je už nevysílají a host.json už nebude řídit jejich chování. Podobně se možnosti zveřejněné jednotlivými zásobníky vztahují pouze na vlastní protokoly a nemění chování ostatních protokolů modulu runtime popsaných v tomto článku. V takovém případě může být potřeba provést změny v obou konfiguracích, abyste mohli řídit chování všech protokolů.

Konfigurace kategorií

Protokolovací nástroj Azure Functions obsahuje kategorii pro každý protokol. Kategorie určuje, která část kódu modulu runtime nebo kódu vaší funkce protokol zapsala. Kategorie se liší mezi verzemi 1.x a novějšími verzemi.

Názvy kategorií se ve funkcích přiřazují odlišně v porovnání s jinými architekturami .NET. Například při použití ILogger<T> v ASP.NET je kategorie názvem obecného typu. Funkce jazyka C# také používají ILogger<T>, ale místo nastavení názvu obecného typu jako kategorie modul runtime přiřadí kategorie na základě zdroje. Příklad:

  • Položky související se spuštěním funkce jsou přiřazeny kategorii Function.<FUNCTION_NAME>.
  • Položky vytvořené uživatelským kódem uvnitř funkce, například při volání logger.LogInformation(), jsou přiřazeny kategorii Function.<FUNCTION_NAME>.User.

Následující tabulka popisuje hlavní kategorie protokolů, které modul runtime vytvoří:

Kategorie Table Popis
Function stopy Zahrnuje spuštěné a dokončené protokoly funkce pro všechna spuštění funkcí. Pro úspěšná spuštění jsou tyto protokoly na Information úrovni. Výjimky se protokolují na Error úrovni. Modul runtime také vytvoří Warning protokoly úrovně, například když se zprávy fronty odesílají do jedové fronty.
Function.<YOUR_FUNCTION_NAME> závislosti Data závislostí se automaticky shromažďují pro některé služby. Pro úspěšná spuštění jsou tyto protokoly na Information úrovni. Další informace najdete v tématu Závislosti. Výjimky se protokolují na Error úrovni. Modul runtime také vytvoří Warning protokoly úrovně, například když se zprávy fronty odesílají do jedové fronty.
Function.<YOUR_FUNCTION_NAME> customMetrics
customEvents		 Sady C# a JavaScript SDK umožňují shromažďovat vlastní metriky a protokolovat vlastní události. Další informace najdete v tématu Vlastní telemetrická data.
Function.<YOUR_FUNCTION_NAME> stopy Zahrnuje spuštěné a dokončené protokoly pro konkrétní spuštění funkce. Pro úspěšná spuštění jsou tyto protokoly na Information úrovni. Výjimky se protokolují na Error úrovni. Modul runtime také vytvoří Warning protokoly úrovně, například když se zprávy fronty odesílají do jedové fronty.
Function.<YOUR_FUNCTION_NAME>.User stopy Uživatelem generované protokoly, které můžou být jakékoli úrovně protokolu. Další informace o zápisu do protokolů z funkcí najdete v tématu Zápis do protokolů.
Host.Aggregator customMetrics Tyto protokoly generované modulem runtime poskytují počty a průměry volání funkcí v konfigurovatelném časovém období. Výchozí období je 30 sekund nebo 1 000 výsledků podle toho, co nastane dříve. Příklady jsou počet spuštění, úspěšnosti a doby trvání. Všechny tyto protokoly se zapisují na Information úrovni. Pokud filtrujete na Warning nebo vyšší, žádná z těchto dat se nezobrazí.
Host.Results požaduje Tyto protokoly generované modulem runtime označují úspěch nebo selhání funkce. Všechny tyto protokoly se zapisují na Information úrovni. Pokud filtrujete na Warning nebo vyšší, žádná z těchto dat se nezobrazí.
Microsoft stopy Plně kvalifikovaná kategorie protokolu, která odráží komponentu modulu runtime .NET vyvolanou hostitelem.
Worker stopy Protokoly generované pracovním procesem jazyka pro non-.NET jazyky. Protokoly pracovních procesů jazyka mohou být také protokolovány do Microsoft.* kategorie, například Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. Tyto protokoly se zapisují na Information úrovni.

Poznámka:

U funkcí knihovny tříd .NET tyto kategorie předpokládají, že používáte ILogger , a ne ILogger<T>. Další informace najdete v dokumentaci k funkcím ILogger.

Sloupec Tabulka označuje, do které tabulky v Application Insights se protokol zapíše.

Konfigurace úrovní protokolu

Ke každému protokolu se přiřadí úroveň protokolu. Hodnota je celé číslo, které označuje relativní důležitost:

ÚroveňProtokolu Kód Popis
Trasování 0 Protokoly, které obsahují nejpodrobnější zprávy. Tyto zprávy můžou obsahovat citlivá data aplikace. Tyto zprávy jsou ve výchozím nastavení zakázané a nikdy by neměly být povolené v produkčním prostředí.
Ladění 0 Protokoly, které se používají k interaktivnímu šetření během vývoje. Tyto protokoly by měly obsahovat především informace užitečné pro ladění a nemají dlouhodobou hodnotu.
Informační 2 Protokoly, které sledují obecný tok aplikace. Tyto protokoly by měly mít dlouhodobou hodnotu.
Upozorňující 3 Protokoly, které zvýrazňují neobvyklou nebo neočekávanou událost v toku aplikace, ale jinak nezpůsobí zastavení spuštění aplikace.
Chyba 4 Protokoly, které zvýrazňují, když je aktuální tok spuštění zastaven kvůli selhání. Tyto chyby by měly značí selhání v aktuální aktivitě, nikoli selhání na úrovni aplikace.
Kritické 5 Protokoly, které popisují neopravitelnou aplikaci nebo systémovou chybu nebo katastrofické selhání, které vyžaduje okamžitou pozornost.
Nic 6 Zakáže protokolování pro zadanou kategorii.

Konfigurace host.json souboru určuje, kolik protokolování aplikace funkcí odesílá do Application Insights.

Pro každou kategorii označíte minimální úroveň protokolu, kterou chcete odeslat. Nastavení host.json se liší v závislosti na verzi modulu runtime služby Functions.

Následující příklady definují protokolování na základě následujících pravidel:

  • Výchozí úroveň protokolování je nastavená tak, aby Warning se zabránilo nadměrnému protokolování pro neočekávané kategorie.
  • Host.Aggregator a Host.Results jsou nastaveny na nižší úrovně. Nastavení příliš vysoké úrovně protokolování (zejména vyšší než Information) může vést ke ztrátě metrik a dat o výkonu.
  • Protokolování spuštění funkce je nastaveno na Informationhodnotu . V případě potřeby můžete toto nastavení přepsat v místním vývoji na Debug nebo Trace.
{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

Pokud host.json obsahuje více protokolů, které začínají stejným řetězcem, budou se nejprve shodovat s více definovanými protokoly. Podívejte se na následující příklad, který protokoluje vše v modulu runtime s výjimkou Host.Aggregator, na Error úrovni:

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

Nastavením None úrovně protokolu můžete zabránit zápisu protokolů pro kategorii.

Upozornění

Azure Functions se integruje s Application Insights uložením událostí telemetrie do tabulek Application Insights. Pokud nastavíte úroveň protokolu kategorií na jinou Informationhodnotu než , zabrání to toku telemetrie do těchto tabulek a nebudete moct zobrazit související data na kartách Application Insights a Monitorování funkcí.

Například pro předchozí ukázky:

  • Pokud nastavíte Host.Results kategorii na Error úroveň protokolu, Azure shromáždí v tabulce pouze události requests telemetrie spouštění hostitele pro neúspěšné provádění funkcí, což brání zobrazení podrobností o spuštění hostitele úspěšných spuštění na kartách Application Insights i monitorování funkcí.
  • Pokud nastavíte Function kategorii na Error úroveň protokolu, zastaví se shromažďování telemetrických dat funkcí souvisejících s dependencies, customMetricsa customEvents pro všechny funkce, což vám brání v zobrazení jakéhokoli z těchto dat v Application Insights. Azure shromažďuje pouze traces protokolované na Error úrovni.

V obou případech Azure dál shromažďuje data o chybách a výjimkách na kartách Application Insights a Monitorování funkcí. Další informace najdete v tématu Řešení s velkým objemem telemetrie.

Konfigurace agregátoru

Jak je uvedeno v předchozí části, modul runtime agreguje data o provádění funkcí v určitém časovém období. Výchozí období je 30 sekund nebo 1 000 spuštění, podle toho, co nastane dříve. Toto nastavení můžete nakonfigurovat v souboru host.json. Příklad:

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

Konfigurace vzorkování

Application Insights má funkci vzorkování , která vás může chránit před vytvářením příliš velkého množství telemetrických dat při dokončených spuštěních v době špičky zatížení. Když míra příchozích spuštění překročí zadanou prahovou hodnotu, Application Insights začne některá z příchozích spuštění náhodně ignorovat. Maximální počet spuštění za sekundu je ve výchozím nastavení 20 (5 ve verzi 1.x). Vzorkování můžete nakonfigurovat v host.json. Tady je příklad:

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

Z vzorkování můžete vyloučit určité typy telemetrie. V tomto příkladu jsou data typu Request a Exception jsou vyloučena z vzorkování. Zajišťuje, že se zaprotokolují všechna spuštění funkcí (požadavky) a výjimky, zatímco jiné typy telemetrie zůstanou předmětem vzorkování.

Pokud váš projekt používá závislost na sadě Application Insights SDK k ručnímu sledování telemetrie, může docházet k neobvyklému chování, pokud se konfigurace vzorkování liší od konfigurace vzorkování ve vaší aplikaci funkcí. V takových případech použijte stejnou konfiguraci vzorkování jako aplikace funkcí. Další informace najdete v tématu Vzorkování v Application Insights.

Povolení shromažďování dotazů SQL

Application Insights automaticky shromažďuje data o závislostech pro požadavky HTTP, volání databáze a několik vazeb. Další informace najdete v tématu Závislosti. U volání SQL se název serveru a databáze vždy shromažďuje a ukládá, ale text dotazu SQL se ve výchozím nastavení neshromažďuje. K dependencyTrackingOptions.enableSqlCommandTextInstrumentation povolení protokolování textu dotazu SQL můžete použít následující nastavení (minimálně) v souboru host.json:

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

Další informace najdete v tématu Rozšířené sledování SQL pro získání úplného dotazu SQL.

Konfigurace protokolů kontroleru škálování

Tato funkce je ve verzi Preview.

Kontroler škálování Azure Functions může generovat protokoly do Application Insights nebo do úložiště objektů blob, abyste lépe pochopili rozhodnutí, která kontroler škálování provádí pro vaši aplikaci funkcí.

Pokud chcete tuto funkci povolit, přidejte do nastavení aplikace funkcí nastavení aplikace.SCALE_CONTROLLER_LOGGING_ENABLED Následující hodnota nastavení musí být ve formátu <DESTINATION>:<VERBOSITY>. Další informace najdete v následující tabulce:

Vlastnost Popis
<DESTINATION> Cíl, do kterého se protokoly odesílají. Platné hodnoty jsou AppInsights a Blob.
Při použití AppInsightsse ujistěte, že je ve vaší aplikaci funkcí povolená služba Application Insights.
Když nastavíte cíl na Blob, protokoly se vytvoří v kontejneru objektů blob pojmenovaném azure-functions-scale-controller ve výchozím účtu úložiště nastaveném AzureWebJobsStorage v nastavení aplikace.
<VERBOSITY> Určuje úroveň protokolování. Podporované hodnoty jsou None, Warninga Verbose.
Při nastavení Verbosezaznamená kontroler škálování důvod každé změny počtu pracovních procesů a informace o aktivačních událostech, které do těchto rozhodnutí započítávají. Podrobné protokoly zahrnují upozornění triggerů a hodnoty hash používané triggery před a po spuštění kontroleru škálování.

Tip

Mějte na paměti, že když necháte protokolování kontroleru škálování povolené, ovlivňuje potenciální náklady na monitorování aplikace funkcí. Zvažte povolení protokolování, dokud neshromáždíte dostatek dat, abyste pochopili, jak se řadič škálování chová, a pak ho zakazujte.

Například následující příkaz Azure CLI zapne podrobné protokolování z kontroleru škálování do Application Insights:

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

V tomto příkladu nahraďte <FUNCTION_APP_NAME> název <RESOURCE_GROUP_NAME> vaší aplikace funkcí a názvem skupiny prostředků v uvedeném pořadí.

Následující příkaz Azure CLI zakáže protokolování nastavením podrobností na None:

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

Protokolování můžete také zakázat odebráním SCALE_CONTROLLER_LOGGING_ENABLED nastavení pomocí následujícího příkazu Azure CLI:

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

S povoleným protokolováním kontroleru škálování teď můžete dotazovat protokoly kontroleru škálování.

Povolení integrace Application Insights

Aby aplikace funkcí odesílala data do Application Insights, musí se připojit k prostředku Application Insights jenom pomocí jednoho z těchto nastavení aplikace:

Název nastavení Popis
APPLICATIONINSIGHTS_CONNECTION_STRING Toto nastavení se doporučuje a vyžaduje se, když vaše instance Application Insights běží v suverénním cloudu. Připojovací řetězec podporuje další nové funkce.
APPINSIGHTS_INSTRUMENTATIONKEY Starší nastavení, které služba Application Insights přestala používat pro nastavení připojovací řetězec.

Při vytváření aplikace funkcí na webu Azure Portal z příkazového řádku pomocí nástrojů Azure Functions Core Tools nebo editoru Visual Studio Code je integrace Application Insights ve výchozím nastavení povolená. Prostředek Application Insights má stejný název jako vaše aplikace funkcí a vytvoří se buď ve stejné oblasti, nebo v nejbližší oblasti.

Vyžadování ověřování Microsoft Entra

Pomocí nastavení APPLICATIONINSIGHTS_AUTHENTICATION_STRING můžete povolit připojení k Application Insights pomocí ověřování Microsoft Entra. Tím se vytvoří konzistentní prostředí ověřování napříč všemi kanály Application Insights, včetně profileru a snapshot debuggeru, a také z hostitelů Functions a agentů specifických pro jazyk.

Poznámka:

Pro místní vývoj neexistuje žádná podpora ověřování Entra.

Hodnota obsahuje Authorization=AAD spravovanou identitu přiřazenou systémem nebo ClientId=<YOUR_CLIENT_ID>;Authorization=AAD spravovanou identitu přiřazenou uživatelem. Spravovaná identita už musí být dostupná pro aplikaci funkcí s přiřazenou rolí ekvivalentní vydavateli metrik monitorování. Další informace naleznete v tématu Ověřování Microsoft Entra pro Application Insights.

Nastavení APPLICATIONINSIGHTS_CONNECTION_STRING je stále povinné.

Poznámka:

Pokud se připojujete APPLICATIONINSIGHTS_AUTHENTICATION_STRING k Application Insights pomocí ověřování Microsoft Entra, měli byste také zakázat místní ověřování pro Application Insights. Tato konfigurace vyžaduje ověřování Microsoft Entra, aby se telemetrie mohla ingestovat do vašeho pracovního prostoru.

Nová aplikace funkcí na portálu

Pokud chcete zkontrolovat vytvořený prostředek Application Insights, vyberte ho a rozbalte okno Application Insights . Můžete změnit název nového prostředku nebo vybrat jiné umístění v zeměpisné oblasti Azure, kam chcete ukládat data.

Snímek obrazovky, který ukazuje, jak povolit Application Insights při vytváření aplikace funkcí

Když vyberete Vytvořit, vytvoří se prostředek Application Insights s vaší aplikací funkcí, která je nastavená APPLICATIONINSIGHTS_CONNECTION_STRING v nastavení aplikace. Všechno je připravené.

Přidání do existující aplikace funkcí

Pokud se prostředek Application Insights nevytvořil s vaší aplikací funkcí, vytvořte ho pomocí následujícího postupu. Potom můžete do aplikace funkcí přidat připojovací řetězec z daného prostředku jako nastavení aplikace.

  1. Na webu Azure Portal vyhledejte a vyberte aplikaci funkcí a pak vyberte svou aplikaci funkcí.

  2. Vyberte v horní části okna banner Služba Application Insights není nakonfigurovaná. Pokud tento banner nevidíte, je možné, že vaše aplikace už má povolenou službu Application Insights.

    Snímek obrazovky, který ukazuje, jak povolit Application Insights z portálu

  3. Rozbalte položku Změnit prostředek a vytvořte prostředek Application Insights pomocí nastavení uvedených v následující tabulce:

    Nastavení Navrhovaná hodnota Popis
    Nový název prostředku Jedinečný název aplikace Nejjednodušší je použít stejný název, jako má vaše aplikace funkcí, který musí být ve vašem předplatném jedinečný.
    Místo Západní Evropa Pokud je to možné, použijte stejnou oblast jako vaše aplikace funkcí nebo oblast , která je blízko této oblasti.

    Snímek obrazovky, který ukazuje, jak vytvořit prostředek Application Insights

  4. Vyberte Použít.

    Prostředek Application Insights se vytvoří ve stejné skupině prostředků a předplatném jako vaše aplikace funkcí. Po vytvoření prostředku zavřete okno Application Insights .

  5. V aplikaci funkcí rozbalte Nastavení a pak vyberte Proměnné prostředí. Pokud se na kartě Nastavení aplikace zobrazí nastavení aplikace s názvem APPLICATIONINSIGHTS_CONNECTION_STRINGIntegrace Application Insights, je povolená pro vaši aplikaci funkcí spuštěnou v Azure. Pokud toto nastavení neexistuje, přidejte ho pomocí application Insights připojovací řetězec jako hodnotu.

Poznámka:

Starší aplikace funkcí můžou místo APPINSIGHTS_INSTRUMENTATIONKEY APPLICATIONINSIGHTS_CONNECTION_STRING. Pokud je to možné, aktualizujte aplikaci tak, aby místo instrumentačního klíče používala připojovací řetězec.

Zákaz integrovaného protokolování

Dřívější verze funkcí používaly integrované monitorování, které se už nedoporučuje. Když povolíte Application Insights, zakažte integrované protokolování, které používá Azure Storage. Integrované protokolování je užitečné pro testování s lehkými úlohami, ale není určené pro použití v produkčním prostředí s vysokým zatížením. Pro produkční monitorování doporučujeme Application Insights. Pokud používáte integrované protokolování v produkčním prostředí, může být záznam protokolování neúplný kvůli omezování ve službě Azure Storage.

Pokud chcete zakázat integrované protokolování, odstraňte AzureWebJobsDashboard nastavení aplikace. Další informace o tom, jak odstranit nastavení aplikace na webu Azure Portal, najdete v části Nastavení aplikace v části Správa aplikace funkcí. Před odstraněním nastavení aplikace se ujistěte, že žádné existující funkce ve stejné aplikaci funkcí nepoužívají nastavení pro triggery nebo vazby azure Storage.

Řešení s velkým objemem telemetrie

Aplikace funkcí jsou základní součástí řešení, která můžou způsobit velké objemy telemetrie, jako jsou řešení IoT, rychlá řešení řízená událostmi, finanční systémy s vysokým zatížením a systémy integrace. V takovém případě byste měli zvážit další konfiguraci, abyste snížili náklady při zachování pozorovatelnosti.

Vygenerovaná telemetrie je možné využívat na řídicích panelech v reálném čase, upozorňování, podrobnou diagnostiku atd. V závislosti na tom, jak se generuje telemetrie, je potřeba definovat strategii pro snížení objemu vygenerovaných dat. Tato strategie umožňuje správně monitorovat, provozovat a diagnostikovat aplikace funkcí v produkčním prostředí. Zvažte následující možnosti:

  • Použití vzorkování: Jak už bylo zmíněno dříve, vzorkování pomáhá výrazně snížit objem přijatých telemetrických událostí při zachování statisticky správné analýzy. Může se stát, že i při použití vzorkování stále získáte velký objem telemetrie. Prozkoumejte možnosti, které vám adaptivní vzorkování poskytuje. Nastavte maxTelemetryItemsPerSecond například hodnotu, která vyrovnává svazek vygenerovaný vašimi potřebami monitorování. Mějte na paměti, že vzorkování telemetrie se používá na hostitele, který spouští vaši aplikaci funkcí.

  • Výchozí úroveň protokolu: Použijte Warning nebo Error jako výchozí hodnotu pro všechny kategorie telemetrie. Později se můžete rozhodnout, které kategorie chcete nastavit na Information úrovni, abyste mohli správně monitorovat a diagnostikovat funkce.

  • Ladění telemetrie funkcí: S výchozí úrovní protokolu nastavenou na Error nebo Warningse shromažďují žádné podrobné informace z každé funkce (závislosti, vlastní metriky, vlastní události a trasování). Pro tyto funkce, které jsou klíčem pro monitorování v produkčním Function.<YOUR_FUNCTION_NAME> prostředí, definujte explicitní položku pro kategorii a nastavte ji na Information, abyste mohli shromáždit podrobné informace. Pokud se chcete vyhnout shromažďování uživatelem generovaných protokolů na Information úrovni, nastavte Function.<YOUR_FUNCTION_NAME>.User kategorii na Error úroveň protokolu.Warning

  • Kategorie Host.Aggregator: Jak je popsáno v kategoriích konfigurace, tato kategorie poskytuje agregované informace o vyvolání funkcí. Informace z této kategorie se shromažďují v tabulce Application Insights customMetrics a zobrazují se na kartě Přehled funkce na webu Azure Portal. V závislosti na tom, jak agregátor konfigurujete, zvažte, že v telemetrii shromážděných telemetrií může dojít ke zpoždění určenému flushTimeout nastavením. Pokud nastavíte tuto kategorii na jinou hodnotu než Information, zastavíte shromažďování dat v customMetrics tabulce a nezobrazíte metriky na kartě Přehled funkce.

    Následující snímek obrazovky ukazuje Host.Aggregator telemetrická data zobrazená na kartě Přehled funkce:

    Snímek obrazovky znázorňující telemetrii Host.Aggregator zobrazenou na kartě Přehled funkce

    Následující snímek obrazovky ukazuje Host.Aggregator telemetrická data v tabulce Application Insights customMetrics :

    Snímek obrazovky znázorňující telemetrii Host.Aggregator v tabulce CustomMetrics Application Insights

  • Kategorie Host.Results: Jak je popsáno v konfiguraci kategorií, poskytuje tato kategorie protokoly generované modulem runtime, které označují úspěch nebo selhání vyvolání funkce. Informace z této kategorie se shromažďují v tabulce Application Insights requests a zobrazují se na kartě Monitorování funkcí a v různých řídicích panelech Application Insights (Výkon, Selhání atd.). Pokud nastavíte tuto kategorii na jinou hodnotu než Information, shromáždíte pouze telemetrii vygenerovanou na úrovni protokolu definované (nebo vyšší). Například nastavením na error výsledky sledování dat požadavků pouze pro neúspěšná spuštění.

    Následující snímek obrazovky ukazuje Host.Results telemetrická data zobrazená na kartě Monitorování funkcí:

    Snímek obrazovky znázorňující telemetrii Host.Results na kartě Monitorování funkce

    Následující snímek obrazovky ukazuje Host.Results telemetrická data zobrazená na řídicím panelu výkonu Application Insights:

    Snímek obrazovky znázorňující telemetrii Host.Results na řídicím panelu výkonu Application Insights

  • Host.Aggregator vs Host.Results: Obě kategorie poskytují dobré přehledy o provádění funkcí. V případě potřeby můžete z jedné z těchto kategorií odebrat podrobné informace, abyste je mohli použít k monitorování a upozorňování. Tady je ukázkový skript:

{
  "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"
      }
    }
  }
}

S touto konfigurací:

  • Výchozí hodnota pro všechny funkce a kategorie telemetrie je nastavená na Warning (včetně kategorií Microsoft a Worker). Ve výchozím nastavení se proto shromažďují všechny chyby a upozornění vygenerovaná modulem runtime a vlastním protokolováním.

  • Úroveň Function protokolu kategorií je nastavená na Error, takže pro všechny funkce se ve výchozím nastavení shromažďují pouze výjimky a protokoly chyb. Závislosti, metriky generované uživatelem a události generované uživatelem se přeskočí.

  • Host.Aggregator Pro kategorii, protože je nastavená na Error úroveň protokolu, agregované informace z vyvolání funkcí se neshromažďují v customMetrics tabulce Application Insights a informace o počtech spuštění (celkový, úspěšný a neúspěšný) se na řídicím panelu přehledu funkce nezobrazují.

  • Host.Results Pro kategorii se shromažďují všechny informace o spuštění hostitele v requests tabulce Application Insights. Všechny výsledky vyvolání se zobrazují na řídicím panelu monitorování funkcí a v řídicích panelech Application Insights.

  • Pro funkci s názvem Function1nastavíme úroveň protokolu na Informationhodnotu . U této konkrétní funkce se tedy shromažďuje veškerá telemetrie (závislost, vlastní metriky a vlastní události). Pro stejnou funkci nastavíme Function1.User kategorii (trasování generovaná uživatelem), Erroraby se shromáždilo pouze vlastní protokolování chyb.

    Poznámka:

    Konfigurace pro každou funkci není v modulu runtime Functions v1.x podporovaná.

  • Vzorkování se konfiguruje tak, aby posílala jednu položku telemetrie za sekundu za sekundu a s výjimkou výjimek. K tomuto vzorkování dochází u každého hostitele serveru, na kterém běží naše aplikace funkcí. Pokud tedy máme čtyři instance, tato konfigurace generuje čtyři položky telemetrie za sekundu za jeden typ a všechny výjimky, ke kterým může dojít.

    Poznámka:

    Počty metrik, jako je frekvence požadavků a míra výjimek, se upraví tak, aby se kompenzuje vzorkovací frekvence, aby zobrazovaly přibližně správné hodnoty v Průzkumníku metrik.

Tip

Experimentujte s různými konfiguracemi a ujistěte se, že splňujete požadavky na protokolování, monitorování a upozorňování. Také se ujistěte, že máte podrobnou diagnostiku v případě neočekávaných chyb nebo selhání.

Přepsání konfigurace monitorování za běhu

Nakonec může docházet k situacím, kdy potřebujete rychle změnit chování protokolování určité kategorie v produkčním prostředí a nechcete provést celé nasazení jen pro změnu v souboru host.json . V takových případech můžete přepsat host.json hodnoty.

Pokud chcete tyto hodnoty nakonfigurovat na úrovni nastavení aplikace (a vyhnout se opětovnému nasazení jenom host.json změn), měli byste určité host.json hodnoty přepsat tak, že vytvoříte ekvivalentní hodnotu jako nastavení aplikace. Když modul runtime najde nastavení aplikace ve formátu, přepíše ekvivalentní host.json nastavení umístěné ve path.to.setting formátu AzureFunctionsJobHost__path__to__settingJSON. Když je vyjádřeno jako nastavení aplikace, dvojité podtržítko (__) nahradí tečku (.) použitou k označení hierarchie JSON. Můžete například použít následující nastavení aplikace ke konfiguraci jednotlivých úrovní protokolu funkcí v host.json.

cesta Host.json Nastavení aplikace
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

Nastavení můžete přepsat přímo v podokně Konfigurace aplikace funkcí webu Azure Portal nebo pomocí Azure CLI nebo skriptu PowerShellu.

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"

Poznámka:

host.json Přepsáním změny nastavení aplikace se vaše aplikace funkcí restartuje. Nastavení aplikace, která obsahují období, se nepodporuje při spouštění v Linuxu v plánu Elastic Premium nebo plánu Dedicated (App Service). V těchto hostitelských prostředích byste měli dál používat soubor host.json .

Monitorování aplikací funkcí pomocí kontroly stavu

Pomocí funkce Kontrola stavu můžete monitorovat aplikace funkcí v plánech Premium (Elastic Premium) a Dedicated (App Service). Kontrola stavu není pro plán Consumption dostupná. Informace o tom, jak ho nakonfigurovat, najdete v tématu Monitorování instancí služby App Service pomocí kontroly stavu. Aplikace funkcí by měla mít funkci triggeru HTTP, která reaguje stavovým kódem HTTP 200 ve stejném koncovém bodu, který je nakonfigurovaný na Path parametru kontroly stavu. Můžete také mít, aby tato funkce prováděla dodatečné kontroly, aby se zajistilo, že závislé služby jsou dostupné a funkční.

Související obsah

Další informace o monitorování najdete tady: