-
Notifications
You must be signed in to change notification settings - Fork 179
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
Generate FaaS metrics semconv from YAML #88
Generate FaaS metrics semconv from YAML #88
Conversation
81e6e51
to
14ecb07
Compare
This PR still suffers from the issues I described in #86. It's not clear which attributes are to be added to which metrics. There's seems to be a distinction between incoming and outgoing metrics/attributes but the current conventions don't distinguish them. Any people familiar/experienced with this topic that can help? |
c375c82
to
cfe0e20
Compare
@open-telemetry/lambda-extension-approvers can you review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming this doesn't introduce anything new and is just moving existing metric semconv to YAML. (That seems to be the case, but difficult to tell.)
@tylerbenson yes, that was the goal - just move them to yaml. But these conventions I think are unclear. I opened a separate issue where I described the problems I see #86. Could you please take a look and share your thoughts? |
cfe0e20
to
1cf9e98
Compare
1cf9e98
to
fd64349
Compare
We discussed in slack together with the initial author, @skonto (than you!) and others about the unclear state of the current FaaS metrics. Here's the summary: We reached the conclusion that the existing metrics are all "incoming", meaning they are to be recorded by the FaaS instance itself. The problem is that some of the metrics can also be reported by whoever is invoking the FaaS. These are:
From @skonto on initial intentions:
For the sake of moving forward with this PR, we then agreed to remove the notion of "client-related" metrics and focus only on FaaS metrics. I will create follow up issues to track the rest of the work:
Please upvote/leave comments if you agree with this or not. I will then do the follow ups once we have an agreement. CC @jsuereth @AlexanderWert @lmolkova @Oberon00 @tylerbenson |
You may also want to consider dropping the faas.client concept altogether (also from tracing). It seems to only make sense on AWS, and maybe would be better incorporated at https://github.com/open-telemetry/semantic-conventions/blob/main/docs/cloud-providers/aws-sdk.md#aws-service-specific-attributes |
For the "TODO" above, I created separated issues: |
Closes #77, #86
CC @skonto @tylerbenson as previous authors