如何設定 Azure Functions 的監視

發行項
08/06/2024

Azure Functions 與 Application Insights 整合，讓您更能監視函式應用程式。 Application Insights 是 Azure 監視器的一項功能，是可延伸的應用程式效能管理 (APM) 服務，可收集函式應用程式所產生的資料，包括應用程式寫入記錄的資訊。建立函式應用程式時，通常會啟用 Application Insights 整合。如果您的應用程式沒有檢測金鑰集，您必須先啟用 Application Insights 整合。

您可以使用 Application Insights，而不需任何自訂設定。然而，預設設定可能會導致大量資料。如果您使用 Visual Studio Azure 訂用帳戶，可能就會達到 Application Insights 適用的資料上限。如需 Application Insights 成本的資訊，請參閱 Application Insights 計費。如需詳細資訊，請參閱具有大量遙測的解決方案。

您將在本文中了解如何設定及自訂函數傳送到 Application Insights 的資料。您可以在 host.json 檔案中設定常用的記錄設定。根據預設，這些設定也會控管程式碼發出的自訂記錄。不過，在某些情況下您可以停用此行為，以改為使用可讓您更充分掌控記錄的選項。如需詳細資訊，請參閱自訂應用程式記錄。

注意

您可以使用特別設定的應用程式設定來代表 host.json 檔案中的特定設定，並用於特定環境。這可讓您有效地變更 host.json 設定，而不需要重新發佈專案中的 host.json 檔案。如需詳細資訊，請參閱覆寫 host.json 值。

自訂應用程式記錄檔

根據預設，您寫入的自訂應用程式記錄會傳送至 Functions 主機，然後主機會將記錄傳送至 Application Insights 底下的「背景工作角色」類別。某些語言堆疊可讓您改為將記錄直接傳送至 Application Insights，可讓您完全掌控寫入記錄的發出方式。在此案例中，記錄管線會從 worker -> Functions host -> Application Insights 變更為 worker -> Application Insights。

下表摘要列出每個堆疊可以使用的設定選項：

語言堆疊	設定自訂記錄的位置
.NET (內含式模型)	`host.json`
.NET (隔離式模型)	預設 (將自訂記錄傳送至 Functions 主機)：`host.json` 若要直接將記錄傳送至 Application Insights，請參閱：在 HostBuilder 中設定 Application Insights
Node.JS	`host.json`
Python	`host.json`
Java	預設 (將自訂記錄傳送至 Functions 主機)：`host.json` 若要直接將記錄傳送至 Application Insights，請參閱：設定 Application Insights Java 代理程式
PowerShell	`host.json`

設定為直接傳送自訂應用程式記錄時，主機不會再發出這些記錄，且 host.json 不再控制其行為。同樣地，每個堆疊所公開的選項只會套用至自訂記錄，且不會變更本文所述的其他執行階段記錄行為。在此案例中，若要控制所有記錄的行為，您可能需要變更這兩種設定。

設定類別

Azure Functions 記錄器包括每個記錄的「類別」。類別指出寫入記錄的是哪個部分的執行階段程式碼或函式程式碼。 1.x 版與更新版本之間的類別不同。

相較於其他 .NET 架構，在 Functions 中會以不同方式指派類別名稱。例如，當您在 ASP.NET 中使用 ILogger<T> 時，類別是泛型型別的名稱。 C# 函式也會使用 ILogger<T>，但不是將泛型型別名稱設定為類別，而是由執行階段根據來源指派類別。例如：

系統會將類別 Function.<FUNCTION_NAME> 指派給與執行函式相關的項目。
由函式中使用者程式碼所建立的項目，例如呼叫 logger.LogInformation() 時，會獲得類別 Function.<FUNCTION_NAME>.User 指派。

下表說明執行階段所建立記錄的主要類別：

v2.x+
v1.x

