You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: projects/service-and-deployment-semconv.md
+27-39Lines changed: 27 additions & 39 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,18 +4,17 @@
4
4
5
5
Cloud providers have long supported customer-defined tags (key-value metadata) as a mechanism to organize resources, manage cost, apply governance controls, and enable automation. These tag, such as environment=prod or costCenter=acme-digital, are widely used across platforms like AWS, Azure, and GCP to group and manage infrastructure, and are leveraged by services including identity and access management, billing systems, policy engines, and security tooling.
6
6
7
-
Despite their ubiquity, these tags are not standardized across providers and often lack well-defined semantics. Different users may express the same concept in different ways (e.g., env=prod vs. environment=production), and tools consuming these tags must implement custom logic to interpret them. This fragmentation makes it difficult to reason about infrastructure consistently, especially in multi-cloud and hybrid environments where teams rely on observability and automation platforms to derive insights from tags.
7
+
Despite their ubiquity, these tags are not standardized across providers and often lack well-defined semantics. Different users may express the same concept in different ways (e.g., env=prod vs. environment=production), and tools consuming these tags must implement custom logic to interpret them. This fragmentation makes it difficult to reason about infrastructure consistently, especially in multi-cloud and hybrid environments where teams rely on observability and automation platforms to derive insights from tags.
8
8
9
9
Note: These metadata fields are commonly referred to as tags by cloud providers like AWS, Azure, and GCP. However, to remain consistent with OpenTelemetry conventions, we will refer to them as attributes throughout this proposal.
10
10
11
11
This SIG proposes to define semantic conventions for a scoped set of commonly used resource attributes across three phases:
12
12
13
-
Phase 1: Extend the Service entity with new attributes (service.owner, service.criticality).
14
-
Phase 2: Stabilize deployment.environment.name attribute and finish model for deployment related entities.
15
-
Phase 3: Formulate a plan for tagging resources with sensitivity labels, and interaction with other telemetry.
13
+
-Phase 1: Extend the Service entity with new attributes (service.owner, service.criticality).
14
+
-Phase 2: Stabilize deployment.environment.name attribute and finish model for deployment related entities.
15
+
-Phase 3: Formulate a plan for tagging resources with sensitivity labels, and interaction with other telemetry.
16
16
17
17
Standardizing the meaning of these attributes will allow telemetry pipelines to treat them as first-class, interoperable metadata. For example, resource detectors in OpenTelemetry can surface these resource attributes from platform metadata, making them accessible to downstream tools in a consistent format. With shared semantics in place, observability and security platforms can enable features like governance-aware dashboards, default security posture suggestions, and cross-cloud resource attribution without relying on cloud- or vendor-specific integrations.
18
-
---
19
18
20
19
### Current Challenges
21
20
@@ -25,18 +24,16 @@ Standardizing the meaning of these attributes will allow telemetry pipelines to
25
24
26
25
-**Limited utility in observability**: Attributes show up in telemetry, but their ambiguous structure makes them hard to use for dashboards, alerting, or policy logic.
27
26
28
-
---
29
-
30
27
### Goals, objectives, and requirements
31
28
32
29
The goal of this project is to define a shared understanding for a set of commonly used resource attributes. Initial areas of work include:
33
30
34
-
* Define the scoped set of resource attributes and their recommended values
35
-
* Ensure alignment with existing OpenTelemetry resource attributes where applicable
36
-
* Collaborate with the open source community and other cloud providers for cross-domain alignment
31
+
- Define the scoped set of resource attributes and their recommended values
32
+
- Ensure alignment with existing OpenTelemetry resource attributes where applicable
33
+
- Collaborate with the open source community and other cloud providers for cross-domain alignment
37
34
38
-
---
39
35
## Initial Attribute Scope and Proposals
36
+
40
37
This section outlines the initial set of resource-level attributes, their expected types, example values, and rationale. Where applicable, we build on existing OTel attributes; in other cases, we propose new attributes/namespaces.
41
38
42
39
## Initial Attribute Scope
@@ -47,21 +44,20 @@ This section outlines the initial set of resource-level attributes, their expect
| Data | sensitivity | "high", "medium", "low" |`data.sensitivity`| Proposed (new entity) |
50
-
---
51
47
52
48
## Deliverables
49
+
53
50
Initial deliverables will include:
54
51
55
-
* A specification defining semantic conventions for the scoped set of resource attributes including a classification of these attributes by domain (e.g., Operations, Security, Finance).
56
-
* Recommended value sets and usage guidance for applicable resource attributes
57
-
* Alignment with existing OpenTelemetry resource attributes where relevant
58
-
* Build prototype ResourceDetectors that retrieve standardized attributes from platform metadata services and surface these attributes as part of OpenTelemetry resource data.
59
-
* A classification and normalization rubric that:
60
-
- Helps in mapping common tag variants used across providers and organizations to canonical OpenTelemetry attributes
61
-
- Provides normalization guidance to support consistent implementation (e.g., enum values, casing, value translation)
62
-
* Documentation and examples for adoption by cloud providers, observability platforms, and security tools
52
+
- A specification defining semantic conventions for the scoped set of resource attributes including a classification of these attributes by domain (e.g., Operations, Security, Finance).
53
+
- Recommended value sets and usage guidance for applicable resource attributes
54
+
- Alignment with existing OpenTelemetry resource attributes where relevant
55
+
- Build prototype ResourceDetectors that retrieve standardized attributes from platform metadata services and surface these attributes as part of OpenTelemetry resource data.
56
+
- A classification and normalization rubric that:
57
+
- Helps in mapping common tag variants used across providers and organizations to canonical OpenTelemetry attributes
58
+
- Provides normalization guidance to support consistent implementation (e.g., enum values, casing, value translation)
59
+
- Documentation and examples for adoption by cloud providers, observability platforms, and security tools
63
60
64
-
---
65
61
## Staffing / Help Wanted
66
62
67
63
We are seeking domain experts to work on the definition, alignment, and adoption of standardized resource attributes across cloud platforms and observability systems.
@@ -70,9 +66,8 @@ The goal is to follow @tedsuo's proposed [Semantic Convention Process](https://d
70
66
71
67
-**Stage 1: Working Group Preparation** — Define scope, gather contributors, and align on the initial set of attributes.
72
68
-**Stage 2: Prototyping and Finalizing Semantic Conventions Proposal** — Build prototypes using the proposed attributes and refine the semantic conventions for final review and submission.
73
-
-**Stage 3: Implementation**
69
+
-**Stage 3: Implementation**
74
70
75
-
---
76
71
### Required staffing
77
72
78
73
**Project Leads:**
@@ -81,46 +76,39 @@ The goal is to follow @tedsuo's proposed [Semantic Convention Process](https://d
Stage 1 (Working Group Preparation) is currently underway. We are aligning on the initial scoped set of attributes, gathering contributors, and identifying sponsors and maintainers.
105
98
106
-
Stage 2 (Stabilizing the Specification) will begin once we have adequate staffing and have aligned on a meeting schedule (currently targeting bi-weekly sessions).
99
+
Stage 2 (Stabilizing the Specification) will begin once we have adequate staffing and have aligned on a meeting schedule (currently targeting bi-weekly sessions).
107
100
108
-
Stage 3 (Implementation) will begin after the initial tag set is reviewed and marked stable.
109
-
110
-
---
101
+
Stage 3 (Implementation) will begin after the initial tag set is reviewed and marked stable.
0 commit comments