Konfigurace monitorování pro Azure Functions

  • Článek

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

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

Dále v tomto článku se dozvíte, jak nakonfigurovat a přizpůsobit data, která vaše funkce odesílají do aplikace Přehledy. Běžnou konfiguraci protokolování je možné nastavit v souboru host.json. Ve výchozím nastavení tato nastavení také řídí vlastní protokoly generované vaším kódem, ale v některých případech může být toto chování zakázáno ve prospěch možností, které vám dávají větší kontrolu nad protokolováním. Další informace najdete v protokolech vlastních 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í. To vám umožní efektivně změnit nastavení host.json , aniž byste museli znovu publikovat soubor host.json v projektu. 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é zapíšete, posílají hostiteli Functions, který je pak odešle do aplikace Přehledy prostřednictvím kategorie Pracovní proces. Některé zásobníky jazyka umožňují místo toho odesílat protokoly přímo do aplikačního Přehledy, takže máte plnou kontrolu nad tím, jak se protokoly generují. Kanál protokolování se změní z worker -> Functions host -> Application Insights na worker -> Application Insights.

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

Zásobník jazyků Konfigurace vlastních protokolů
.NET (model v procesu) host.json
.NET (izolovaný model) Ve výchozím nastavení: host.json
Možnost odesílat protokoly přímo: Konfigurace Přehledy aplikace v nástroji HostBuilder
Node.JS host.json
Python host.json
Java Ve výchozím nastavení: host.json
Možnost odesílat protokoly přímo: Konfigurace agenta Java Přehledy aplikace
PowerShell host.json