類別	資料表	Description
`Function`	traces	包含所有函式執行的函式已啟動和函式已完成記錄。針對成功的執行，這些記錄均位於 `Information` 層級。例外狀況會記錄於 `Error` 層級。執行階段也會建立 `Warning` 層級的記錄，像是將佇列訊息傳送至有害佇列時。
`Function.<YOUR_FUNCTION_NAME>`	相依性	會針對某些服務自動收集相依性資料。針對成功的執行，這些記錄均位於 `Information` 層級。如需詳細資訊，請參閱相依性。例外狀況會記錄於 `Error` 層級。執行階段也會建立 `Warning` 層級的記錄，像是將佇列訊息傳送至有害佇列時。
`Function.<YOUR_FUNCTION_NAME>`	customMetrics customEvents	C# 和 JavaScript SDK 可讓您收集自訂計量和記錄自訂事件。如需詳細資訊，請參閱自訂遙測資料。
`Function.<YOUR_FUNCTION_NAME>`	traces	包含特定函式執行的函式已啟動和函式已完成記錄。針對成功的執行，這些記錄均位於 `Information` 層級。例外狀況會記錄於 `Error` 層級。執行階段也會建立 `Warning` 層級的記錄，像是將佇列訊息傳送至有害佇列時。
`Function.<YOUR_FUNCTION_NAME>.User`	traces	使用者產生的記錄，可能屬於任何記錄層級。如需從函式寫入記錄的詳細資訊，請參閱寫入至記錄。
`Host.Aggregator`	customMetrics	這些執行階段產生的記錄會透過可設定的期間來提供函式引動過程的計數與平均。預設期間為 30 秒或 1,000 個結果，視何者較早達到而定。範例包括執行次數、成功率和持續時間。所有這些記錄都會在 `Information` 層級寫入。若您在 `Warning` 或更高層級進行篩選，就不會看到此資料。
`Host.Results`	requests	這些執行階段產生的記錄表示函式的成功或失敗。所有這些記錄都會在 `Information` 層級寫入。若您在 `Warning` 或更高層級進行篩選，就不會看到此資料。
`Microsoft`	traces	完整記錄類別，反映主機所叫用的 .NET 執行階段元件。
`Worker`	traces	針對非 .NET 語言，由語言背景工作處理序所產生的記錄。在 `Microsoft.*` 類別中也可能記錄語言背景工作記錄，例如 `Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher`。這些記錄都會在 `Information` 層級寫入。

注意

對於 .NET 類別庫函式，這些類別會假設您使用的是 ILogger，而不是 ILogger<T>。如需詳細資訊，請參閱Functions ILogger 文件。

類別	資料表	Description
`Function`	traces	使用者產生的記錄，可能屬於任何記錄層級。如需從函式寫入記錄的詳細資訊，請參閱寫入至記錄。
`Host.Aggregator`	customMetrics	這些執行階段產生的記錄會透過可設定的期間來提供函式引動過程的計數與平均。預設期間為 30 秒或 1,000 個結果，視何者較早達到而定。範例包括執行次數、成功率和持續時間。所有這些記錄都會在 `Information` 層級寫入。若您在 `Warning` 或更高層級進行篩選，就不會看到此資料。
`Host.Executor`	traces	包含特定函式執行的函式已啟動和函式已完成記錄。針對成功的執行，這些記錄均位於 `Information` 層級。例外狀況會記錄於 `Error` 層級。執行階段也會在 `Warning` 層級建立記錄，例如當佇列訊息傳送至有害佇列的時侯。
`Host.Results`	requests	這些執行階段產生的記錄表示函式的成功或失敗。所有這些記錄都會在 `Information` 層級寫入。若您在 `Warning` 或更高層級進行篩選，就不會看到此資料。

[資料表] 資料行會指出寫入記錄檔的資料表是 Application Insights 中的哪一個資料表。

設定記錄層級

記錄層級會指派給每個記錄檔。值為整數，表示相對重要性：

