Add SDK Log health metrics #1921
Open
+577
−0
Conversation
This file contains 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
model/otel/metrics.yaml
Outdated
| brief: "The number of LogRecords for which the export has finished, either successful or failed" | ||
| note: | | ||
| For successful exports, `error.type` MUST NOT be set. For failed exports, `error.type` must contain the failure cause. | ||
| For exporters with partial success semantics (e.g. OTLP with `rejected_spans`), rejected spans must count as failed and only non-rejected LogRecords count as success. |
There was a problem hiding this comment.
does this note about partial success also apply to log exporters? Currently it mentions rejected spans, which is a copy of the corresponding span metrics, I guess?
There was a problem hiding this comment.
Yeah, copy-paste mistake. I even already adjusted the end of the sentence: and only non-rejected LogRecords count as success
|
related to #1979 |
lzchen
approved these changes
Mar 18, 2025
trask
reviewed
Mar 18, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.