Custom Telemetry #112
Replies: 2 comments
-
Guidelines coming from @KennieNP :
Coding patterns, including
May be @KennieNP can take the lead, as this is already documented somewhere internally at Microsoft. |
Beta Was this translation helpful? Give feedback.
-
This is a copy-paste from our internal guidelines === Guiding principles for telemetry === ==== Think about it as an API ==== Therefore, signal must be treated as any other API
==== Naming conventions and telemetry schema ====
Consider always having a "message" field that expresses in human readable form what the telemetry event is about.
==== Candidate data for telemetry ==== Also, note that customers pay for data ingestion. So be mindful to not flood their telemetry resources. If you do not know where to start, consider using telemetry for deflection. In Dynamics 365 Business Central, they started with signal about authorization (successful/failed) to deflect support cases and IcM tickets that was due to disabled users/wrong licenses, ... ==== How customers use telemetry ====
Customers typically start in the Application Insights portal and then move on to use more advanced tools for analytics (KQL, Power BI, Excel, ...). Once they have seen the light, they will likely start alerting on telemetry using Azure Monitor Alerts or setting up Power Automate flows. Business Central have developed a telemetry maturity model (based on the Gartner BI maturity model) for how organizations can evolve to use telemetry proactively in their business processes. === Privacy considerations === ==== What we NEVER can emit ==== Decorate emitter methods in code with privacy classification (use the MS taxonomy) to help developers think of privacy at development time. Only emit signal that is of type System Metadata or OII. |
Beta Was this translation helpful? Give feedback.
-
Custom Telemetry Pattern
Beta Was this translation helpful? Give feedback.
All reactions