LogLevel	代碼	描述
追蹤	0	包含最詳細訊息的記錄。這些訊息可能包含敏感性應用程式資料。這些訊息預設會停用，且永遠不應在生產環境中啟用。
偵錯	1	開發期間用於互動式調查的記錄。這些記錄主要應包含適用於偵錯的資訊，且不具備任何長期值。
資訊	2	追蹤應用程式一般流程的記錄。這些記錄應具備長期值。
警告	3	醒目提示應用程式流程中異常或未預期事件的記錄，這些異常或未預期事件不會造成應用程式停止執行。
錯誤	4	在目前流程因失敗而停止執行時醒目提示的記錄。這些錯誤應指出目前活動中的失敗，而非整個應用程式的失敗。
重大	5	描述無法復原的應用程式或系統損毀，或需要立即注意重大失敗的記錄。
無	6	停用指定類別的記錄。

host.json 檔案的設定決定函式應用程式傳送至 Application Insights 的記錄數量。

針對每個類別，您可以指出要傳送的最小記錄層級。 host.json 設定會根據Functions 執行階段版本而有所不同。

以下範例會根據下列規則定義記錄：

預設記錄層級設為 Warning，以防止非預期的類別發生過度記錄。
Host.Aggregator 和 Host.Results 設為較低層級。將記錄層級設得太高 (特別是高於 Information)，可能會導致計量和效能資料遺失。
函式執行的記錄設定為 Information。若有必要，您可以在本機開發中覆寫此設定，以 Debug 或 Trace。

v2.x+
v1.x

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

如果 host.json 包含多個以相同字串開頭的記錄，則會先比對具有已定義內容較多的記錄。請考慮下列範例，該範例在執行階段中記錄了所有的項目，但 Host.Aggregator 除外，該項目記錄於 Error 層級：

v2.x+
v1.x

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

您可以使用 None 的記錄層級設定來防止針對類別寫入任何記錄。

警告

Azure Functions 將遙測事件儲存在 Application Insights 資料表中，以便與 Application Insights 進行整合。如果您將類別記錄層級設定為與 Information 不同的值，其會防止遙測資料流向這些資料表，且您將無法在 [Application Insights] 和 [函數監視器] 索引標籤中看到相關資料。

例如，針對先前的範例：

若您將 Host.Results 類別設定為 Error 記錄層級，Azure 僅會在 requests 資料表中收集失敗函數執行的主機執行遙測事件，以防止在 [Application Insights] 和 [函數監視器] 索引標籤中顯示成功執行的主機執行詳細資料。
若您將 Function 類別設定為 Error 記錄層級，那麼系統將停止收集與 dependencies、customMetrics 和 customEvents 相關的函數遙測資料，以防止您在 Application Insights 中看到此類資料。 Azure 僅會收集處於 Error 層級的 traces。

在這兩種情況下，Azure 都會繼續收集 [Application Insights] 和 [函數監視器] 索引標籤中的錯誤和例外狀況資料。如需詳細資訊，請參閱具有大量遙測的解決方案。

設定彙總工具

如前一節所述，執行階段經過一段時間就會彙總有關函式執行的資料。預設期間為 30 秒或 1,000 個執行，視何者較早達到而定。您可以在 host.json 檔案中設定此設定。例如：

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

設定取樣

Application Insights 具有取樣功能，可以提供保護，以避免在尖峰負載期間完成的執行中產生過多的遙測資料。當傳入執行速率超過指定的閾值時，Application Insights 就會開始隨機忽略某些傳入執行。每秒執行次數上限的預設值為 20 (在 1.x 版中為五)。您可以在 host.json 中設定取樣。以下是範例：

v2.x+
v1.x

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

您可以從取樣中排除特定類型的遙測。在此範例中，Request 和 Exception 類型的資料會從取樣中遭到排除。這會確保「所有」函數執行 (要求) 和例外狀況都會記錄下來，而其他類型的遙測仍會受到取樣。

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

若您的專案相依於 Application Insights SDK 來進行手動遙測追蹤，當您的取樣設定與函數應用程式的取樣設定不同時，就可能會遇到異常行為。在這種情況下，請使用與函數應用程式相同的取樣設定。如需詳細資訊，請參閱在 Application Insights 中取樣。

啟用 SQL 查詢集合。

