feat: add attributes for cloud-native deployment

[thisthat]

Fixes #3168

Changes

This PR introduces semantic conventions for Cloud Native Deployments.

Related issues

• Semantic Convention for Deployments #3168

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[thisthat]

Hey @carlosalberto, do you have some free cycles to look into this PR? :)

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[dyladan]

This is not stale

[carlosalberto]

cc @open-telemetry/specs-logs-approvers

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[thisthat]

ping to remove the stale label

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[dyladan]

This is not stale

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[trask]

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)

[thisthat]

Hey @trask, thanks for the pointers! I'll have a look at the ECS conventions and check for any overlap 👍

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[dyladan]

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.

[trask]

@AlexanderWert @ruflin can you comment on whether you see any conflicts with adding deployment.* attributes? thx

[ruflin]

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.

[felixbarny]

@felixbarny What is your team using for this at the moment?

I don't think we're tracking any metadata about deployments or "applications", just services.

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.

++

[reyang]

@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).

[ChrsMark]

@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 orchestrator.resource.* fields that might be familiar here? For example orchestrator.resource.name.

Sorry if I miss anything here, and happy to elaborate more if needed :).

cc: @ruflin @AlexanderWert

[jsuereth]

Please move this to https://github.com/open-telemetry/semantic-conventions

[thisthat]

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.

@ruflin

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.

I used the term service to refer to the general notion of microservice. Maybe a better name could be process?!.
The term application describes the group of services that belongs together and form an application.
Basically, if you look at the K8s recommended labels, the service is the app.kubernetes.io/name and the application is app.kubernetes.io/part-of. This should also answer your question @ChrsMark

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[arminru]

This PR was moved to open-telemetry/semantic-conventions#24.