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

Semconv schema: don't require attributes on metrics #405

Closed
lmolkova opened this issue Mar 27, 2024 · 3 comments
Closed

Semconv schema: don't require attributes on metrics #405

lmolkova opened this issue Mar 27, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@lmolkova
Copy link
Contributor

Json schema validation shows error when metrics is defined without attributes
image

with Missing property "attributes".yaml-schema: https://raw.githubusercontent.com/open-telemetry/build-tools/v0.24.0/semantic-conventions/semconv.schema.json

Metrics don't have to have attributes or may inherit them through extension mechanism.

@lmolkova lmolkova added the bug Something isn't working label Mar 27, 2024
@jsuereth jsuereth closed this as completed Oct 9, 2024
@jsuereth jsuereth reopened this Oct 9, 2024
@lmolkova lmolkova transferred this issue from open-telemetry/build-tools Oct 9, 2024
@jerbly
Copy link
Contributor

jerbly commented Nov 24, 2024

@lmolkova @jsuereth - I'm happy to take this one on if you would like to assign it to me. It's similar to a PR I just did for group stability: #467

I will change the EBNF and json schema. However, there is currently a difference in this area between the EBNF and the schema. The EBNF currently defines attributes as mandatory for all group types and extends optional. Whereas the schema defines attributes and extends with an anyOf meaning it's valid to omit attributes provided you have extends instead. There's currently one single non-metric defined with extends and without attributes:

  - id: span.db.client
    type: span
    stability: experimental
    brief: This span defines the attributes used to perform database client calls.
    span_kind: client
    extends: trace.db.common.full

Is this a valid case? If so the EBNF should be defined like this ( extends | attributes | ( extends attributes ) ).

@jsuereth
Copy link
Contributor

This is a valid use case.

@lquerel
Copy link
Contributor

lquerel commented Dec 3, 2024

Done in #494

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

No branches or pull requests

4 participants