Application Insights 會自動針對 HTTP 要求、資料庫呼叫和數個繫結的相依性收集資料。如需詳細資訊，請參閱相依性。針對 SQL 呼叫，伺服器和資料庫的名稱一律會收集並儲存，但預設不會收集 SQL 查詢文字。您可以在 host.json 檔案中設定 (至少) 下列項目，以使用 dependencyTrackingOptions.enableSqlCommandTextInstrumentation 來啟用 SQL 查詢文字記錄：

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

如需詳細資訊，請參閱透過進階 SQL 追蹤取得完整的 SQL 查詢。

設定調整控制器記錄

這項功能處於預覽狀態。

您可以讓 Azure Functions 調整控制器發出記錄至 Application Insights 或 Blob 儲存體，以便進一步了解調整控制器針對您函式應用程式所做的決策。

若要啟用此功能，請將名為 SCALE_CONTROLLER_LOGGING_ENABLED 的應用程式設定新增至函數應用程式設定。設定中下列的值必須使用 <DESTINATION>:<VERBOSITY> 格式。如需詳細資訊，請參閱下列表格：

屬性	說明
`<DESTINATION>`	已傳送記錄的目的地。有效值為 `AppInsights` 和 `Blob`。當您使用 `AppInsights` 時，請確定您的函式應用程式中已啟用 Application Insights。當您將目的地設定為 `Blob` 時，記錄會在名為 `azure-functions-scale-controller` 的 Blob 容器中建立，該容器位於 `AzureWebJobsStorage` 應用程式設定中的預設儲存體帳戶中。
`<VERBOSITY>`	指定記錄的層級。支援的值為 `None`、`Warning` 和 `Verbose`。當設定為 `Verbose` 時，調整控制器會記錄背景工作計數中每次變更的原因，並針對考慮這些決策的觸發程序，記錄其相關資訊。詳細資訊記錄包括觸發程序警告，以及觸發程序在調整控制器執行前後所使用的雜湊。

提示

請記住，如果您讓調整控制器記錄保持啟用狀態，您監視函式應用程式的潛在成本就會受到影響。請考慮在您收集到足夠的資料前啟用記錄，並在資料足夠讓您了解調整控制器的行為之後，將其停用。

例如，下列 Azure CLI 命令會開啟從調整控制器到 Application Insights 的詳細資訊記錄：

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

在此範例中，分別將 <FUNCTION_APP_NAME> 和 <RESOURCE_GROUP_NAME> 取代為函式應用程式的名稱和資源群組名稱。

下列 Azure CLI 命令會將詳細資訊設定為 None 來停用記錄：

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

您也可以使用下列 Azure CLI 命令移除 SCALE_CONTROLLER_LOGGING_ENABLED 設定來停用記錄：

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

啟用調整控制器記錄後，您現在可以查詢調整控制器記錄了。

啟用 Application Insights 整合

針對將資料傳送至 Application Insights 的函數應用程式，只能使用這些應用程式設定的其中之一來連線到 Application Insights 資源：

設定名稱	描述
`APPLICATIONINSIGHTS_CONNECTION_STRING`	這是建議設定；若您的 Application Insights 執行個體是在主權雲端中執行時，則會是必要設定。連接字串支援其他新功能。
`APPINSIGHTS_INSTRUMENTATIONKEY`	舊版設定，已由 Application Insights 取代，以利連接字串設定。

當您在 Azure 入口網站中，使用 Azure Functions Core Tools 或 Visual Studio Code，從命令列建立函式應用程式時，預設會啟用 Application Insights 整合。 Application Insights 資源的名稱與您的函數應用程式相同，而且其會建立於相同區域或最近的區域中。

需要 Microsoft Entra 驗證

您可以使用 [APPLICATIONINSIGHTS_AUTHENTICATION_STRING] 設定，使用 Microsoft Entra 驗證來啟用 Application Insights 的連線。這會在所有 Application Insights 管線中建立一致的驗證體驗，包括分析工具和快照偵錯工具，以及來自 Functions 主機和語言特定的代理程式。

注意

本機開發沒有 Entra 驗證支援。

值包含系統指派的受控識別的 Authorization=AAD，或使用者指派的受控識別的 ClientId=<YOUR_CLIENT_ID>;Authorization=AAD。函數應用程式必須已有可用受控識別，且指派的角色相當於監視計量發行者。如需詳細資訊，請參閱 Application Insights 的 Microsoft Entra 驗證。

