Skip to content

Commit 490d43f

Browse files
authored
Merge pull request #225687 from paulth1/app-articles-batch-18
[AQ] edit pass: App articles batch 18
2 parents ae030f7 + 2fb065b commit 490d43f

9 files changed

+273
-277
lines changed

articles/azure-monitor/app/availability-standard-tests.md

Lines changed: 45 additions & 46 deletions
Large diffs are not rendered by default.

articles/azure-monitor/app/azure-ad-authentication.md

Lines changed: 103 additions & 107 deletions
Large diffs are not rendered by default.
Lines changed: 29 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -1,64 +1,68 @@
11
---
2-
title: Data model for request telemetry - Azure Application Insights
3-
description: Application Insights data model for request telemetry
2+
title: Data model for request telemetry - Application Insights
3+
description: This article describes the Application Insights data model for request telemetry.
44
ms.topic: conceptual
55
ms.date: 01/07/2019
66
ms.reviewer: mmcc
77
---
88

99
# Request telemetry: Application Insights data model
1010

11-
A request telemetry item (in [Application Insights](./app-insights-overview.md)) represents the logical sequence of execution triggered by an external request to your application. Every request execution is identified by unique `ID` and `url` containing all the execution parameters. You can group requests by logical `name` and define the `source` of this request. Code execution can result in `success` or `fail` and has a certain `duration`. Both success and failure executions may be grouped further by `resultCode`. Start time for the request telemetry defined on the envelope level.
11+
A request telemetry item in [Application Insights](./app-insights-overview.md) represents the logical sequence of execution triggered by an external request to your application. Every request execution is identified by a unique `id` and `url` that contain all the execution parameters.
1212

13-
Request telemetry supports the standard extensibility model using custom `properties` and `measurements`.
13+
You can group requests by logical `name` and define the `source` of this request. Code execution can result in `success` or `fail` and has a certain `duration`. Both success and failure executions can be grouped further by `resultCode`. Start time for the request telemetry is defined on the envelope level.
14+
15+
Request telemetry supports the standard extensibility model by using custom `properties` and `measurements`.
1416

1517
[!INCLUDE [azure-monitor-log-analytics-rebrand](../../../includes/azure-monitor-instrumentation-key-deprecation.md)]
1618

1719
## Name
1820

19-
Name of the request represents code path taken to process the request. Low cardinality value to allow better grouping of requests. For HTTP requests it represents the HTTP method and URL path template like `GET /values/{id}` without the actual `id` value.
21+
The name of the request represents the code path taken to process the request. A low cardinality value allows for better grouping of requests. For HTTP requests, it represents the HTTP method and URL path template like `GET /values/{id}` without the actual `id` value.
2022

