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

Clarify if HTTP metrics semantic conventions require ALL the metrics to be implemented #2972

Closed
reyang opened this issue Nov 22, 2022 · 6 comments · Fixed by #3158
Closed
Assignees
Labels
semconv:HTTP spec:metrics Related to the specification/metrics directory

Comments

@reyang
Copy link
Member

reyang commented Nov 22, 2022

What did you expect to see?

The HTTP metrics semantic convention spec should provide clarity "what is considered a compliant implementation", e.g. "an implementation is considered compliant if it has implemented all of the metrics described by this spec" or "an implementation is considered compliant if it has implemented at least one of the metrics described by this spec" or mark some metrics as REQUIRED and say "an implementation is considered compliant if and only if it has implemented ALL the REQUIRED metrics described by this spec".

Additional context.

The current spec has vague wording "The following metric instruments MUST be used to describe HTTP operations. They MUST be of the specified type and units."

@reyang reyang added spec:metrics Related to the specification/metrics directory semconv:HTTP labels Nov 22, 2022
@reyang reyang moved this to Blockers for HTTP semconv stability in Semantic Conventions + Instrumentation Stability WG Nov 22, 2022
@carlosalberto
Copy link
Contributor

I don't think we have a definition for this anywhere, not even for tracing, right?

@reyang
Copy link
Member Author

reyang commented Nov 28, 2022

I don't think we have a definition for this anywhere, not even for tracing, right?

That's exactly why I opened this issue - in order for us to move semantic convention to Stable, we need to have clarity.

@nerdondon
Copy link

I'm pretty in the camp of having a certain set of metrics marked as required since that means there is a dependable interface. This does mean that the bar for marking more metrics as required would be a breaking change though.

@jsuereth
Copy link
Contributor

So thinking about this a good bit. We want a "T-shaped" API. The idea being you have a set of known consistent http metrics that must be included for baseline observability. Instrumentation can go deeper (and we can do this with optional/allowed metrics), but we should have a baseline that is consistent for tooling & expectation purposes.

@jamesmoessis
Copy link
Contributor

Would this be a simple boolean?

required ::= true | false 

Or would this follow a similar structure to attributes requirement level? i.e.

requirement_level ::= "required"
         |   "conditionally_required" <condition>
         |   "recommended" [condition] # Default if not specified
         |   "optional"

@arminru
Copy link
Member

arminru commented Feb 3, 2023

@jamesmoessis I created #3176 to discuss the desired levels and their definition (also beyond just HTTP).

@github-project-automation github-project-automation bot moved this from Blocker for stability to Done in Spec: HTTP Semantic Conventions Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semconv:HTTP spec:metrics Related to the specification/metrics directory
Projects
Development

Successfully merging a pull request may close this issue.

7 participants