Konfigurace monitorování pro Azure Functions

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í.

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:

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ří:

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:

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

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Host.Results": "Information",
        "Host.Aggregator": "Trace",
        "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"
    }
  }
}

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Information",
      "categoryLevels": {
        "Host": "Error",
        "Function": "Error",
        "Host.Aggregator": "Information"
      }
    }
  }
}

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

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

{
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

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:

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:

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.

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é.

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.

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.

   

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.

   

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.

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:

  

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

  

• 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í:

  

  Následující snímek obrazovky ukazuje Host.Results telemetrická data zobrazená 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"
      }
    }
  }
} 

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Function": "Error",
        "Host.Aggregator": "Error",
        "Host.Results": "Information",
        "Host.Executor": "Warning"
      }
    }
  },
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

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.

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.

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"

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host__Aggregator" = "Information"}

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:

• Monitorování Azure Functions
• Analýza telemetrických dat Azure Functions v Application Insights
• Přehled Application Insights