21-
Application Insights web SDK sends request name "as is" with regards to letter case. Grouping on UI is case-sensitive so `GET /Home/Index` is counted separately from `GET /home/INDEX` even though often they result in the same controller and action execution. The reason for that is that urls in general are [case-sensitive](https://www.w3.org/TR/WD-html40-970708/htmlweb.html). You may want to see if all `404` happened for the urls typed in uppercase. You can read more on request name collection by ASP.NET Web SDK in the [blog post](https://apmtips.com/posts/2015-02-23-request-name-and-url/).
23+
The Application Insights web SDK sends a request name "as is" about letter case. Grouping on the UI is case sensitive, so `GET /Home/Index` is counted separately from `GET /home/INDEX` even though often they result in the same controller and action execution. The reason for that is that URLs in general are [case sensitive](https://www.w3.org/TR/WD-html40-970708/htmlweb.html). You might want to see if all `404` errors happened for URLs typed in uppercase. You can read more about request name collection by the ASP.NET web SDK in the [blog post](https://apmtips.com/posts/2015-02-23-request-name-and-url/).
2224

23-
Max length: 1024 characters
25+
**Maximum length**: 1,024 characters
2426

2527
## ID
2628

27-
Identifier of a request call instance. Used for correlation between request and other telemetry items. ID should be globally unique. For more information, see [correlation](./correlation.md) page.
29+
ID is the identifier of a request call instance. It's used for correlation between the request and other telemetry items. The ID should be globally unique. For more information, see [Telemetry correlation in Application Insights](./correlation.md).
2830

29-
Max length: 128 characters
31+
**Maximum length**: 128 characters
3032

31-
## Url
33+
## URL
3234

33-
Request URL with all query string parameters.
35+
URL is the request URL with all query string parameters.
3436

35-
Max length: 2048 characters
37+
**Maximum length**: 2,048 characters
3638

3739
## Source
3840

39-
Source of the request. Examples are the instrumentation key of the caller or the ip address of the caller. For more information, see [correlation](./correlation.md) page.
41+
Source is the source of the request. Examples are the instrumentation key of the caller or the IP address of the caller. For more information, see [Telemetry correlation in Application Insights](./correlation.md).
4042

41-
Max length: 1024 characters
43+
**Maximum length**: 1,024 characters
4244

4345
## Duration
4446

45-
Request duration in format: `DD.HH:MM:SS.MMMMMM`. Must be positive and less than `1000` days. This field is required as request telemetry represents the operation with the beginning and the end.
47+
The request duration is formatted as `DD.HH:MM:SS.MMMMMM`. It must be positive and less than `1000` days. This field is required because request telemetry represents the operation with the beginning and the end.
4648

4749
## Response code
4850

49-
Result of a request execution. HTTP status code for HTTP requests. It may be `HRESULT` value or exception type for other request types.
51+
The response code is the result of a request execution. It's the HTTP status code for HTTP requests. It might be an `HRESULT` value or an exception type for other request types.
5052

51-
Max length: 1024 characters
53+
**Maximum length**: 1,024 characters
5254

5355
## Success
5456

55-
Indication of successful or unsuccessful call. This field is required. When not set explicitly to `false` - a request is considered to be successful. Set this value to `false` if operation was interrupted by exception or returned error result code.
57+
Success indicates whether a call was successful or unsuccessful. This field is required. When a request isn't set explicitly to `false`, it's considered to be successful. Set this value to `false` if the operation was interrupted by an exception or a returned error result code.
58+
59+
For web applications, Application Insights defines a request as successful when the response code is less than `400` or equal to `401`. However, there are cases when this default mapping doesn't match the semantics of the application.
5660

57-
For the web applications, Application Insights define a request as successful when the response code is less than `400` or equal to `401`. However there are cases when this default mapping does not match the semantic of the application. Response code `404` may indicate "no records", which can be part of regular flow. It also may indicate a broken link. For the broken links, you can even implement more advanced logic. You can mark broken links as failures only when those links are located on the same site by analyzing url referrer. Or mark them as failures when accessed from the company's mobile application. Similarly `301` and `302` indicates failure when accessed from the client that doesn't support redirect.
61+
Response code `404` might indicate "no records," which can be part of regular flow. It also might indicate a broken link. For broken links, you can implement more advanced logic. You can mark broken links as failures only when those links are located on the same site by analyzing the URL referrer. Or you can mark them as failures when they're accessed from the company's mobile application. Similarly, `301` and `302` indicate failure when they're accessed from the client that doesn't support redirect.
5862

59-
Partially accepted content `206` may indicate a failure of an overall request. For instance, Application Insights endpoint receives a batch of telemetry items as a single request. It returns `206` when some items in the batch were not processed successfully. Increasing rate of `206` indicates a problem that needs to be investigated. Similar logic applies to `207` Multi-Status where the success may be the worst of separate response codes.
63+
Partially accepted content `206` might indicate a failure of an overall request. For instance, an Application Insights endpoint might receive a batch of telemetry items as a single request. It returns `206` when some items in the batch weren't processed successfully. An increasing rate of `206` indicates a problem that needs to be investigated. Similar logic applies to `207` Multi-Status where the success might be the worst of separate response codes.
6064

61-
You can read more on request result code and status code in the [blog post](https://apmtips.com/posts/2016-12-03-request-success-and-response-code/).
65+
You can read more about the request result code and status code in the [blog post](https://apmtips.com/posts/2016-12-03-request-success-and-response-code/).
6266

6367
## Custom properties
6468

@@ -70,8 +74,7 @@ You can read more on request result code and status code in the [blog post](http
7074

7175
## Next steps
7276

73-
- [Write custom request telemetry](./api-custom-events-metrics.md#trackrequest)
74-
- See [data model](data-model.md) for Application Insights types and data model.
75-
- Learn how to [configure ASP.NET Core](./asp-net.md) application with Application Insights.
76-
- Check out [platforms](./app-insights-overview.md#supported-languages) supported by Application Insights.
77-
77+
- [Write custom request telemetry](./api-custom-events-metrics.md#trackrequest).
78+
- See the [data model](data-model.md) for Application Insights types and data models.
79+
- Learn how to [configure an ASP.NET Core](./asp-net.md) application with Application Insights.
80+
- Check out [platforms](./app-insights-overview.md#supported-languages) supported by Application Insights.

articles/azure-monitor/app/live-stream.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -171,7 +171,7 @@ If you want to monitor a particular server role instance, you can filter by serv
171171

172172
Live Metrics custom filters allow you to control which of your application's telemetry is streamed to the Live Metrics view in the Azure portal. The filters criteria are sent to the apps that are instrumented with the Application Insights SDK. The filter value could potentially contain sensitive information, such as the customer ID. To keep this value secured and prevent potential disclosure to unauthorized applications, you have two options:
173173

174-
- **Recommended:** Secure the Live Metrics channel by using [Azure Active Directory (Azure AD) authentication](./azure-ad-authentication.md#configuring-and-enabling-azure-ad-based-authentication).
174+
- **Recommended:** Secure the Live Metrics channel by using [Azure Active Directory (Azure AD) authentication](./azure-ad-authentication.md#configure-and-enable-azure-ad-based-authentication).
175175
- **Legacy (no longer recommended):** Set up an authenticated channel by configuring a secret API key as explained in the "Legacy option" section.
176176

177177
> [!NOTE]

0 commit comments

Comments
 (0)