feat: add attributes for cloud-native deployment #24
Conversation
Signed-off-by: Giovanni Liva <giovanni.liva@dynatrace.com>
Signed-off-by: Giovanni Liva <giovanni.liva@dynatrace.com>
Signed-off-by: Giovanni Liva <giovanni.liva@dynatrace.com>
There was a problem hiding this comment.
Some of the concepts, such as application and workload aren't unique to k8s/cloud native deployments. I wouldn't segregate them under a specific deployment namespace but rather try to map them to more generic concepts that also make sense outside of cloud native deployments.
This is a good example where it would be good to have a common catalogue of attributes and logs and traces just reference from the common catalogue.
|
|
||
| | Attribute | Type | Description | Examples | Requirement Level | | ||
| |---|---|---|---|---| | ||
| | `deployment.workload.name` | string | The name of the single workload under deployment. | `podtato-head-hat`; `podtato-head-left-leg` | Required | |
There was a problem hiding this comment.
Sounds like this is essentially the same as service.name?
There was a problem hiding this comment.
Thanks @felixbarny for pointing that out. You are right, this has the same semantics as service.name. I'll adapt the PR to make use of that attribute.
|
Does it make sense to spin up a CI/CD working group and have this as part of that? |
|
Related to open-telemetry/oteps#223. @horovits FYI. |
| | Attribute | Type | Description | Examples | Requirement Level | | ||
| |---|---|---|---|---| | ||
| | `deployment.workload.name` | string | The name of the single workload under deployment. | `podtato-head-hat`; `podtato-head-left-leg` | Required | | ||
| | `deployment.workload.namespace` | string | The namespace in which the workload will be deployed. | `podtatohead` | Recommended | |
There was a problem hiding this comment.
deployment.workload.{name|version|namespace} seem to overlap with service.* attributes. Should we just share them here?
Also deployment.workload.status seems to be the status of the deployment, less the workload itself.
There was a problem hiding this comment.
Thank @jsuereth for looking into this. I agree, these 3 attributes can be replaced with service.* attributes.
Also deployment.workload.status seems to be the status of the deployment, less the workload itself.
Deployment is an overloaded term, especially in K8s. Maybe delivery would be a better term 🤔
If I read "status of the deployment", I think about the specific Kubernetes Deployment CR, but here I'd like to capture also the different "deployment models" that K8s allows which are grouped around the term Workload.
| |---|---|---|---|---| | ||
| | `deployment.task.name` | string | The name that identifies the executed task. | `database-migration`; `report-metric`; `provision-infrastructure` | Required | | ||
| | `deployment.task.status` | string | The status of the task execution. | `Pending` | Recommended | | ||
| | `deployment.application.name` | string | The name of the application under deployment. | `podtato-head` | Required | |
There was a problem hiding this comment.
I don't understand the difference between workload + application here. Can you outline that somewhere?
There was a problem hiding this comment.
Sure, maybe this should be in the "Overview" section.
The difference is that an application is an abstraction that groups together different workloads. For example, an application could be my-awesome-website which comprises 3 different workloads: frontend, backend, and database.
Tasks are actions that are executed when delivering the application and its individual workloads. For example, a task could be sending a slack message that the delivery for a specific component started/finished.
Do you think this explanation is clear @jsuereth? If so, I would add it to the document.
I would be interested in such thing 👍 |
jsuereth
added
the
experts needed
|
Hi @thisthat! Sorry for the ping, but is this something you are still interested in working on? |
|
Hey @joaopgrassi sure! I am still interested 👍 |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
| type: event | ||
| brief: > | ||
| This document defines attributes for Cloud Native deployments of applications. | ||
| These attributes can be attached to spans when performing operations for deploying applications on Kubernetes, |
There was a problem hiding this comment.
Why mention Kubernetes here?
Opentelemetry is open source and vendor neutral and as such not restricted to deployments on just K8s.
Maybe it should be phrased that "deploying applications on Kubernetes" is an example.
The same question applies for the brief of deployment.workload below.
|
|
||
| ### Application | ||
|
|
||
| Each stage of the lifecycle of a cloud-native application deployment SHOULD be recorded as an Event on the span during |
There was a problem hiding this comment.
Should these events have any relation with the Continuous Deployment Events of CDEvents?
|
Hi @thisthat ! We changed how the CHANGELOG.md is managed. Please take a look at https://github.com/open-telemetry/semantic-conventions/blob/main/CONTRIBUTING.md#adding-a-changelog-entry to see what needs to be done. Sorry for the disruption. |
|
Referencing: #833 |
|
Let's close this PR as being stale. We can reopen it with changes (including attribute registry usage) and align w/ exisitng CI/CD plans. |
Fixes #3168
Old PR: open-telemetry/opentelemetry-specification#3168 / open-telemetry/opentelemetry-specification#3169
Changes
This PR introduces semantic conventions for Cloud Native Deployments.
Related issues
FYI @dyladan @trask @ruflin @felixbarny @reyang @ChrsMark @jsuereth