You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. Select **Refresh** periodically, until the list of function invocations appears.
56
-
57
-
It can take up to five minutes for the list to appear while the telemetry client batches data for transmission to the server. (The delay doesn't apply to the [Live Metrics Stream](../azure-monitor/app/live-stream.md). That service connects to the Functions host when you load the page, so logs are streamed directly to the page.)
51
+
1. In the function app page, select a function that has run at least once after Application Insights was configured. Then select the **Monitor** tab. Select **Refresh** periodically, until the list of function invocations appears.
> It can take up to five minutes for the list to appear while the telemetry client batches data for transmission to the server. The delay doesn't apply to the [Live Metrics Stream](../azure-monitor/app/live-stream.md). That service connects to the Functions host when you load the page, so logs are streamed directly to the page.
64
57
65
-
The logging output for that invocation appears in a new page.
58
+
1. To see the logs for a particular function invocation, select the **Date (UTC)** column link for that invocation. The logging output for that invocation appears in a new page.
You can see that both pages have a **Run in Application Insights** link to the Application Insights Analytics query that retrieves the data.
62
+
1. Choose the **Run in Application Insights** link to view the source of the query that retrieves the Azure Monitor log data in Azure Log If this is the first time using Azure Log Analytics in your subscription, you are asked to enable to.
70
63
71
-
64
+
1. When you choose that link and choose to enable Log Analytic. the following query is displayed. You can see that the query results are limited to the last 30 days (`where timestamp > ago(30d)`). In addition, the results show no more than 20 rows (`take 20`). In contrast, the invocation details list for your function is for the last 30 days with no limit.
72
65
73
-
The following query is displayed. You can see that the query results are limited to the last 30 days (`where timestamp > ago(30d)`). In addition, the results show no more than 20 rows (`take 20`). In contrast, the invocation details list for your function is for the last 30 days with no limit.
For more information, see [Query telemetry data](#query-telemetry-data) later in this article.
78
69
@@ -88,30 +79,29 @@ For information about how to use Application Insights, see the [Application Insi
88
79
89
80
The following areas of Application Insights can be helpful when evaluating the behavior, performance, and errors in your functions:
90
81
91
-
|Tab| Description |
82
+
|Investigate| Description |
92
83
| ---- | ----------- |
93
84
|**[Failures](../azure-monitor/app/asp-net-exceptions.md)**| Create charts and alerts based on function failures and server exceptions. The **Operation Name** is the function name. Failures in dependencies aren't shown unless you implement custom telemetry for dependencies. |
|**Servers**| View resource utilization and throughput per server. This data can be useful for debugging scenarios where functions are bogging down your underlying resources. Servers are referred to as **Cloud role instances**. |
85
+
|**[Performance](../azure-monitor/app/performance-counters.md)**| Analyze performance issues by viewing resource utilization and throughput per **Cloud role instances**. This data can be useful for debugging scenarios where functions are bogging down your underlying resources. |
96
86
|**[Metrics](../azure-monitor/app/metrics-explorer.md)**| Create charts and alerts that are based on metrics. Metrics include the number of function invocations, execution time, and success rates. |
97
-
|**[Live Metrics Stream](../azure-monitor/app/live-stream.md)**| View metrics data as it's created in near real-time. |
87
+
|**[Live Metrics ](../azure-monitor/app/live-stream.md)**| View metrics data as it's created in near real-time. |
98
88
99
89
## Query telemetry data
100
90
101
-
[Application Insights Analytics](../azure-monitor/app/analytics.md) gives you access to all telemetry data in the form of tables in a database. Analytics provides a query language for extracting, manipulating, and visualizing the data.
91
+
[Application Insights Analytics](../azure-monitor/app/analytics.md) gives you access to all telemetry data in the form of tables in a database. Analytics provides a query language for extracting, manipulating, and visualizing the data.
Here's a query example that shows the distribution of requests per worker over the last 30 minutes.
108
98
109
-
```
99
+
<pre>
110
100
requests
111
101
| where timestamp > ago(30m)
112
102
| summarize count() by cloud_RoleInstance, bin(timestamp, 1m)
113
103
| render timechart
114
-
```
104
+
</pre>
115
105
116
106
The tables that are available are shown in the **Schema** tab on the left. You can find data generated by function invocations in the following tables:
117
107
@@ -128,10 +118,10 @@ The other tables are for availability tests, and client and browser telemetry. Y
128
118
129
119
Within each table, some of the Functions-specific data is in a `customDimensions` field. For example, the following query retrieves all traces that have log level `Error`.
130
120
131
-
```
121
+
<pre>
132
122
traces
133
123
| where customDimensions.LogLevel == "Error"
134
-
```
124
+
</pre>
135
125
136
126
The runtime provides the `customDimensions.LogLevel` and `customDimensions.Category` fields. You can provide additional fields in logs that you write in your function code. See [Structured logging](#structured-logging) later in this article.
137
127
@@ -141,11 +131,20 @@ You can use Application Insights without any custom configuration. The default c
141
131
142
132
### Categories
143
133
144
-
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.
134
+
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. The following chart describes the main categories of logs that the runtime creates.
135
+
136
+
| Category | Description |
137
+
| ----- | ----- |
138
+
| Host.Results | These logs show as **requests** in Application Insights. They 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. |
139
+
| Host.Aggregator | These 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. The logs are available in the **customMetrics** table in Application Insights. 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. |
140
+
141
+
All logs for categories other than these are available in the **traces** table in Application Insights.
142
+
143
+
All logs with categories that begin with `Host` are written by the Functions runtime. The **Function started** and **Function completed** logs have category `Host.Executor`. For successful runs, these logs are `Information` level. Exceptions are logged at `Error` level. The runtime also creates `Warning` level logs, for example: queue messages sent to the poison queue.
145
144
146
145
The Functions runtime creates logs with a category that begin with "Host." In version 1.x, the `function started`, `function executed`, and `function completed` logs have the category `Host.Executor`. Starting in version 2.x, these logs have the category `Function.<YOUR_FUNCTION_NAME>`.
147
146
148
-
If you write logs in your function code, the category is `Function` in version 1.x of the Functions runtime. In version 2.x, the category is `Function.<YOUR_FUNCTION_NAME>.User`.
147
+
If you write logs in your function code, the category is is `Function.<YOUR_FUNCTION_NAME>.User` and can be any log level. In version 1.x of the Functions runtime, the category is `Function`.
149
148
150
149
### Log levels
151
150
@@ -247,36 +246,6 @@ If [host.json] includes multiple categories that start with the same string, the
247
246
248
247
To suppress all logs for a category, you can use log level `None`. No logs are written with that category and there's no log level above it.
249
248
250
-
The following sections describe the main categories of logs that the runtime creates.
251
-
252
-
### Category Host.Results
253
-
254
-
These logs show as "requests" in Application Insights. They 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.
259
-
260
-
### Category Host.Aggregator
261
-
262
-
These 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.
263
-
264
-
The logs are available in the **customMetrics** table in Application Insights. Examples are the number of runs, success rate, and duration.
All logs with categories that begin with `Host` are written by the Functions runtime. The "Function started" and "Function completed" logs have category `Host.Executor`. For successful runs, these logs are `Information` level. Exceptions are logged at `Error` level. The runtime also creates `Warning` level logs, for example: queue messages sent to the poison queue.
277
-
278
-
Logs written by your function code have category `Function` and can be any log level.
279
-
280
249
## Configure the aggregator
281
250
282
251
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:
0 commit comments