APPLICATIONINSIGHTS_CONNECTION_STRING 設定仍為必要。

注意

使用 APPLICATIONINSIGHTS_AUTHENTICATION_STRING 連線到使用 Microsoft Entra 驗證的 Application Insights 時，您也應停用 Application Insights 的本機驗證 (部分機器翻譯)。此設定需要 Microsoft Entra 驗證，才能將遙測資料擷取到您的工作區。

入口網站中新的函式應用程式

若要檢閱所建立的 Application Insights 資源，請加以選取以展開 [Application Insights] 視窗。您可以變更新資源名稱，或者在您希望儲存資料的 Azure 地理位置中，選取不同的位置。

螢幕擷取畫面顯示如何在建立函數應用程式時，啟用 Application Insights。

當您選取 [建立] 時，即會使用您的函式應用程式來建立 Application Insights 資源，其已在應用程式設定中設定了 APPLICATIONINSIGHTS_CONNECTION_STRING。一切都已準備就緒。

新增至現有的函式應用程式

如果沒有以函式應用程式建立 Application Insights 資源，請使用下列步驟來建立資源。然後，您可以從該資源新增連接字串，以作為函數應用程式中的應用程式設定。

在 Azure 入口網站中，搜尋並選取函式應用程式，然後選取您的函式應用程式。
選取視窗頂端的 [未設定 Application Insights] 橫幅。如果您看不到此橫幅，則您的應用程式可能已經啟用 Application Insights。

使用下表中指定的設定，展開 [變更您的資源] 並建立 Application Insights 資源：

設定	建議的值	描述
新資源名稱	唯一的應用程式名稱	最簡單的方式是使用與您函式應用程式一樣的名稱，而這必須是您訂用帳戶中唯一的名稱。
地點	西歐	可能的話，請使用與函式應用程式相同的區域，或該區域附近的區域。

螢幕擷取畫面顯示如何建立 Application Insights 資源。

選取套用。

Application Insights 資源會建立在函式應用程式所在的資源群組和訂用帳戶。建立資源之後，請關閉 [Application Insights] 視窗。
在您的函數應用程式中，展開 [設定]，然後選取 [環境變數]。在 [應用程式設定] 索引標籤中，如果您看到名為 APPLICATIONINSIGHTS_CONNECTION_STRING 的應用程式設定，就表示 Azure 中執行的函數應用程式已啟用 Application Insights 整合。若此設定不存在，請將 Application Insights 連接字串做為值來使用，以新增此設定。

注意

較舊的函數應用程式可能會使用 APPINSIGHTS_INSTRUMENTATIONKEY，而不是 APPLICATIONINSIGHTS_CONNECTION_STRING。可能的話，請更新應用程式以使用連接字串，而不是使用檢測金鑰。

停用內建記錄

舊版 Functions 會使用內建的監視功能 (不再建議使用)。當您啟用 Application Insights，請停用使用 Azure 儲存體的內建記錄。內建記錄適合用來測試少量的工作負載，但不適用於負載繁重的實際執行環境。若要監視實際執行環境，建議使用 Application Insights。若將內建記錄用於實際執行環境，記錄內容可能會因為 Azure 儲存體的節流設定而變得不完整。

若要停用內建記錄，請刪除 AzureWebJobsDashboard 應用程式設定。如需在 Azure 入口網站中刪除應用程式設定的詳細資訊，請參閱如何管理函式應用程式的應用程式設定。刪除應用程式設定之前，確定相同函式應用程式中目前沒有任何函式會使用適用於 Azure 儲存體觸發程序或繫結的設定。

具有大量遙測的解決方案

函數應用程式是解決方案中不可或缺的一環，該解決方案可能會導致出現大量的遙測，例如 IoT 解決方案、快速事件驅動解決方案、高負載財務系統和整合系統。在此情況下，您應該考慮額外的設定，以便降低成本，同時維持可檢視性。

