Add metrics spec supplementary guidelines #1966
Conversation
reyang
added
area:sdk
There was a problem hiding this comment.
This generally looks very good. I need to take a second pass on grammar/phrasing (That's my own worst enemy), but the content looks like a great addition/treatment of the issue for implementers.
One thing I'd like to call out though is a suggestion around Memory Management and Allocations. While it's impossible to remove all allocations on the hot path of synchronous metric collection, particularly if using Baggage, SDK authors should be encouraged to reduce memory contention in the hot path, and pay most overhead at startup. This aligns with OTel's vision of "least disruption to runtime", which shows up in recommendations around error-reporting during operation and likely should also apply to things like memory usage.
I like the idea of limiting memory as suggested here, just want to also reinforce this "allocate ahead of time and reuse" notion, which we actually expose a bit more directly in Java (and I need to annotate).
Specifically, one scenario to call out (more important for Logs/Traces than metrics) is how a system behaves when memory can no longer be allocated. Do we still get observability or is it gone?
I've updated the PR to cover the pre-allocation for garbage collected languages. PTAL.
I've updated the PR trying to scratch the surface. If we need to dig deeper, a separate PR might be better? |
Co-authored-by: Alan West <3676547+alanwest@users.noreply.github.com>
Related to #1873 and #1891.
If you find it hard to look at the raw markdown file, here is a rendered version https://github.com/reyang/opentelemetry-specification/blob/reyang/guideline/specification/metrics/supplementary-guidelines.md.