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.
Looking forward to hearing your opinions here!
Merge requirement checklist
[chore]
schema-next.yaml updated with changes to existing conventions.