Microsoft/alguidelines
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update content/docs/BestPractices/CustomTelemetry/index.md

Browse source 
Co-authored-by: Henrik Helgesen <henrik@helgesen.consulting>
This commit is contained in:
waldo 2022-03-02 10:04:47 +01:00 • committed by GitHub
parent bfc249435d
commit 78d169687a
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
content/docs/BestPractices/CustomTelemetry/index.md
View file

@ -32,7 +32,7 @@ Therefore, signal must be treated as any other API
To make it easy for the consumer of telemetry to work with the data, please To make it easy for the consumer of telemetry to work with the data, please
- use **PascalCasing**. This makes all fields in Application Insights look the same (signal logged through the AL LogMessage method will have "al" prefixed to dimension names. - use **PascalCasing**. This makes all fields in Application Insights look the same (signal logged through the AL LogMessage method will have "al" prefixed to dimension names.
- **Don't use special characters or spaces** for fields/custom dimension keys. This makes the KQL queries so much easier to write - **Do not use special characters or spaces** for fields/custom dimension keys. This makes the KQL queries so much easier to write
- for custom dimensions, consider using prefixes that helps the telemetry consumer understand where the dimension is coming from (e.g. HttpStatusCode, SqlStatement, ...) - for custom dimensions, consider using prefixes that helps the telemetry consumer understand where the dimension is coming from (e.g. HttpStatusCode, SqlStatement, ...)
Consider always having a **"message"** field that expresses in human readable form what the telemetry event is about. Consider always having a **"message"** field that expresses in human readable form what the telemetry event is about.