您可以在即時儀表板、警示、詳細診斷中取用產生的遙測。取決於您如何取用所產生的遙測，您需要定義一個策略以便減少產生的資料量。此策略可讓您在生產環境中正確地監視、運作和診斷函數應用程式。請考慮下列選項：

使用取樣：如先前所述，取樣有助於大幅減少擷取的遙測事件量，同時維持統計上正確的分析。即使使用取樣，您仍可能會收到大量遙測。檢查調適型取樣提供的選項。例如，將 maxTelemetryItemsPerSecond 設定為適當的值，以便平衡監視需求與產生的遙測量。請記住，每個執行函式應用程式的主機都會套用遙測取樣。
預設記錄層級：使用 Warning 或 Error 做為所有遙測類別的預設值。稍後，您可以決定要在 Information 層級設定什麼類別，以便正確監視和診斷函式。
調整函數遙測：將預設記錄層級設定為 Error 或 Warning 時，不會收集每個函數的詳細資訊 (相依性、自訂計量、自訂事件和追蹤)。對於生產環境監視的關鍵函數，請定義 Function.<YOUR_FUNCTION_NAME> 類別的明確項目，並將其設定為 Information，以便讓您收集詳細資訊。若要避免在 Information 層級收集使用者產生的記錄，請將 Function.<YOUR_FUNCTION_NAME>.User 類別設定為 Error 或 Warning 記錄層級。
Host.Aggregator 類別：如設定類別中所述，此類別會提供函式叫用的彙總資訊。此類別中的資訊會在 Application Insights customMetrics 資料表中收集，並顯示在 [Azure 入口網站] 的函數 [概觀] 索引標籤中。根據您設定彙總工具的方式，請考慮到在收集的遙測中可能會有延遲，該延遲取決於 flushTimeout 設定。如果您將此類別設定為不同於 Information 的其他值，您將停止收集 customMetrics 資料表中的資料，而且不會在函數 [概觀] 索引標籤中顯示計量。

下列螢幕擷取畫面顯示函式 [概觀] 索引標籤中顯示的 Host.Aggregator 遙測資料：

下列螢幕擷取畫面顯示 Application Insights customMetrics 資料表中的 Host.Aggregator 遙測資料：
Host.Results 類別：如設定類別中所述，此類別會提供執行階段產生的記錄，該記錄會指出函式叫用是成功或失敗。此類別的資訊會在 Application Insights requests 資料表中受到收集，並顯示在 [監視] 索引標籤和不同的 Application Insights 儀表板 (效能、失敗等等) 中。如果您將此類別設定為不同於 Information 的其他值，則只會收集在定義的記錄層級 (或更高層級) 產生的遙測。例如，將其設定為 error 會導致只追蹤失敗執行的要求資料。

下列螢幕擷取畫面顯示函式 [監視] 索引標籤中顯示的 Host.Results 遙測資料：

下列螢幕擷取畫面顯示 Application Insights 效能儀表板中顯示的 Host.Results 遙測資料：
Host.Aggregator 與 Host.Results：這兩個類別都會提供有關函式執行的良好見解。如有需要，您可以從其中一個類別中移除詳細資訊，以便使用另一個類別進行監視和警示。以下是一個範例：

v2.x+
v1.x

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

使用此組態：

所有函式和遙測類別的預設值設定為 Warning (包括 Microsoft 和背景工作類別)。因此，根據預設，會收集執行階段和自訂記錄所產生的所有錯誤和警告。
Function 類別記錄層級會將所有函數設定為 Error，因此，根據預設只會收集例外狀況和錯誤記錄。系統會略過相依性、使用者產生的計量和使用者產生的事件。
針對 Host.Aggregator 類別，因為其設定為 Error 記錄層級，所以不會在 customMetrics Application Insights 資料表中收集來自函數叫用的彙總資訊，而且執行計數的相關資訊 (總計、成功和失敗) 將不會顯示在函數概觀儀表板中。
針對 Host.Results 類別，會在 requests Application Insights 資料表中收集所有主機執行資訊。所有叫用結果都會顯示在函數 [監視] 儀表板和 Application Insights 儀表板中。
針對稱為 Function1 的函數，我們已將記錄層級設定為 Information。因此，針對此具體的函式，會收集所有遙測 (相依性、自訂計量和自訂事件)。針對相同的函數，我們會將 Function1.User 類別 (使用者產生的追蹤) 設定為 Error，因此只會收集自訂錯誤記錄。

