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:
-
Join us, by providing comments or feedback, in our Discussions page
-
Submit a PR with changes to this file ( docs/Applications.FlightRecorder.PriorToCrash.document.md)
Direct Sharing URL
Interesting Application : FlightRecorder into Memory Dump
Scenario Summary
Imagine a long-running Flight Recorder that collects 100 times the logging that would normally stream through something similar to OpenTelemetry.
This logging would be very verbose, containing information like function entry and exit, web requests, queue lengths, open file pointers, file indexes, and so on.
Normally, this type of information would clutter up a backend database and be useless in most contexts.
However, when collected during a process crash, this information is sufficiently inexpensive and can significantly boost productivity.
A Flight Recorder like this is not free; the logs will have to go into a circular buffer, which does cause CPU load. But when done well, for example, using something similar to ETW or user events on Linux, this CPU load can be very inexpensive compared to other techniques.
When the process crashes, this log can be collected and will serve as a set of breadcrumbs leading to that process crash.
Pretty fantastic.
This approach also has a positive impact on the developer's mindset. Developers often struggle with the need to suppress logging messages due to cost, security, and privacy concerns imposed by business and finance teams.
With the availability of Flight Recorders, developers can feel reassured. Knowing that in the event of a process crash, they will have access to the critical logs leading up to the incident, alleviates their concerns and allows them to focus on more productive tasks.