Proposed Pull Request Change

📄 Document Links

View on GitHub View on Microsoft Learn

--- title: Configure monitoring for Azure Functions description: Learn how to connect your function app to Application Insights for monitoring and how to configure data collection. ms.service: azure-functions ms.topic: how-to ms.date: 05/19/2025 ms.custom: - devdivchpfy22 - sfi-image-nochange - sfi-ropc-nochange # Customer intent: As a developer, I want to understand how to configure monitoring for my functions correctly, so I can collect the data that I need. --- # How to configure monitoring for Azure Functions Azure Functions integrates with Application Insights to better enable you to monitor your function apps. Application Insights, a feature of Azure Monitor, is an extensible Application Performance Management (APM) service that collects data generated by your function app, including information your app writes to logs. Application Insights integration is typically enabled when your function app is created. If your app doesn't have the instrumentation key set, you must first [enable Application Insights integration](#enable-application-insights-integration). You can use Application Insights without any custom configuration. However, the default configuration can result in high volumes of data. If you're using a Visual Studio Azure subscription, you might hit your data cap for Application Insights. For information about Application Insights costs, see [Application Insights billing](/azure/azure-monitor/logs/cost-logs#application-insights-billing). For more information, see [Solutions with high-volume of telemetry](#solutions-with-high-volume-of-telemetry). In this article, you learn how to configure and customize the data that your functions send to Application Insights. You can set common logging configurations in the *[host.json]* file. By default, these settings also govern custom logs emitted by your code. However, in some cases this behavior can be disabled in favor of options that give you more control over logging. For more information, see [Custom application logs](#custom-application-logs). > [!NOTE] > You can use specially configured application settings to represent specific settings in a *host.json* file for a particular environment. Doing so lets you effectively change *host.json* settings without needing to republish the *host.json* file in your project. For more information, see [Override host.json values](functions-host-json.md#override-hostjson-values). ## Custom application logs By default, custom application logs you write are sent to the Functions host, which then sends them to Application Insights under the [Worker category](#configure-categories). Some language stacks allow you to instead send the logs directly to Application Insights, which gives you full control over how logs you write are emitted. In this case, the logging pipeline changes from `worker -> Functions host -> Application Insights` to `worker -> Application Insights`. The following table summarizes the configuration options available for each stack: | Language stack | Where to configure custom logs | |-|-| | .NET (in-process model) | `host.json` | | .NET (isolated model) | Default (send custom logs to the Functions host): `host.json`<br/>To send logs directly to Application Insights, see: [Configure Application Insights in the HostBuilder](./dotnet-isolated-process-guide.md#application-insights) | | Node.js | `host.json` | | Python | `host.json` | | Java | Default (send custom logs to the Functions host): `host.json`<br/>To send logs directly to Application Insights, see: [Configure the Application Insights Java agent](/azure/azure-monitor/app/monitor-functions#distributed-tracing-for-java-applications) | | PowerShell | `host.json` | When you configure custom application logs to be sent directly, the host no longer emits them, and `host.json` no longer controls their behavior. Similarly, the options exposed by each stack apply only to custom logs, and they don't change the behavior of the other runtime logs described in this article. In this case, to control the behavior of all logs, you might need to make changes in both configurations. ## Configure categories The Azure Functions logger includes a *category* for every log. The category indicates which part of the runtime code or your function code wrote the log. Categories differ between version 1.x and later versions. Category names are assigned differently in Functions compared to other .NET frameworks. For example, when you use `ILogger<T>` in ASP.NET, the category is the name of the generic type. C# functions also use `ILogger<T>`, but instead of setting the generic type name as a category, the runtime assigns categories based on the source. For example: + Entries related to running a function are assigned a category of `Function.<FUNCTION_NAME>`. + Entries created by user code inside the function, such as when calling `logger.LogInformation()`, are assigned a category of `Function.<FUNCTION_NAME>.User`. The following table describes the main categories of logs that the runtime creates: ### [v2.x+](#tab/v2) | Category | Table | Description | | ----- | ----- | ----- | | **`Function`** | **traces**| Includes function started and completed logs for all function runs. For successful runs, these logs are at the `Information` level. Exceptions are logged at the `Error` level. The runtime also creates `Warning` level logs, such as when queue messages are sent to the [poison queue](functions-bindings-storage-queue-trigger.md#poison-messages).| | **`Function.<YOUR_FUNCTION_NAME>`** | **dependencies**| Dependency data is automatically collected for some services. For successful runs, these logs are at the `Information` level. For more information, see [Dependencies](functions-monitoring.md#dependencies). Exceptions are logged at the `Error` level. The runtime also creates `Warning` level logs, such as when queue messages are sent to the [poison queue](functions-bindings-storage-queue-trigger.md#poison-messages). | | **`Function.<YOUR_FUNCTION_NAME>`** | **customMetrics**<br/>**customEvents** | C# and JavaScript SDKs lets you collect custom metrics and log custom events. For more information, see [Custom telemetry data](functions-monitoring.md#custom-telemetry-data).| | **`Function.<YOUR_FUNCTION_NAME>`** | **traces**| Includes function started and completed logs for specific function runs. For successful runs, these logs are at the `Information` level. Exceptions are logged at the `Error` level. The runtime also creates `Warning` level logs, such as when queue messages are sent to the [poison queue](functions-bindings-storage-queue-trigger.md#poison-messages). | | **`Function.<YOUR_FUNCTION_NAME>.User`** | **traces**| User-generated logs, which can be any log level. For more information about writing to logs from your functions, see [Writing to logs](functions-monitoring.md#writing-to-logs). | | **`Host.Aggregator`** | **customMetrics** | These runtime-generated logs provide counts and averages of function invocations over a [configurable](#configure-the-aggregator) period of time. The default period is 30 seconds or 1,000 results, whichever comes first. Examples are the number of runs, success rate, and duration. All of these logs are written at the `Information` level. If you filter at `Warning` or higher, you don't see any of this data. | | **`Host.Results`** | **requests** | These runtime-generated logs indicate success or failure of a function. All of these logs are written at the `Information` level. If you filter at `Warning` or higher, you don't see any of this data. | | **`Microsoft`** | **traces** | Fully qualified log category that reflects a .NET runtime component invoked by the host. | | **`Worker`** | **traces** | Logs generated by the language worker process for non-.NET languages. Language worker logs might also be logged in a `Microsoft.*` category, such as `Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher`. These logs are written at the `Information` level.| > [!NOTE] > For .NET class library functions, these categories assume you're using `ILogger` and not `ILogger<T>`. For more information, see the [Functions ILogger documentation](functions-dotnet-class-library.md#ilogger). ### [v1.x](#tab/v1) | Category | Table | Description | | ----- | ----- | ----- | | **`Function`** | **traces**| User-generated logs, which can be any log level. For more information about writing to logs from your functions, see [Writing to logs](functions-monitoring.md#writing-to-logs). | | **`Host.Aggregator`** | **customMetrics** | These runtime-generated logs provide counts and averages of function invocations over a [configurable](#configure-the-aggregator) period of time. The default period is 30 seconds or 1,000 results, whichever comes first. Examples are the number of runs, success rate, and duration. All of these logs are written at `Information` level. If you filter at `Warning` or higher, you don't see any of this data. | | **`Host.Executor`** | **traces** | Includes **Function started** and **Function completed** logs for specific function runs. For successful runs, these logs are at the `Information` level. Exceptions are logged at the `Error` level. The runtime also creates logs at the `Warning`level, such as when queue messages are sent to the [poison queue](functions-bindings-storage-queue-trigger.md#poison-messages). | | **`Host.Results`** | **requests** | These runtime-generated logs indicate success or failure of a function. All of these logs are written at the `Information` level. If you filter at `Warning` or higher, you don't see any of this data. | --- The **Table** column indicates to which table in Application Insights the log is written. ## Configure log levels [!INCLUDE [functions-log-levels](../../includes/functions-log-levels.md)] For each category, you indicate the minimum log level to send. The *host.json* settings vary depending on the [Functions runtime version](functions-versions.md). The following examples define logging based on the following rules: + The default logging level is set to `Warning` to prevent [excessive logging](#solutions-with-high-volume-of-telemetry) for unanticipated categories. + `Host.Aggregator` and `Host.Results` are set to lower levels. Setting logging levels too high (especially higher than `Information`) can result in loss of metrics and performance data. + Logging for function runs is set to `Information`. If necessary, you can [override](functions-host-json.md#override-hostjson-values) this setting in local development to `Debug` or `Trace`. ### [v2.x+](#tab/v2) ```json { "logging": { "fileLoggingMode": "debugOnly", "logLevel": { "default": "Warning", "Host.Aggregator": "Trace", "Host.Results": "Information", "Function": "Information" } } } ``` ### [v1.x](#tab/v1) ```json { "logger": { "categoryFilter": { "defaultLevel": "Warning", "categoryLevels": { "Host.Results": "Information", "Host.Aggregator": "Trace", "Function": "Information" } } } } ``` --- If *[host.json]* includes multiple logs that start with the same string, the more defined logs ones are matched first. Consider the following example that logs everything in the runtime, except `Host.Aggregator`, at the `Error` level: ### [v2.x+](#tab/v2) ```json { "logging": { "fileLoggingMode": "debugOnly", "logLevel": { "default": "Information", "Host": "Error", "Function": "Error", "Host.Aggregator": "Information" } } } ``` ### [v1.x](#tab/v1) ```json { "logger": { "categoryFilter": { "defaultLevel": "Information", "categoryLevels": { "Host": "Error", "Function": "Error", "Host.Aggregator": "Information" } } } } ``` --- You can use a log level setting of `None` to prevent any logs from being written for a category. > [!CAUTION] > Azure Functions integrates with Application Insights by storing telemetry events in Application Insights tables. If you set a category log level to any value different from `Information`, it prevents the telemetry from flowing to those tables, and you won't be able to see related data in the **Application Insights** and **Function Monitor** tabs. > > For example, for the previous samples: > > + If you set the `Host.Results` category to the `Error` log level, Azure gathers only host execution telemetry events in the `requests` table for failed function executions, preventing the display of host execution details of successful executions in both the **Application Insights** and **Function Monitor** tabs. > + If you set the `Function` category to the `Error` log level, it stops gathering function telemetry data related to `dependencies`, `customMetrics`, and `customEvents` for all the functions, preventing you from viewing any of this data in Application Insights. Azure gathers only `traces` logged at the `Error` level. > > In both cases, Azure continues to collect errors and exceptions data in the **Application Insights** and **Function Monitor** tabs. For more information, see [Solutions with high-volume of telemetry](#solutions-with-high-volume-of-telemetry). ## Configure the aggregator As noted in the previous section, the runtime aggregates data about function executions over a period of time. The default period is 30 seconds or 1,000 runs, whichever comes first. You can configure this setting in the *[host.json]* file. For example: ```json { "aggregator": { "batchSize": 1000, "flushTimeout": "00:00:30" } } ``` ## Configure sampling Application Insights has a [sampling](/azure/azure-monitor/app/sampling) feature that can protect you from producing too much telemetry data on completed executions at times of peak load. When the rate of incoming executions exceeds a specified threshold, Application Insights starts to randomly ignore some of the incoming executions. The default setting for maximum number of executions per second is 20 (five in version 1.x). You can configure sampling in [*host.json*](./functions-host-json.md#applicationinsights). Here's an example: ### [v2.x+](#tab/v2) ```json { "logging": { "applicationInsights": { "samplingSettings": { "isEnabled": true, "maxTelemetryItemsPerSecond" : 20, "excludedTypes": "Request;Exception" } } } } ``` You can exclude certain types of telemetry from sampling. In this example, data of type `Request` and `Exception` is excluded from sampling. It ensures that *all* function executions (requests) and exceptions are logged while other types of telemetry remain subject to sampling. ### [v1.x](#tab/v1) ```json { "applicationInsights": { "sampling": { "isEnabled": true, "maxTelemetryItemsPerSecond" : 5 } } } ``` --- If your project uses a dependency on the Application Insights SDK to do manual telemetry tracking, you might experience unusual behavior if your sampling configuration differs from the sampling configuration in your function app. In such cases, use the same sampling configuration as the function app. For more information, see [Sampling in Application Insights](/azure/azure-monitor/app/sampling). ## Enable SQL query collection Application Insights automatically collects data on dependencies for HTTP requests, database calls, and for several bindings. For more information, see [Dependencies](./functions-monitoring.md#dependencies). For SQL calls, the name of the server and database is always collected and stored, but SQL query text isn't collected by default. You can use `dependencyTrackingOptions.enableSqlCommandTextInstrumentation` to enable SQL query text logging by using the following settings (at a minimum) in your [host.json file](./functions-host-json.md#applicationinsightsdependencytrackingoptions): ```json "logging": { "applicationInsights": { "enableDependencyTracking": true, "dependencyTrackingOptions": { "enableSqlCommandTextInstrumentation": true } } } ``` For more information, see [Advanced SQL tracking to get full SQL query](/azure/azure-monitor/app/asp-net-dependencies#advanced-sql-tracking-to-get-full-sql-query). ## Configure scale controller logs *This feature is in preview.* You can have the [Azure Functions scale controller](./event-driven-scaling.md#runtime-scaling) emit logs to either Application Insights or to Blob storage to better understand the decisions the scale controller is making for your function app. To enable this feature, add an application setting named `SCALE_CONTROLLER_LOGGING_ENABLED` to your function app settings. The following value of the setting must be in the format `<DESTINATION>:<VERBOSITY>`. For more information, see the following table: [!INCLUDE [functions-scale-controller-logging](../../includes/functions-scale-controller-logging.md)] For example, the following Azure CLI command turns on verbose logging from the scale controller to Application Insights: ```azurecli-interactive az functionapp config appsettings set --name <FUNCTION_APP_NAME> \ --resource-group <RESOURCE_GROUP_NAME> \ --settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose ``` In this example, replace `<FUNCTION_APP_NAME>` and `<RESOURCE_GROUP_NAME>` with the name of your function app and the resource group name, respectively. The following Azure CLI command disables logging by setting the verbosity to `None`: ```azurecli-interactive az functionapp config appsettings set --name <FUNCTION_APP_NAME> \ --resource-group <RESOURCE_GROUP_NAME> \ --settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None ``` You can also disable logging by removing the `SCALE_CONTROLLER_LOGGING_ENABLED` setting using the following Azure CLI command: ```azurecli-interactive az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \ --resource-group <RESOURCE_GROUP_NAME> \ --setting-names SCALE_CONTROLLER_LOGGING_ENABLED ``` With scale controller logging enabled, you're now able to [query your scale controller logs](analyze-telemetry-data.md#query-scale-controller-logs). ## Enable Application Insights integration For a function app to send data to Application Insights, it needs to connect to the Application Insights resource using **only one** of these application settings: | Setting name | Description | | ---- | ---- | | **[`APPLICATIONINSIGHTS_CONNECTION_STRING`](functions-app-settings.md#applicationinsights_connection_string)** | This setting is recommended and is required when your Application Insights instance runs in a sovereign cloud. The connection string supports other [new capabilities](/azure/azure-monitor/app/migrate-from-instrumentation-keys-to-connection-strings#new-capabilities). | | **[`APPINSIGHTS_INSTRUMENTATIONKEY`](functions-app-settings.md#appinsights_instrumentationkey)** | Legacy setting, which Application Insights has deprecated in favor of the connection string setting. | When you create your function app in the [Azure portal](./functions-get-started.md) from the command line by using [Azure Functions Core Tools](./how-to-create-function-azure-cli.md?pivots=programming-language-csharp) or [Visual Studio Code](./how-to-create-function-vs-code.md?pivot=programming-language-csharp), Application Insights integration is enabled by default. The Application Insights resource has the same name as your function app, and is created either in the same region or in the nearest region. ### Require Microsoft Entra authentication You can use the [`APPLICATIONINSIGHTS_AUTHENTICATION_STRING`](./functions-app-settings.md#applicationinsights_authentication_string) setting to enable connections to Application Insights using Microsoft Entra authentication. This creates a consistent authentication experience across all Application Insights pipelines, including Profiler and Snapshot Debugger, as well as from the Functions host and language-specific agents. >[!NOTE] >There's currently no Microsoft Entra ID authentication support for local development. > >When Ingesting data in a sovereign cloud, Microsoft Entra ID authentication isn't available when using the Application Insights SDK. OpenTelemetry-based data collection supports Microsoft Entra ID authentication across all cloud environments, including sovereign clouds. The value contains either `Authorization=AAD` for a system-assigned managed identity or `ClientId=<YOUR_CLIENT_ID>;Authorization=AAD` for a user-assigned managed identity. The managed identity must already be available to the function app, with an assigned role equivalent to [Monitoring Metrics Publisher](/azure/role-based-access-control/built-in-roles/monitor#monitoring-metrics-publisher). For more information, see [Microsoft Entra authentication for Application Insights](/azure/azure-monitor/app/azure-ad-authentication). The [`APPLICATIONINSIGHTS_CONNECTION_STRING`](functions-app-settings.md#applicationinsights_connection_string) setting is still required. [!INCLUDE [functions-app-insights-disable-local-note](../../includes/functions-app-insights-disable-local-note.md)] ### New function app in the portal To review the Application Insights resource being created, select it to expand the **Application Insights** window. You can change the **New resource name** or select a different **Location** in an [Azure geography](https://azure.microsoft.com/global-infrastructure/geographies/) where you want to store your data. :::image type="content" source="media/functions-monitoring/enable-ai-new-function-app.png" alt-text="Screenshot that shows how to enable Application Insights while creating a function app."::: When you select **Create**, an Application Insights resource is created with your function app, which has the `APPLICATIONINSIGHTS_CONNECTION_STRING` set in application settings. Everything is ready to go. <a id="manually-connect-an-app-insights-resource"></a> ### Add to an existing function app If an Application Insights resource wasn't created with your function app, use the following steps to create the resource. You can then add the connection string from that resource as an [application setting](functions-how-to-use-azure-function-app-settings.md#settings) in your function app. 1. In the [Azure portal](https://portal.azure.com), search for and select **function app**, and then select your function app. 1. Select the **Application Insights is not configured** banner at the top of the window. If you don't see this banner, then your app might already have Application Insights enabled. :::image type="content" source="media/configure-monitoring/enable-application-insights.png" alt-text="Screenshot that shows how to enable Application Insights from the portal."::: 1. Expand **Change your resource** and create an Application Insights resource by using the settings specified in the following table: | Setting | Suggested value | Description | | ------------ | ------- | -------------------------------------------------- | | **New resource name** | Unique app name | It's easiest to use the same name as your function app, which must be unique in your subscription. | | **Location** | West Europe | If possible, use the same [region](https://azure.microsoft.com/regions/) as your function app, or the one that's close to that region. | :::image type="content" source="media/configure-monitoring/ai-general.png" alt-text="Screenshot that shows how to create an Application Insights resource."::: 1. Select **Apply**. The Application Insights resource is created in the same resource group and subscription as your function app. After the resource is created, close the **Application Insights** window. 1. In your function app, expand **Settings**, and then select **Environment variables**. In the **App settings** tab, if you see an app setting named `APPLICATIONINSIGHTS_CONNECTION_STRING`, Application Insights integration is enabled for your function app running in Azure. If this setting doesn't exist, add it by using your Application Insights connection string as the value. > [!NOTE] > Older function apps might use `APPINSIGHTS_INSTRUMENTATIONKEY` instead of `APPLICATIONINSIGHTS_CONNECTION_STRING`. When possible, update your app to use the connection string instead of the instrumentation key. ## Disable built-in logging Early versions of Functions used built-in monitoring, which is no longer recommended. When you enable Application Insights, disable the built-in logging that uses Azure Storage. The built-in logging is useful for testing with light workloads, but isn't intended for high-load production use. For production monitoring, we recommend Application Insights. If you use built-in logging in production, the logging record might be incomplete because of throttling on Azure Storage. To disable built-in logging, delete the `AzureWebJobsDashboard` app setting. For more information about how to delete app settings in the Azure portal, see the **Application settings** section of [How to manage a function app](functions-how-to-use-azure-function-app-settings.md#settings). Before you delete the app setting, ensure that no existing functions in the same function app use the setting for Azure Storage triggers or bindings. ## Solutions with high volume of telemetry Function apps are an essential part of solutions that can cause high volumes of telemetry, such as IoT solutions, rapid event driven solutions, high load financial systems, and integration systems. In this case, you should consider extra configuration to reduce costs while maintaining observability. The generated telemetry can be consumed in real-time dashboards, alerting, detailed diagnostics, and so on. Depending on how the generated telemetry is consumed, you need to define a strategy to reduce the volume of data generated. This strategy allows you to properly monitor, operate, and diagnose your function apps in production. Consider the following options: + **Use the correct table plan**: [Table plans](/azure/azure-monitor/logs/data-platform-logs#table-plans) help you manage data costs by controlling how often you use the data in a table and the kind of analysis you need to perform. To reduce costs, you can choose the `Basic` plan, which does lack some features available in the `Analytics` plan. + **Use sampling**: As mentioned [previously](#configure-sampling), sampling helps to dramatically reduce the volume of telemetry events ingested while maintaining a statistically correct analysis. It could happen that even using sampling you still get a high volume of telemetry. Inspect the options that [adaptive sampling](/azure/azure-monitor/app/sampling#configuring-adaptive-sampling-for-aspnet-applications) provides to you. For example, set the `maxTelemetryItemsPerSecond` to a value that balances the volume generated with your monitoring needs. Keep in mind that the telemetry sampling is applied per host executing your function app. + **Default log level**: Use `Warning` or `Error` as the default value for all telemetry categories. Later, you can decide which [categories](#configure-categories) you want to set at the `Information` level, so that you can monitor and diagnose your functions properly. + **Tune your functions telemetry**: With the default log level set to `Error` or `Warning`, no detailed information from each function is gathered (dependencies, custom metrics, custom events, and traces). For those functions that are key for production monitoring, define an explicit entry for the `Function.<YOUR_FUNCTION_NAME>` category and set it to `Information`, so that you can gather detailed information. To avoid gathering [user-generated logs](functions-monitoring.md#writing-to-logs) at the `Information` level, set the `Function.<YOUR_FUNCTION_NAME>.User` category to the `Error` or `Warning` log level. + **Host.Aggregator category**: As described in [configure categories](#configure-categories), this category provides aggregated information of function invocations. The information from this category is gathered in the Application Insights `customMetrics` table, and is shown in the function **Overview** tab in the Azure portal. Depending on how you configure the aggregator, consider that there can be a delay, determined by the `flushTimeout` setting, in the telemetry gathered. If you set this category to a value different from `Information`, you stop gathering the data in the `customMetrics` table and don't display metrics in the function **Overview** tab. The following screenshot shows `Host.Aggregator` telemetry data displayed in the function **Overview** tab: :::image type="content" source="media/configure-monitoring/host-aggregator-function-overview.png" alt-text="Screenshot that shows the Host.Aggregator telemetry displayed in the function Overview tab." lightbox="media/configure-monitoring/host-aggregator-function-overview-big.png"::: The following screenshot shows `Host.Aggregator` telemetry data in Application Insights `customMetrics` table: :::image type="content" source="media/configure-monitoring/host-aggregator-custom-metrics.png" alt-text="Screenshot that shows Host.Aggregator telemetry in the customMetrics Application Insights table." lightbox="media/configure-monitoring/host-aggregator-custom-metrics-big.png"::: + **Host.Results category**: As described in [configure categories](#configure-categories), this category provides the runtime-generated logs indicating the success or failure of a function invocation. The information from this category is gathered in the Application Insights `requests` table, and is shown in the function **Monitor** tab and in different Application Insights dashboards (Performance, Failures, and so on). If you set this category to a value different than `Information`, you gather only telemetry generated at the log level defined (or higher). For example, setting it to `error` results in tracking requests data only for failed executions. The following screenshot shows the `Host.Results` telemetry data displayed in the function **Monitor** tab: :::image type="content" source="media/configure-monitoring/host-results-function-monitor.png" alt-text="Screenshot that shows Host.Results telemetry in the function Monitor tab." lightbox="media/configure-monitoring/host-results-function-monitor-big.png"::: The following screenshot shows `Host.Results` telemetry data displayed in Application Insights Performance dashboard: :::image type="content" source="media/configure-monitoring/host-results-application-insights.png" alt-text="Screenshot that shows the Host.Results telemetry in the Application Insights Performance dashboard." lightbox="media/configure-monitoring/host-results-application-insights-big.png"::: + **Host.Aggregator vs Host.Results**: Both categories provide good insights about function executions. If needed, you can remove the detailed information from one of these categories, so that you can use the other for monitoring and alerting. Here's a sample: # [v2.x+](#tab/v2) ``` json { "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" } } } } ``` # [v1.x](#tab/v1) ```json { "logger": { "categoryFilter": { "defaultLevel": "Warning", "categoryLevels": { "Function": "Error", "Host.Aggregator": "Error", "Host.Results": "Information", "Host.Executor": "Warning" } } }, "applicationInsights": { "sampling": { "isEnabled": true, "maxTelemetryItemsPerSecond" : 5 } } } ``` --- With this configuration: + The default value for all functions and telemetry categories is set to `Warning` (including Microsoft and Worker categories). So, by default, all errors and warnings generated by runtime and custom logging are gathered. + The `Function` category log level is set to `Error`, so for all functions, by default, only exceptions and error logs are gathered. Dependencies, user-generated metrics, and user-generated events are skipped. + For the `Host.Aggregator` category, as it's set to the `Error` log level, aggregated information from function invocations isn't gathered in the `customMetrics` Application Insights table, and information about executions counts (total, successful, and failed) aren't shown in the function overview dashboard. + For the `Host.Results` category, all the host execution information is gathered in the `requests` Application Insights table. All the invocations results are shown in the function Monitor dashboard and in Application Insights dashboards. + For the function called `Function1`, we set the log level to `Information`. So, for this concrete function, all the telemetry is gathered (dependency, custom metrics, and custom events). For the same function, we set the `Function1.User` category (user-generated traces) to `Error`, so only custom error logging is gathered. > [!NOTE] > Configuration per function isn't supported in v1.x of the Functions runtime. + Sampling is configured to send one telemetry item per second per type, excluding the exceptions. This sampling happens for each server host running our function app. So, if we have four instances, this configuration emits four telemetry items per second per type and all the exceptions that might occur. > [!NOTE] > Metric counts such as request rate and exception rate are adjusted to compensate for the sampling rate, so that they show approximately correct values in Metric Explorer. > [!TIP] > Experiment with different configurations to ensure that you cover your requirements for logging, monitoring, and alerting. Also, ensure that you have detailed diagnostics in case of unexpected errors or malfunctioning. ## Overriding monitoring configuration at runtime Finally, there could be situations where you need to quickly change the logging behavior of a certain category in production, and you don't want to make a whole deployment just for a change in the *host.json* file. For such cases, you can override the [host.json values](functions-host-json.md#override-hostjson-values). To configure these values at App settings level (and avoid redeployment on just *host.json* changes), you should override specific `host.json` values by creating an equivalent value as an application setting. When the runtime finds an application setting in the format `AzureFunctionsJobHost__path__to__setting`, it overrides the equivalent `host.json` setting located at `path.to.setting` in the JSON. When expressed as an application setting, a double underscore (`__`) replaces the dot (`.`) used to indicate JSON hierarchy. For example, you can use the following app settings to configure individual function log levels in `host.json`. | Host.json path | App setting | |----------------|-------------| | 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 | You can override the settings directly at the Azure portal Function App Configuration pane or by using an Azure CLI or PowerShell script. # [Azure CLI](#tab/v2) ```azurecli-interactive az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host.Aggregator=Information" ``` # [PowerShell](#tab/v1) ```powershell Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host.Aggregator" = "Information"} ``` --- > [!NOTE] > Overriding the `host.json` through changing app settings will restart your function app. > App settings that contain a period aren't supported when running on Linux in an Elastic Premium plan or a Dedicated (App Service) plan. In these hosting environments, you should continue to use the *host.json* file. ## Monitor function apps using Health check You can use the Health Check feature to monitor function apps on the Premium (Elastic Premium) and Dedicated (App Service) plans. Health check isn't an option for the Flex Consumption and Consumption plans. To learn how to configure it, see [Monitor App Service instances using Health check](../app-service/monitor-instances-health-check.md). Your function app should have an HTTP trigger function that responds with an HTTP status code of 200 on the same endpoint as configured on the `Path` parameter of the health check. You can also have that function perform extra checks to ensure that dependent services are reachable and working. ## Related content For more information about monitoring, see: + [Monitor Azure Functions](functions-monitoring.md) + [Analyze Azure Functions telemetry data in Application Insights](analyze-telemetry-data.md) + [Application Insights overview](/azure/azure-monitor/app/app-insights-overview) [host.json]: functions-host-json.md