你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

如何为 Azure Functions 配置监视

项目
01/19/2024

Azure Functions 与 Application Insights 集成，从而使你能够更好地监视函数应用。 Application Insights（Azure Monitor 的一项功能）是一种可扩展的应用程序性能管理 (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（独立模型）	默认情况下：`host.json` 直接发送日志的选项：在 HostBuilder 中配置 Application Insights
Node.JS	`host.json`
Python	`host.json`
Java	默认情况下：`host.json` 直接发送日志的选项：配置 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

类别	表	说明
`Function`	traces	包括所有函数运行的函数已启动和已完成的日志。对于成功运行，这些日志处于 `Information` 级别。异常记录在 `Error` 级别。运行时还会创建 `Warning` 级别日志，例如将队列消息发送到病毒队列时。
`Function.<YOUR_FUNCTION_NAME>`	dependencies	系统会自动收集一些服务的依赖项数据。对于成功运行，这些日志处于 `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 文档。

类别	表	说明
`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 包含以相同字符串开头的多个日志，则首先匹配定义更多的日志。考虑以下示例，该示例在运行时中记录 Error 级别上除 Host.Aggregator 之外的所有内容：

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 日志级别，则它只会收集 requests 表中与失败的函数执行对应的主机执行遥测事件，导致“Application Insights”和“函数监视器”选项卡中不会显示成功执行的主机执行详细信息。
如果 Function 类别设置为 Error 日志级别，则会停止收集与所有函数的 dependencies、customMetrics 和 customEvents 相关的函数遥测数据，导致你无法在 Application Insights 中查看任何此类数据。它只会收集已记录的 Error 级别的 traces。

在这两种情况下，你将继续在“Application Insights”和“函数监视器”选项卡中收集错误和异常数据。有关详细信息，请参阅具有大量遥测数据的解决方案。

配置聚合器

如前一部分中所述，运行时聚合一段时间内有关函数执行的数据。默认时段为 30 秒或 1,000 次运行，以先满足的条件为准。可以在 host.json 文件中配置此设置。下面是一个示例：

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

配置采样

Application Insights 具有采样功能，可以防止在峰值负载时为已完成的执行生成过多的遥测数据。当传入执行的速率超过指定的阈值时，Application Insights 开始随机忽略某些传入执行。每秒执行的最大次数的默认设置为 20（版本 1.x 中为 5）。可以在 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 查询文本。可以使用 dependencyTrackingOptions.enableSqlCommandTextInstrumentation 通过在 host.json 文件中至少设置以下项来启用 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 资源的名称与函数应用的相同，并且在同一区域或最接近的区域中创建。

门户中的新函数应用

若要查看正在创建的 Application Insights 资源，请选择该资源，展开“Application Insights”窗口。可以更改“新建资源名称”，或者在 Azure 地理位置中选择另一个需要在其中存储数据的“位置”。

Screenshot of enabling Application Insights while creating a function app.

选择“创建”时，Application Insights 资源通过函数应用创建，该函数应用在应用程序设置中设置了 APPLICATIONINSIGHTS_CONNECTION_STRING。一切准备就绪。

添加到现有函数应用

如果未使用函数应用创建 Application Insights 资源，请使用以下步骤创建资源。然后，可以将该资源中的连接字符串添加为函数应用中的应用程序设置。

在 Azure 门户中，搜索并选择“函数应用”，然后选择你的函数应用。
选择窗口顶部的“未配置 Application Insights”横幅。如果看不到此横幅，则应用可能已启用 Application Insights。

展开“更改资源”，使用下表中指定的设置创建 Application Insights 资源：

设置	建议值	描述
新资源名称	唯一的应用名称	使用与函数应用相同的名称是最方便的，该名称在订阅中必须独一无二。
位置	西欧	尽可能使用函数应用所在的同一区域，或与该区域接近的区域。

Screenshot of creating an Application Insights resource.

选择“应用”。

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 和 Worker 类别）。因此，默认情况下，将会收集运行时和自定义日志记录生成的所有错误和警告。
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 脚本来替代设置。

az 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 会重启函数应用。在 Linux 上的弹性高级计划或专用（应用服务）计划中运行时，不支持包含时段的应用设置。在这些托管环境中，应继续使用 host.json 文件。

使用运行状况检查监视函数应用

运行状况检查功能可用于监视高级（弹性高级）和专用（应用服务）计划中的函数应用。运行状况检查不是消耗计划的选项。若要了解如何对其进行配置，请参阅使用运行状况检查监视应用服务实例。函数应用应具有 HTTP 触发器函数，该函数在运行状况检查的“Path”参数上配置的同一终结点上以 200 的 HTTP 状态代码进行响应。还可以让该函数执行额外的检查，从而确保依赖的服务可访问且正常工作。

后续步骤

有关监视的详细信息，请参阅：