From 78d169687ab20214c8a0838b5e34b22b16589cf3 Mon Sep 17 00:00:00 2001 From: waldo Date: Wed, 2 Mar 2022 10:04:47 +0100 Subject: [PATCH] Update content/docs/BestPractices/CustomTelemetry/index.md Co-authored-by: Henrik Helgesen --- content/docs/BestPractices/CustomTelemetry/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/BestPractices/CustomTelemetry/index.md b/content/docs/BestPractices/CustomTelemetry/index.md index 978b48c5..9f8b7ba0 100644 --- a/content/docs/BestPractices/CustomTelemetry/index.md +++ b/content/docs/BestPractices/CustomTelemetry/index.md @@ -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 - 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, ...) Consider always having a **"message"** field that expresses in human readable form what the telemetry event is about.