From 42358aab34506f91a1a582624fd713ff550f81a5 Mon Sep 17 00:00:00 2001 From: christianbraeunlich Date: Thu, 17 Mar 2022 21:44:50 +0100 Subject: [PATCH] added period at the end --- 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 9f8b7ba0..02fc2d19 100644 --- a/content/docs/BestPractices/CustomTelemetry/index.md +++ b/content/docs/BestPractices/CustomTelemetry/index.md @@ -71,7 +71,7 @@ Of course it is possible to have a single object as a central place to emit tele ## Candidate data for telemetry -Telemetry must be **actionable** for the customer. Do not emit signals that they cannot act on (knowing about CPU performance counters on the database is useless if the partner cannot scale the database) +Telemetry must be **actionable** for the customer. Do not emit signals that they cannot act on period (knowing about CPU performance counters on the database is useless if the partner cannot scale the database). Also, note that customers pay for data ingestion. So be mindful to not flood their telemetry resources. Consider to use TelemetryScope::ExtensionPublisher by default and only use TelemetryScope::All in case the customer can also act on the data.