Add SDK Log health metrics #1921
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
AlexanderWert
approved these changes
Mar 14, 2025
AlexanderWert
moved this from Untriaged
to Needs More Approval
in Semantic Conventions Triage
|
related to #1979 |
lzchen
approved these changes
Mar 18, 2025
trask
reviewed
Mar 18, 2025
lmolkova
approved these changes
Mar 25, 2025
lmolkova
moved this from Needs More Approval
to Ready to be Merged
in Semantic Conventions Triage
3 tasks
github-project-automation
bot
moved this from Ready to be Merged
to Needs More Approval
in Semantic Conventions Triage
3 tasks
MrAlias
added a commit
to open-telemetry/opentelemetry-go
that referenced
this pull request
May 20, 2025
- Add the new metric API package structure prototyped in https://github.com/MrAlias/semconv-go Prototypes of new metric API use: - MrAlias/opentelemetry-go-contrib#6136 - MrAlias/opentelemetry-go-contrib#6135 - MrAlias/opentelemetry-go-contrib#6134 - Generate `semconv/v1.32.0` - Drop the `kestrel` metric namespace as this is a Java specific technology ## [`v1.32.0` semantic convention release notes](https://github.com/open-telemetry/semantic-conventions/releases/tag/v1.32.0): <div data-pjax="true" data-test-selector="body-content" data-view-component="true" class="markdown-body my-3"><p>📣 This release is the second release candidate for the Database Semantic Conventions, with <strong>db conventions stability planned to be declared in the subsequent release</strong>.</p> <h3>🛑 Breaking changes 🛑</h3> <ul> <li><code>device</code>: Change the definition of <code>device.id</code> and make it opt-in. (<a href="open-telemetry/semantic-conventions#1874" data-hovercard-type="issue" data-hovercard-url="/open-telemetry/semantic-conventions/issues/1874/hovercard">#1874</a>, <a href="open-telemetry/semantic-conventions#1951" data-hovercard-type="pull_request" data-hovercard-url="/open-telemetry/semantic-conventions/pull/1951/hovercard">#1951</a>)</li> <li><code>feature_flag</code>: Rename <code>evaluation</code> to <code>result</code> for feature flag evaluation result attributes (<a href="open-telemetry/semantic-conventions#1989" data-hovercard-type="pull_request" data-hovercard-url="/open-telemetry/semantic-conventions/pull/1989/hovercard">#1989</a>)</li> </ul> <h3>🚀 New components 🚀</h3> <ul> <li><code>app</code>: Create <code>app.installation.id</code> attribute (<a href="open-telemetry/semantic-conventions#1874" data-hovercard-type="issue" data-hovercard-url="/open-telemetry/semantic-conventions/issues/1874/hovercard">#1874</a>, <a href="open-telemetry/semantic-conventions#1897" data-hovercard-type="pull_request" data-hovercard-url="/open-telemetry/semantic-conventions/pull/1897/hovercard">#1897</a>)</li> <li><code>cpython</code>: Add CPython runtime garbage collector metrics (<a href="open-telemetry/semantic-conventions#1930" data-hovercard-type="issue" data-hovercard-url="/open-telemetry/semantic-conventions/issues/1930/hovercard">#1930</a>)</li> </ul> <h3>💡 Enhancements 💡</h3> <ul> <li><code>vcs</code>: Add owner and provider name to VCS attribute registry (<a href="open-telemetry/semantic-conventions#1452" data-hovercard-type="issue" data-hovercard-url="/open-telemetry/semantic-conventions/issues/1452/hovercard">#1452</a>)</li> <li><code>vcs</code>: Remove fallback value for VCS provider name attribute (<a href="open-telemetry/semantic-conventions#2020" data-hovercard-type="pull_request" data-hovercard-url="/open-telemetry/semantic-conventions/pull/2020/hovercard">#2020</a>)</li> <li><code>db</code>: Truncate <code>db.query.summary</code> to 255 characters if parsed from the query (<a href="open-telemetry/semantic-conventions#1978" data-hovercard-type="issue" data-hovercard-url="/open-telemetry/semantic-conventions/issues/1978/hovercard">#1978</a>)</li> <li><code>db</code>: Normalize spaces in <code>db.operation.name</code> (if any) (<a href="open-telemetry/semantic-conventions#2028" data-hovercard-type="issue" data-hovercard-url="/open-telemetry/semantic-conventions/issues/2028/hovercard">#2028</a>)</li> <li><code>db</code>: <code>db.operation.parameter.<key></code> should not be captured for batch operations (<a href="open-telemetry/semantic-conventions#2026" data-hovercard-type="issue" data-hovercard-url="/open-telemetry/semantic-conventions/issues/2026/hovercard">#2026</a>)</li> <li><code>db</code>: Add <code>db.stored_procedure.name</code> (<a href="open-telemetry/semantic-conventions#1491" data-hovercard-type="issue" data-hovercard-url="/open-telemetry/semantic-conventions/issues/1491/hovercard">#1491</a>)</li> <li><code>gcp</code>: Adds GCP AppHub labels for resource. (<a href="open-telemetry/semantic-conventions#2006" data-hovercard-type="pull_request" data-hovercard-url="/open-telemetry/semantic-conventions/pull/2006/hovercard">#2006</a>)</li> <li><code>error</code>: Add <code>error.message</code> property for human-readable error message on events. (<a href="open-telemetry/semantic-conventions#1992" data-hovercard-type="pull_request" data-hovercard-url="/open-telemetry/semantic-conventions/pull/1992/hovercard">#1992</a>)</li> <li><code>profile</code>: Extend the list of known frame types with a value for Go and Rust (<a href="open-telemetry/semantic-conventions#2003" data-hovercard-type="pull_request" data-hovercard-url="/open-telemetry/semantic-conventions/pull/2003/hovercard">#2003</a>)</li> <li><code>otel</code>: Adds SDK self-monitoring metrics for log processing (<a href="open-telemetry/semantic-conventions#1921" data-hovercard-type="pull_request" data-hovercard-url="/open-telemetry/semantic-conventions/pull/1921/hovercard">#1921</a>)</li> </ul>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow up of #1631 adding SDK health metrics for logs.
Changes
Adds:
The processor and exporter metrics are very similar to the span-ones in #1631. In fact, they are pretty much a copy-paste.
So I think with the concrete examples at hand now, it would be a good time to revisit the decision and reasoning whether to keep the metrics separated per signal or combine them with and differentiate via an attribute (e.g.
otel.signal.kind=span,log,metric).The detailed reasoning for separation can be found in this comment.
I still think that reasoning holds for processors: Log and Span Processors do have the same name, but work differently (e.g. span processor has multiple callbacks). Therefore it makes sense to have different namespaces for their metrics to not make things ugly in the future when new, span or log specific metrics need to be added or the processor specs diverge further. This already shows in the fact that metrics do not have processors, but
MetricReaders.For the exporters I'm not so sure anymore: The exporters are separated in the spec, but it is in fact mostly copy-pasted and I think they are unlikely to diverge. So if we wanted to reduce the size of the spec here and ease some queries (e.g. "are there errors in any exporter?"), we could think of combining them.In the SIG meeting we decided to keep them separate for now, see #2002.
Looking forward to hearing your opinions here!
Merge requirement checklist
[chore]schema-next.yaml updated with changes to existing conventions.