Skip to content
Dynamic Telemetry is a PROPOSAL : please provide feedback! :-)

Dynamic Telemetry is not an implementation, it's a request for collaboration, that will lead to an shared understanding, and hopefully one or more implementations.

Your feedback and suggestions on this document are highly encouraged!

Please:

  1. Join us, by providing comments or feedback, in our Discussions page

  2. Submit a PR with changes to this file ( docs/PositionPaper.SharingDataAmongStakeHoldersIsHard.document.md)

Direct Sharing URL

http://microsoft.github.io/DynamicTelemetry/docs/PositionPaper.SharingDataAmongStakeHoldersIsHard.document/

Sharing data between stake holders is tough; roles and responsibly breakdowns

Points:

  1. Dynamic Telemetry takes a hard position on rigid schema - "no"
  2. Dynamic Telemetry takes a hard position on Durable ID and structured payloads - "YES"

Dynamic Telemetry requires the ability to identify and decode a log, metric, or trace. However, it does not enforce that the structured payload conforms to a schema.

This enforcement is useful in many applications but needs to be enforced at a higher level than Dynamic Telemetry.

If a user of Dynamic Telemetry desires a rigid schema, this is totally acceptable. They should look for, or author, a language processor to fulfill this task.

A keen reader of the Dynamic Telemetry documentation will notice potential incongruity found in the design pattern documentation. Specifically, the design patterns discussed have rigid schemas as their core value proposition. This is potentially something that should be further discussed if the design patterns are included in Dynamic Telemetry or built atop it.

Please see Rude Q&A for more information