注意

在 v1.x 的函數執行階段中不支援每個函數的分別設定。
取樣會設定為，每個類型每秒傳送一個遙測項目，但不包括例外狀況。執行函數應用程式的每個伺服器主機都會發生此取樣。因此，如果我們有四個執行個體，此設定會針對每個類型每秒發出四個遙測項目，以及所有可能發生的例外狀況。

注意

度量計量 (例如要求率及例外狀況率) 會受到調整來補償取樣率，讓它們能在計量瀏覽器中顯示大致上正確的值。

提示

實驗不同的設定，以確保您涵蓋記錄、監視和警示的需求。此外，請確定您在發生非預期的錯誤或運作異常時具有詳細的診斷。

在執行階段覆寫監視設定

最後，在某些情況下，您可能會需要在生產環境中快速變更特定類別的記錄行為，而且您不想只為了要進行 host.json 檔案中的變更就進行整個部署。在這種情況下，您可以覆寫 host.json 值。

若要在應用程式設定層級設定這些值 (並避免只為了 host.json 變更就得重新部署)，您應該建立對等值做為應用程式設定，以便覆寫特定的 host.json 值。當執行階段以格式 AzureFunctionsJobHost__path__to__setting 尋找應用程式設定時，其會覆寫位於 JSON 中 path.to.setting 的對等 host.json 設定。以應用程式設定表示時，雙底線 (__) 將會取代用來表示 JSON 階層的點 (.)。例如，您可以使用下列應用程式設定，來設定 host.json 中的個別函數記錄層級。

Host.json 路徑	應用程式設定
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

您可以直接在 [Azure 入口網站函數應用程式設定] 窗格覆寫設定，或使用 Azure CLI 或 PowerShell 指令碼進行覆寫。

Azure CLI
PowerShell

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

注意

透過變更應用程式設定來覆寫 host.json將會重新啟動您的函式應用程式。使用彈性進階方案或專用 (App Service) 方案在 Linux 上執行時，不支援包含期間的應用程式設定。在這些裝載環境中，您應該繼續使用 host.json 檔案。

使用健康情況檢查來監視函數應用程式

您可以使用「健康情況檢查」功能來監視進階 (Elastic Premium) 和專用 (App Service) 方案上的函數應用程式。健康情況檢查並非「使用量」方案的選項。若要了解如何進行設定，請參閱使用健康情況檢查來監視 App Service 執行個體。您的函數應用程式應該有在端點上回應 HTTP 狀態碼 200 的 HTTP 觸發程序函數，而此端點與健康情況檢查的 Path 參數上所設定的端點相同。您也可以讓該函數執行額外的檢查，以確保相依服務可連線且可運作。

如需有關監視的詳細資訊，請參閱：

共用方式為

如何設定 Azure Functions 的監視

自訂應用程式記錄檔

設定類別

設定記錄層級

設定彙總工具

設定取樣

啟用 SQL 查詢集合。

設定調整控制器記錄

啟用 Application Insights 整合

需要 Microsoft Entra 驗證

入口網站中新的函式應用程式

新增至現有的函式應用程式

停用內建記錄

具有大量遙測的解決方案

在執行階段覆寫監視設定

使用健康情況檢查來監視函數應用程式

意見反應

其他資源

共用方式為

如何設定 Azure Functions 的監視

自訂應用程式記錄檔

設定類別

設定記錄層級

設定彙總工具

設定取樣

啟用 SQL 查詢集合。

設定調整控制器記錄

啟用 Application Insights 整合

需要 Microsoft Entra 驗證

入口網站中新的函式應用程式

新增至現有的函式應用程式

停用內建記錄

具有大量遙測的解決方案

在執行階段覆寫監視設定

使用健康情況檢查來監視函數應用程式

相關內容

意見反應

其他資源