Když se vlastní protokoly aplikací odesílají přímo, hostitel je už nevysílají a host.json už jeho chování nespouští. 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. Pokud chcete řídit chování všech protokolů, možná budete muset provést změny pro obě konfigurace.

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í graf 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 podle Warning nebo výše, neuvidíte žádná z těchto dat.
Host.Results Požadavky Tyto protokoly generované modulem runtime označují úspěch nebo selhání funkce. Všechny tyto protokoly se zapisují na Information úrovni. Pokud filtrujete podle Warning nebo výše, neuvidíte žádná z těchto dat.
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 aplikaci Přehledy je protokol zapsán.

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 souboru host.json určuje, kolik protokolování aplikace funkcí odesílá do aplikačního Přehledy.

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í na příliš vysokou úroveň (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 . To lze v případě potřeby přepsat v místním vývoji nebo TraceDebug v případě potřeby.
{
  "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 aplikačními Přehledy ukládáním událostí telemetrie do tabulek Přehledy aplikací. Nastavením úrovně protokolu kategorií na libovolnou hodnotu, která se liší od Information této hodnoty, zabráníte telemetrii toku do těchto tabulek. V důsledku toho neuvidíte související data na kartě Application Přehledy ani Function Monitor.

Z výše uvedených ukázek:

  • Host.Results Pokud je kategorie nastavená na Error úroveň protokolu, bude shromažďovat telemetrické události spouštění hostitele pouze v requests tabulce pro neúspěšné provádění funkcí, což brání zobrazení podrobností o spuštění hostitele při úspěšných spuštěních na kartě Application Přehledy i Sledování funkcí.
  • Function Pokud je kategorie nastavená na Error úroveň protokolu, zastaví shromažďování telemetrických dat funkcí souvisejících s dependencies, customMetricsa customEvents pro všechny funkce, které brání zobrazit některá z těchto dat v aplikaci Přehledy. Shromáždí traces se pouze protokolovaná s Error úrovní.

V obou případech budete dál shromažďovat data o chybách a výjimkách na kartě Application Přehledy 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. Tady je příklad:

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

Konfigurace vzorkování

Aplikace Přehledy 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 souboru 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í. Zajistí, ž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 využívá závislost na sadě Application Přehledy SDK k ručnímu sledování telemetrie, může dojít 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 Přehledy aplikace.

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

Aplikační Přehledy 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. Protokolování dependencyTrackingOptions.enableSqlCommandTextInstrumentation textu dotazu SQL můžete povolit nastavením (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 aplikačních Přehledy 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, můžete do nastavení aplikace funkcí přidat nastavení aplikace s názvem SCALE_CONTROLLER_LOGGING_ENABLED . Následující hodnota nastavení musí být ve formátu <DESTINATION>:<VERBOSITY>:

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á Přehledy aplikace funkcí.
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 aplikačního Přehledy:

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 Přehledy aplikace, musí se připojit k prostředku aplikace Přehledy pomocí pouze jednoho z těchto nastavení aplikace:

Název nastavení Popis
APPLICATIONINSIGHTS_CONNECTION_STRING Toto je doporučené nastavení, které se vyžaduje, když vaše instance Přehledy aplikace běží v suverénním cloudu. Připojovací řetězec podporuje další nové funkce.
APPINSIGHTS_INSTRUMENTATIONKEY Starší nastavení, které je zastaralé aplikací Přehledy ve prospěch 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 ve výchozím nastavení povolená integrace Přehledy aplikací. Prostředek Přehledy aplikace má stejný název jako vaše aplikace funkcí a vytvoří se buď ve stejné oblasti, nebo v nejbližší oblasti.

Nová aplikace funkcí na portálu

Pokud chcete zkontrolovat vytvářený prostředek Přehledy aplikace, vyberte ho a rozbalte okno Přehledy aplikace. 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.

Screenshot of enabling Application Insights while creating a function app.

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

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

Pokud se prostředek aplikace Přehledy 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á povolené Přehledy aplikace.

    Screenshot of enabling Application Insights from the portal.

  3. Rozbalte položku Změnit prostředek a vytvořte prostředek Přehledy aplikace 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.

    Screenshot of creating an Application Insights resource.

  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 Přehledy aplikace.

  5. V aplikaci funkcí vyberte v části Nastavení možnost Konfigurace a pak vyberte Nastavení aplikace. Pokud se zobrazí nastavení s názvem APPLICATIONINSIGHTS_CONNECTION_STRING, je pro vaši aplikaci funkcí běžící v Azure povolena integrace Application Insights. Pokud z nějakého důvodu toto nastavení neexistuje, přidejte ho jako hodnotu pomocí aplikace Přehledy připojovací řetězec.

Poznámka:

Starší aplikace funkcí můžou používat APPINSIGHTS_INSTRUMENTATIONKEY místo APPLICATIONINSIGHTS_CONNECTION_STRING. Pokud je to možné, měli byste aplikaci aktualizovat 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 Přehledy aplikace, 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 monitorování v produkčním prostředí doporučujeme Přehledy aplikace. Pokud se integrované protokolování používá 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 bude generovat telemetrie, budete muset definovat strategii pro snížení objemu vygenerovaných dat. Tato strategie vám umožní správně monitorovat, provozovat a diagnostikovat aplikace funkcí v produkčním prostředí. Můžete zvážit následující možnosti:

  • Použití vzorkování: Jak už jsme zmínili dříve, pomůže 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. Teď se můžete rozhodnout, které kategorie chcete nastavit na Information úrovni, abyste mohli správně monitorovat a diagnostikovat funkce.

  • Vyladění telemetrie funkcí: S výchozí úrovní protokolu nastavenou na Error nebo Warningse nebudou shromažďovat žádné podrobné informace z jednotlivých funkcí (závislosti, vlastní metriky, vlastní události a trasování). Pro tyto funkce, které jsou klíčem pro monitorování v produkčním prostředí, definujte explicitní položku pro Function.<YOUR_FUNCTION_NAME> kategorii a nastavte ji na Information, abyste mohli shromáždit podrobné informace. V tomto okamžiku se chcete vyhnout shromažďování uživatelsky 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 shromáždí v tabulce Přehledy customMetrics aplikace a zobrazí se na kartě Přehled funkce na webu Azure Portal. V závislosti na tom, jak agregátor konfigurujete, zvažte, že v telemetrii, která flushTimeoutse shromáždila, dojde ke zpoždění. Pokud nastavíte tuto kategorii na jinou hodnotu než Information, zastavíte shromažďování dat v customMetrics tabulce a na kartě Přehled funkce se nezobrazí metriky.

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

    Screenshot of Host.Aggregator telemetry displayed in function Overview tab.

    Následující snímek obrazovky ukazuje Host.Aggregator telemetrická data v tabulce Přehledy customMetrics aplikace:

    Screenshot of Host.Aggregator telemetry in customMetrics Application Insights table.

  • 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 Přehledy requests aplikace a zobrazují se na kartě Monitorování funkcí a v různých řídicích panelech Přehledy aplikací (Výkon, Selhání atd.). Pokud nastavíte tuto kategorii na jinou hodnotu než Information, budete shromažďovat telemetrii vygenerovanou pouze 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í:

    Screenshot of Host.Results telemetry in function Monitor tab.

    Následující snímek obrazovky ukazuje Host.Results telemetrická data zobrazená na řídicím panelu Výkon Přehledy aplikace:

    Screenshot of Host.Results telemetry in Application Insights Performance dashboard.

  • 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í budete mít:

  • 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 Protože je kategorie nastavená na Error úroveň protokolu, agregované informace z vyvolání funkcí se nebudou customMetrics shromažďovat v tabulce Přehledy aplikace a informace o počtech spuštění (celkový, úspěšný a neúspěšný) se na řídicím panelu přehledu funkcí nezobrazí.

  • Host.Results Pro kategorii se shromažďují všechny informace o spuštění hostitele v requests tabulce Přehledy aplikace. Všechny výsledky vyvolání se zobrazí na řídicím panelu Monitorování funkcí a v řídicích panelech Přehledy aplikací.

  • Pro funkci s názvem Function1jsme nastavili ú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). U stejné funkce Function1.User je kategorie (trasování generovaná uživatelem) nastavená na Error, takže se shromáždí pouze vlastní protokolování chyb.

    Poznámka:

    Konfigurace pro každou funkci není v 1.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í dojde u každého hostitele serveru, na kterém běží naše aplikace funkcí. Pokud tedy máme čtyři instance, tato konfigurace vygeneruje č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 hodnoty host.json.

Pokud chcete tyto hodnoty nakonfigurovat na úrovni nastavení aplikace (a vyhnout se opětovnému nasazení jenom změn v souboru host.json ), měli byste určité host.json hodnoty přepsat vytvořením ekvivalentní hodnoty 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. Pokud je vyjádřeno jako nastavení aplikace, tečka (.) použitá k označení hierarchie JSON se nahradí dvojitým podtržítkem (__). Můžete například použít následující nastavení aplikace ke konfiguraci jednotlivých úrovní protokolu funkcí, jak je uvedeno výše 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 okně 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í možností pro plán Consumption. 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 na stejném koncovém bodu, který je nakonfigurovaný v parametru Path 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í.

Další kroky

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