-
Notifications
You must be signed in to change notification settings - Fork 893
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
feat: add attributes for cloud-native deployment #3169
Conversation
17b5c68
to
ca348c4
Compare
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Hey @carlosalberto, do you have some free cycles to look into this PR? :) |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Signed-off-by: Giovanni Liva <giovanni.liva@dynatrace.com>
Signed-off-by: Giovanni Liva <giovanni.liva@dynatrace.com>
24a637e
to
349be5a
Compare
This is not stale |
Signed-off-by: Giovanni Liva <giovanni.liva@dynatrace.com>
cc @open-telemetry/specs-logs-approvers |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
ping to remove the stale label |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
This is not stale |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
hey @thisthat! can you compare with (any) existing ECS conventions? (see open-telemetry/oteps#222, open-telemetry/semantic-conventions#1012, and #3409 for context) also, I think we can (and are trying to) share yaml definitions across signals now, so I think you can have a single yaml definition of the attributes now (see http for an example) |
Hey @trask, thanks for the pointers! I'll have a look at the ECS conventions and check for any overlap 👍 |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
I did have a look and didn't find any ECS attributes which map well to this. The closest are package, which could describe a built artifact to be deployed, and service, which could describe the application being deployed. The proposed conventions here don't really map well to ECS service fields as they are application level. I did not find any application level fields in ECS. Further, otel has typically used the service fields to describe the service being instrumented, but the service here is acting on a different service and we have no real way distinguish between the service instrumented and the service deployed. Package might work well in a CI/CD context, but doesn't map well to any of the proposed fields here. This proposal seems more to do with deploying workloads rather than the actual build step. There are orchestrator fields which seem promising for describing the entity actually scheduling the workload, but again I was unable to find a field describing the workload being orchestrated. |
@AlexanderWert @ruflin can you comment on whether you see any conflicts with adding |
Looking into ECS fields to be used I stumbled over the same fields as @dyladan but couldn't see a direct mapping. @felixbarny What is your team using for this at the moment? One general thing I stumbled over is the term application vs service. @thisthat What is for you the difference between the two? I think if we start to use both, we must have a really good descriptions for users that pick it up to know which one to use in which scenario. Overall, I definitively see value in being able to describe a deployment. |
I don't think we're tracking any metadata about deployments or "applications", just services.
++ |
@thisthat heads up - most likely this PR will be closed, and we'll ask you to resubmit the PR in a new repo, please refer to #3474 (comment). |
@thisthat hey! Could you provide some more information/examples of how the schema you are adding will be used in real world scenarios for collectors like in Kubernetes environments? From k8s docs the workload can be a Deployement, StatefulSet, Daemonset or Job/Cronjob. Would this information be mapped somehow on the schema you provide? If yes, could you provide an example of how we fill the proposed schema fields from the actual k8s Resource? What I'm trying to understand here is how an agent/collector would leverage those values to report data collected for Pods, Containers or any other kind of Resource. BTW, orchestrator schema from ECS includes the Sorry if I miss anything here, and happy to elaborate more if needed :). |
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.
Please move this to https://github.com/open-telemetry/semantic-conventions
Thanks all for looking into this PR. I will provide a new PR in the new repo and tag all the people here so we can continue the discussion over there.
I used the term service to refer to the general notion of microservice. Maybe a better name could be process?!. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
This PR was moved to open-telemetry/semantic-conventions#24. |
Fixes #3168
Changes
This PR introduces semantic conventions for Cloud Native Deployments.
Related issues