如何設定 Azure Functions 的監視

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 檔案中設定常用的記錄設定。 根據預設，這些設定也會控管程式碼發出的自訂記錄。 不過，在某些情況下您可以停用此行為，以改為使用可讓您更充分掌控記錄的選項。 如需詳細資訊，請參閱自訂應用程式記錄。

自訂應用程式記錄檔

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

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

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

設定類別

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

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

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

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

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

設定記錄層級

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

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

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

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

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

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

{
  "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 的記錄層級設定來防止針對類別寫入任何記錄。

設定彙總工具

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

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

設定取樣

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

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "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> 格式。 如需詳細資訊，請參閱下列表格：

例如，下列 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 資源：

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

需要 Microsoft Entra 驗證

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

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

APPLICATIONINSIGHTS_CONNECTION_STRING 設定仍為必要。

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

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

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

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

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

1. 在 Azure 入口網站中，搜尋並選取函式應用程式，然後選取您的函式應用程式。

2. 選取視窗頂端的 [未設定 Application Insights] 橫幅。 如果您看不到此橫幅，則您的應用程式可能已經啟用 Application Insights。

   

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

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

   

4. 選取套用。

   Application Insights 資源會建立在函式應用程式所在的資源群組和訂用帳戶。 建立資源之後，請關閉 [Application Insights] 視窗。

5. 在您的函數應用程式中，展開 [設定]，然後選取 [環境變數]。 在 [應用程式設定] 索引標籤中，如果您看到名為 APPLICATIONINSIGHTS_CONNECTION_STRING 的應用程式設定，就表示 Azure 中執行的函數應用程式已啟用 Application Insights 整合。 若此設定不存在，請將 Application Insights 連接字串做為值來使用，以新增此設定。

停用內建記錄

舊版 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：這兩個類別都會提供有關函式執行的良好見解。 如有需要，您可以從其中一個類別中移除詳細資訊，以便使用另一個類別進行監視和警示。 以下是一個範例：

{
  "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 中的個別函數記錄層級。

您可以直接在 [Azure 入口網站函數應用程式設定] 窗格覆寫設定，或使用 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"}

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

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

相關內容

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

• 監視 Azure Functions
• 分析 Application Insights 中的 Azure Functions 遙測資料
• Application Insights 概觀