From 9dc2b75490ae7ef85e6b049c4e3d5ef477698cc3 Mon Sep 17 00:00:00 2001 From: Daniel Jaglowski Date: Thu, 18 Nov 2021 09:36:45 -0500 Subject: [PATCH] Align runtime metric and resource namespaces (#2112) A 'process.runtime' namespace is currently defined in the resource semantic conventions. The metric semantic conventions suggest that runtime metrics use a 'runtime' namespace. Since the runtime metrics are directly related to the runtime resources, they ought to share a common namespace. Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com> --- .../metrics/semantic_conventions/README.md | 4 ++-- .../runtime-environment-metrics.md | 13 +++++++++---- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/specification/metrics/semantic_conventions/README.md b/specification/metrics/semantic_conventions/README.md index 88401cee156..ca60e3b1d16 100644 --- a/specification/metrics/semantic_conventions/README.md +++ b/specification/metrics/semantic_conventions/README.md @@ -62,8 +62,8 @@ where similar metrics have significantly different implementations across the breadth of all existing metrics. For example, every garbage collected runtime has slightly different strategies and measures. Using a single set of metric names for GC, not divided by the runtime, could create dissimilar comparisons -and confusion for end users. (For example, prefer `runtime.java.gc*` over -`runtime.gc.*`.) Measures of many operating system metrics are similarly +and confusion for end users. (For example, prefer `process.runtime.java.gc*` over +`process.runtime.gc.*`.) Measures of many operating system metrics are similarly ambiguous. ### Units diff --git a/specification/metrics/semantic_conventions/runtime-environment-metrics.md b/specification/metrics/semantic_conventions/runtime-environment-metrics.md index c2d5b68bb5d..5ee78632fe9 100644 --- a/specification/metrics/semantic_conventions/runtime-environment-metrics.md +++ b/specification/metrics/semantic_conventions/runtime-environment-metrics.md @@ -13,7 +13,8 @@ semantic conventions when instrumenting runtime environments. - [Metric Instruments](#metric-instruments) - * [Runtime Environment Specific Metrics - `runtime.{environment}.`](#runtime-environment-specific-metrics---runtimeenvironment) + * [Runtime Environment Specific Metrics - `process.runtime.{environment}.`](#runtime-environment-specific-metrics---processruntimeenvironment) +- [Attributes](#attributes) @@ -27,10 +28,10 @@ does not propose any standard top-level runtime metric instruments. See [OTEP 108](https://github.com/open-telemetry/oteps/pull/108/files) for additional discussion. -### Runtime Environment Specific Metrics - `runtime.{environment}.` +### Runtime Environment Specific Metrics - `process.runtime.{environment}.` Metrics specific to a certain runtime environment should be prefixed with -`runtime.{environment}.` and follow the semantic conventions outlined in +`process.runtime.{environment}.` and follow the semantic conventions outlined in [general metric semantic conventions](README.md#general-metric-semantic-conventions). Authors of runtime instrumentations are responsible for the choice of `{environment}` to @@ -40,7 +41,11 @@ For example, some programming languages have multiple runtime environments that vary significantly in their implementation, like [Python which has many implementations](https://wiki.python.org/moin/PythonImplementations). For such languages, consider using specific `{environment}` prefixes to avoid -ambiguity, like `runtime.cpython.` and `runtime.pypy.`. +ambiguity, like `process.runtime.cpython.` and `process.runtime.pypy.`. There are other dimensions even within a given runtime environment to consider, for example pthreads vs green thread implementations. + +## Attributes + +[`process.runtime`](../../resource/semantic_conventions/process.md#process-runtimes) resource attributes SHOULD be included on runtime metric events as appropriate.