| title | description | ms.date | ms.topic | ms.custom |
|---|---|---|---|---|
Configure monitoring for Azure Functions |
Learn how to connect your function app to Application Insights for monitoring and how to configure data collection. |
8/31/2020 |
how-to |
contperf-fy21q2 |
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.
You can use Application Insights without any custom configuration. 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. To learn more about Application Insights costs, see Manage usage and costs for Application Insights.
Later in this article, you learn how to configure and customize the data that your functions send to Application Insights. For a function app, logging is configured in the host.json file.
Note
You can use specially configured application settings to represent specific settings in a host.json file for a specific environment. This lets you effectively change host.json settings without having to republish the host.json file in your project. To learn more, see Override host.json values.
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. The following chart describes the main categories of logs that the runtime creates.
| Category | Table | Description |
|---|---|---|
Function.<YOUR_FUNCTION_NAME> |
dependencies | Dependency data is automatically collected for some services. For successful runs, these logs are at the Information level. To learn more, see 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. |
Function.<YOUR_FUNCTION_NAME> |
customMetrics customEvents |
C# and JavaScript SDKs let you collect custom metrics and log custom events. To learn more, see 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. |
Function.<YOUR_FUNCTION_NAME>.User |
traces | User-generated logs, which can be any log level. To learn more about writing to logs from your functions, see Writing to logs. |
Host.Aggregator |
customMetrics | These runtime-generated logs provide counts and averages of function invocations over a configurable 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 above, you won'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 Information level. If you filter at Warning or above, you won'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 may also be logged in a Microsoft.* category, such as Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. These logs are written at Information level. |
Note
For .NET class library functions, these categories assume you are using ILogger and not ILogger<T>. To learn more, see the Functions ILogger documentation.
| Category | Table | Description |
|---|---|---|
Function |
traces | User-generated logs, which can be any log level. To learn more about writing to logs from your functions, see Writing to logs. |
Host.Aggregator |
customMetrics | These runtime-generated logs provide counts and averages of function invocations over a configurable 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 above, you won'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 Information level. Exceptions are logged at Error level. The runtime also creates Warning level logs, such as when queue messages are sent to the poison queue. |
Host.Results |
requests | These runtime-generated logs indicate success or failure of a function. All of these logs are written at Information level. If you filter at Warning or above, you won't see any of this data. |
The Table column indicates to which table in Application Insights the log is written.
[!INCLUDE functions-log-levels]
For each category, you indicate the minimum log level to send. The host.json settings vary depending on the Functions runtime version.
The example below defines logging based on the following rules:
- For logs of
Host.ResultsorFunction, only log events atErroror a higher level. - For logs of
Host.Aggregator, log all generated metrics (Trace). - For all other logs, including user logs, log only
Informationlevel and higher events.
{
"logging": {
"fileLoggingMode": "always",
"logLevel": {
"default": "Information",
"Host.Results": "Error",
"Function": "Error",
"Host.Aggregator": "Trace"
}
}
}{
"logger": {
"categoryFilter": {
"defaultLevel": "Information",
"categoryLevels": {
"Host.Results": "Error",
"Function": "Error",
"Host.Aggregator": "Trace"
}
}
}
}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:
{
"logging": {
"fileLoggingMode": "always",
"logLevel": {
"default": "Information",
"Host": "Error",
"Function": "Error",
"Host.Aggregator": "Information"
}
}
}{
"logger": {
"categoryFilter": {
"defaultLevel": "Information",
"categoryLevels": {
"Host": "Error",
"Function": "Error",
"Host.Aggregator": "Information"
}
}
}
}You can use a log level setting of None prevent any logs from being written for a category.
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. Here's an example:
{
"aggregator": {
"batchSize": 1000,
"flushTimeout": "00:00:30"
}
}Application Insights has a 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. Here's an example:
{
"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. This makes sure that all function executions (requests) and exceptions are logged while other types of telemetry remain subject to sampling.
{
"applicationInsights": {
"sampling": {
"isEnabled": true,
"maxTelemetryItemsPerSecond" : 5
}
}
}To learn more, see Sampling in Application Insights.
This feature is in preview.
You can have the Azure Functions scale controller 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, you add an application setting named SCALE_CONTROLLER_LOGGING_ENABLED to your function app settings. The value of this setting must be of the format <DESTINATION>:<VERBOSITY>, based on the following:
[!INCLUDE functions-scale-controller-logging]
For example, the following Azure CLI command turns on verbose logging from the scale controller to Application Insights:
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:
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:
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 are now able to query your scale controller logs.
For a function app to send data to Application Insights, it needs to know the instrumentation key of an Application Insights resource. The key must be in an app setting named APPINSIGHTS_INSTRUMENTATIONKEY.
When you create your function app in the Azure portal, from the command line by using Azure Functions Core Tools, or by using Visual Studio Code, Application Insights integration is enabled by default. The Application Insights resource has the same name as your function app, and it's created either in the same region or in the nearest region.
To review the Application Insights resource being created, select it to expand the Application Insights window. You can change the New resource name or choose a different Location in an Azure geography where you want to store your data.
When you choose Create, an Application Insights resource is created with your function app, which has the APPINSIGHTS_INSTRUMENTATIONKEY set in application settings. Everything is ready to go.
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 instrumentation key from that resource as an application setting in your function app.
-
In the Azure portal, search for and select function app, and then choose your function app.
-
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="Enable Application Insights from the portal":::
-
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 as your function app, or one that's close to that region. :::image type="content" source="media/configure-monitoring/ai-general.png" alt-text="Create an Application Insights resource":::
-
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.
-
In your function app, select Configuration under Settings, and then select Application settings. If you see a setting named
APPINSIGHTS_INSTRUMENTATIONKEY, Application Insights integration is enabled for your function app running in Azure. If for some reason this setting doesn't exist, add it using your Application Insights instrumentation key as the value.
Note
Early versions of Functions used built-in monitoring, which is no longer recommended. When enabling Application Insights integration for such a function app, you must also disable built-in logging.
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 built-in logging is used 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 information about how to delete app settings in the Azure portal, see the Application settings section of How to manage a function app. Before you delete the app setting, make sure no existing functions in the same function app use the setting for Azure Storage triggers or bindings.
To learn more about monitoring, see: