[chore] add guidelines for telemetry stability levels#14280
[chore] add guidelines for telemetry stability levels#14280codeboten merged 3 commits intoopen-telemetry:mainfrom
Conversation
Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
ChrsMark
force-pushed
the
document_stability_levels
branch
from
f035c00 to
f43a071
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #14280 +/- ##
==========================================
- Coverage 92.17% 92.14% -0.03%
==========================================
Files 668 668
Lines 41510 41513 +3
==========================================
- Hits 38262 38254 -8
- Misses 2215 2221 +6
- Partials 1033 1038 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
||
| ### Metrics | ||
|
|
||
| Metrics emitted by Collector components follow the same stability levels documented by |
There was a problem hiding this comment.
Is this about internal metrics, or metrics emitted by receivers/scrapers? The reference "Internal Telemetry Stability" implies the former, but the reference in the scraper document suggests the latter. I think this should be made extra clear.
There was a problem hiding this comment.
I'm not sure if we have a specific definition to refer to the non-internal metrics. Tried to clarify that and added an example metric system.cpu.time. Any other suggestions on how this could be further clarified would be welcome.
There was a problem hiding this comment.
I think changing the section titles to "Internal Telemetry Stability Levels" and "Internal Metrics" would help.
I would also completely remove the reference in the scraping receivers docs; "metrics" in that doc seems to systematically refer to the metrics the scraper outputs into the pipeline, so non-internal.
There was a problem hiding this comment.
"metrics" in that doc seems to systematically refer to the metrics the scraper outputs into the pipeline, so non-internal.
That's what I want to cover here :), metrics the scraper outputs into the pipeline. Not the internal ones.
There was a problem hiding this comment.
Oh. In that case, it's the reference to the "Internal Telemetry Stability" page that's confusing, since that page is specifically about internal telemetry. If I'm not mistaken, the changes made in #14070 were also about internal metrics 🤔 I think there may have been some confusion somewhere
There was a problem hiding this comment.
If it really is just receiver/scraper metrics, could we directly refer to the SemConv document / OTEP that this change is inspired from?
There was a problem hiding this comment.
The idea is that both internal telemetry and non-internal telemetry should follow the same stability levels.
There was a problem hiding this comment.
Okay. In that case, in terms of wording I would recommend something like: "Metrics emitted by Collector scrapers/receivers (e.g. system.cpu.time) follow the same stability levels as the Collector's internal metrics (e.g. otelcol_process_cpu_seconds), as documented in [Internal Telemetry Stability]"
Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
This comment was marked as outdated.
This comment was marked as outdated.
Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
605123a
4 participants
Description
This PR adds a guideline section about the stability levels the produced components' telemetry should follow.
Link to tracking issue
Related to open-telemetry/opentelemetry.io#8558 and #13910.