Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add metrics spec supplementary guidelines #1966

Merged
merged 19 commits into from
Sep 30, 2021

Conversation

reyang
Copy link
Member

@reyang reyang commented Sep 24, 2021

@reyang reyang requested review from a team September 24, 2021 20:40
@reyang reyang added area:sdk Related to the SDK spec:metrics Related to the specification/metrics directory labels Sep 24, 2021
@reyang reyang added this to the Metrics API/SDK Feature Freeze milestone Sep 24, 2021
Copy link
Contributor

@jsuereth jsuereth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@reyang
Copy link
Member Author

reyang commented Sep 27, 2021

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).

I've updated the PR to cover the pre-allocation for garbage collected languages. PTAL.

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 trying to scratch the surface. If we need to dig deeper, a separate PR might be better?

Copy link
Contributor

@jmacd jmacd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️ ❤️ ❤️

@jsuereth jsuereth merged commit a43f2b2 into open-telemetry:main Sep 30, 2021
@reyang reyang deleted the reyang/guideline branch September 30, 2021 16:22
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
* add metrics spec supplementary guidelines

* fix wording

* tweak wording

* improve readability

* fix typo

* spellcheck

* fix typo

* add more examples

* try to clarify a bit

* improve wording

* cover more topics

* fix typo

* fix typo

* layout

* fix typo

* Update specification/metrics/supplementary-guidelines.md

Co-authored-by: Alan West <[email protected]>

Co-authored-by: Alan West <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:sdk Related to the SDK spec:metrics Related to the specification/metrics directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants