Update all links to the specification to point at the 1.21.0 release (#45)
This commit is contained in:
parent
1f4dc6890e
commit
4c5194ae78
|
|
@ -5,6 +5,8 @@ Welcome to the new repository!
|
|||
This is currently a direct copy/filter-branch of the Specification repository
|
||||
with only semantic conventions included.
|
||||
|
||||
This repository is currently using [this specification version][SpecificationVersion].
|
||||
|
||||
## Read the docs
|
||||
|
||||
The documentation currently resides in the previous folders, e.g.
|
||||
|
|
@ -45,3 +47,5 @@ Maintainers ([@open-telemetry/specs-semconv-maintainers](https://github.com/orgs
|
|||
- [Reiley Yang](https://github.com/reyang)
|
||||
|
||||
*Find more about the maintainer role in [community repository](https://github.com/open-telemetry/community/blob/master/community-membership.md#maintainer).*
|
||||
|
||||
[SpecificationVersion]: https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
# Set this to the version number you want to CHANGE in URLs in the repository.
|
||||
PREVIOUS_SPECIFICATION_VERSION="main"
|
||||
# Set this to the version number you want to KEEP in URLs in the repository.
|
||||
LATEST_SPECIFICATION_VERSION="1.20.0"
|
||||
LATEST_SPECIFICATION_VERSION="v1.21.0"
|
||||
# The specific pattern we look for when replacing URLs
|
||||
SPECIFICATION_URL_PREFIX="https://github.com/open-telemetry/opentelemetry-specification/tree/"
|
||||
SPECIFICATION_BLOB_URL_PREFIX="https://github.com/open-telemetry/opentelemetry-specification/blob/"
|
||||
|
|
|
|||
|
|
@ -15,9 +15,9 @@ i.e.:
|
|||
## Writing semantic conventions
|
||||
|
||||
Semantic conventions for the spec MUST adhere to the
|
||||
[attribute naming](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/attribute-naming.md),
|
||||
[attribute requirement level](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/attribute-requirement-level.md),
|
||||
and [metric requirement level](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/metric-requirement-level.md) conventions.
|
||||
[attribute naming](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/common/attribute-naming.md),
|
||||
[attribute requirement level](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/common/attribute-requirement-level.md),
|
||||
and [metric requirement level](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/metrics/metric-requirement-level.md) conventions.
|
||||
|
||||
Refer to the [syntax](https://github.com/open-telemetry/build-tools/tree/v0.18.0/semantic-conventions/syntax.md)
|
||||
for how to write the YAML files for semantic conventions and what the YAML properties mean.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# Document Status
|
||||
|
||||
Semantic Conventions follows the [Specification document status conventions](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/document-status.md).
|
||||
Semantic Conventions follows the [Specification document status conventions](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/document-status.md).
|
||||
|
|
|
|||
|
|
@ -12,5 +12,5 @@ The following semantic conventions for events are defined:
|
|||
* [Events](events.md): Semantic attributes that must be used to represent Events using log data model.
|
||||
|
||||
Apart from semantic conventions for logs, [traces](../../trace/semantic_conventions/README.md), and [metrics](../../metrics/semantic_conventions/README.md),
|
||||
OpenTelemetry also defines the concept of overarching [Resources](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md) with their own
|
||||
OpenTelemetry also defines the concept of overarching [Resources](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/resource/sdk.md) with their own
|
||||
[Resource Semantic Conventions](../../resource/semantic_conventions/README.md).
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
**Status**: [Experimental](../../document-status.md)
|
||||
|
||||
This document defines semantic conventions for recording exceptions on
|
||||
[logs](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md#emit-a-logrecord) and [events](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/event-api.md#emit-event)
|
||||
emitted through the [Logger API](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md#logger).
|
||||
[logs](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/bridge-api.md#emit-a-logrecord) and [events](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/event-api.md#emit-event)
|
||||
emitted through the [Logger API](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/bridge-api.md#logger).
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ emitted through the [Logger API](https://github.com/open-telemetry/opentelemetry
|
|||
## Recording an Exception
|
||||
|
||||
Exceptions SHOULD be recorded as attributes on the
|
||||
[LogRecord](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition) passed to the [Logger](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md#logger) emit
|
||||
[LogRecord](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/data-model.md#log-and-event-record-definition) passed to the [Logger](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/bridge-api.md#logger) emit
|
||||
operations. Exceptions MAY be recorded on "logs" or "events" depending on the
|
||||
context.
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ the language runtime.
|
|||
## Attributes
|
||||
|
||||
The table below indicates which attributes should be added to the
|
||||
[LogRecord](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition) and their types.
|
||||
[LogRecord](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/data-model.md#log-and-event-record-definition) and their types.
|
||||
|
||||
<!-- semconv log-exception -->
|
||||
| Attribute | Type | Description | Examples | Requirement Level |
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
**Status**: [Experimental](../../document-status.md)
|
||||
|
||||
This document defines semantic conventions for recording feature flag evaluations as
|
||||
a [log record](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition) emitted through the
|
||||
[Logger API](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md#emit-a-logrecord).
|
||||
a [log record](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/data-model.md#log-and-event-record-definition) emitted through the
|
||||
[Logger API](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/bridge-api.md#emit-a-logrecord).
|
||||
This is useful when a flag is evaluated outside of a transaction context
|
||||
such as when the application loads or on a timer.
|
||||
To record a flag evaluation as a part of a transaction context,
|
||||
|
|
@ -24,14 +24,14 @@ section of the trace semantic convention for feature flag evaluations.
|
|||
## Recording an Evaluation
|
||||
|
||||
Feature flag evaluations SHOULD be recorded as attributes on the
|
||||
[LogRecord](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition) passed to the [Logger](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md#logger) emit
|
||||
[LogRecord](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/data-model.md#log-and-event-record-definition) passed to the [Logger](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/bridge-api.md#logger) emit
|
||||
operations. Evaluations MAY be recorded on "logs" or "events" depending on the
|
||||
context.
|
||||
|
||||
## Attributes
|
||||
|
||||
The table below indicates which attributes should be added to the
|
||||
[LogRecord](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#log-and-event-record-definition) and their types.
|
||||
[LogRecord](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/logs/data-model.md#log-and-event-record-definition) and their types.
|
||||
|
||||
<!-- semconv log-feature_flag -->
|
||||
The event name MUST be `feature_flag`.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ This document describes attributes for log media in OpenTelemetry. Log media are
|
|||
|
||||
## Log Media
|
||||
|
||||
**Note:** The OpenTelemetry specification defines a [Resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-sdk) as `an immutable representation of the entity producing telemetry`.
|
||||
**Note:** The OpenTelemetry specification defines a [Resource](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/resource/sdk.md#resource-sdk) as `an immutable representation of the entity producing telemetry`.
|
||||
The following attributes do not describe entities that produce telemetry. Rather, they describe mechanisms of log transmission.
|
||||
As such, these should be recorded as Log Record attributes when applicable. They should not be recorded as Resource attributes.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Metric Requirement Levels
|
||||
|
||||
This document is the same as [the specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/metric-requirement-level.md).
|
||||
This document is the same as [the specification](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/metrics/metric-requirement-level.md).
|
||||
|
||||
**Status**: [Stable](../document-status.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ The following semantic conventions surrounding metrics are defined:
|
|||
|
||||
Apart from semantic conventions for metrics and
|
||||
[traces](../../trace/semantic_conventions/README.md), OpenTelemetry also
|
||||
defines the concept of overarching [Resources](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md) with
|
||||
defines the concept of overarching [Resources](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/resource/sdk.md) with
|
||||
their own [Resource Semantic
|
||||
Conventions](../../resource/semantic_conventions/README.md).
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ usable.
|
|||
|
||||
When building components that interoperate between OpenTelemetry and a system
|
||||
using the OpenMetrics exposition format, use the
|
||||
[OpenMetrics Guidelines](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md).
|
||||
[OpenMetrics Guidelines](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/compatibility/prometheus_and_openmetrics.md).
|
||||
|
||||
### Pluralization
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ operations. By adding HTTP attributes to metric events it allows for finely tune
|
|||
This metric is required.
|
||||
|
||||
This metric SHOULD be specified with
|
||||
[`ExplicitBucketBoundaries`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#instrument-advice)
|
||||
[`ExplicitBucketBoundaries`](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/metrics/api.md#instrument-advice)
|
||||
of `[ 0, 0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10 ]`.
|
||||
|
||||
<!-- semconv metric.http.server.duration(metric_table) -->
|
||||
|
|
@ -242,7 +242,7 @@ SHOULD NOT be set if only IP address is available and capturing name would requi
|
|||
This metric is required.
|
||||
|
||||
This metric SHOULD be specified with
|
||||
[`ExplicitBucketBoundaries`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#instrument-advice)
|
||||
[`ExplicitBucketBoundaries`](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/metrics/api.md#instrument-advice)
|
||||
of `[ 0, 0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10 ]`.
|
||||
|
||||
<!-- semconv metric.http.client.duration(metric_table) -->
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ This metric is obtained by subscribing to
|
|||
[`GarbageCollectionNotificationInfo`](https://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/GarbageCollectionNotificationInfo.html) events provided by [`GarbageCollectorMXBean`](https://docs.oracle.com/javase/8/docs/api/java/lang/management/GarbageCollectorMXBean.html). The duration value is obtained from [`GcInfo`](https://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/GcInfo.html#getDuration--)
|
||||
|
||||
This metric SHOULD be specified with
|
||||
[`ExplicitBucketBoundaries`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#instrument-advice)
|
||||
[`ExplicitBucketBoundaries`](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/metrics/api.md#instrument-advice)
|
||||
of `[]` (single bucket histogram capturing count, sum, min, max).
|
||||
|
||||
<!-- semconv metric.process.runtime.jvm.gc.duration(metric_table) -->
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
**Status**: [Mixed](../../document-status.md)
|
||||
|
||||
This document defines standard attributes for resources. These attributes are typically used in the [Resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md) and are also recommended to be used anywhere else where there is a need to describe a resource in a consistent manner. The majority of these attributes are inherited from
|
||||
This document defines standard attributes for resources. These attributes are typically used in the [Resource](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/resource/sdk.md) and are also recommended to be used anywhere else where there is a need to describe a resource in a consistent manner. The majority of these attributes are inherited from
|
||||
[OpenCensus Resource standard](https://github.com/census-instrumentation/opencensus-specs/blob/master/resource/StandardResources.md).
|
||||
|
||||
<!-- Re-generate TOC with `markdown-toc --no-first-h1 -i` -->
|
||||
|
|
@ -40,7 +40,7 @@ This document defines standard attributes for resources. These attributes are ty
|
|||
|
||||
Attributes are grouped logically by the type of the concept that they described. Attributes in the same group have a common prefix that ends with a dot. For example all attributes that describe Kubernetes properties start with "k8s."
|
||||
|
||||
See [Attribute Requirement Levels](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/attribute-requirement-level.md) for details on when attributes
|
||||
See [Attribute Requirement Levels](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/common/attribute-requirement-level.md) for details on when attributes
|
||||
should be included.
|
||||
|
||||
## Attributes with Special Handling
|
||||
|
|
@ -52,14 +52,14 @@ Given their significance some resource attributes are treated specifically as de
|
|||
### Semantic Attributes with Dedicated Environment Variable
|
||||
|
||||
These are the attributes which MAY be configurable via a dedicated environment variable
|
||||
as specified in [OpenTelemetry Environment Variable Specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md):
|
||||
as specified in [OpenTelemetry Environment Variable Specification](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/configuration/sdk-environment-variables.md):
|
||||
|
||||
- [`service.name`](#service)
|
||||
|
||||
## Semantic Attributes with SDK-provided Default Value
|
||||
|
||||
These are the attributes which MUST be provided by the SDK
|
||||
as specified in the [Resource SDK specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#sdk-provided-resource-attributes):
|
||||
as specified in the [Resource SDK specification](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/resource/sdk.md#sdk-provided-resource-attributes):
|
||||
|
||||
- [`service.name`](#service)
|
||||
- [`telemetry.sdk` group](#telemetry-sdk)
|
||||
|
|
|
|||
|
|
@ -31,8 +31,8 @@ The following library-specific semantic conventions are defined:
|
|||
* [AWS SDK](instrumentation/aws-sdk.md): For AWS SDK spans.
|
||||
* [GraphQL](instrumentation/graphql.md): For GraphQL spans.
|
||||
|
||||
Apart from semantic conventions for traces and [metrics](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/README.md),
|
||||
OpenTelemetry also defines the concept of overarching [Resources](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md) with their own
|
||||
Apart from semantic conventions for traces and [metrics](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/metrics/semantic_conventions/README.md),
|
||||
OpenTelemetry also defines the concept of overarching [Resources](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/resource/sdk.md) with their own
|
||||
[Resource Semantic Conventions](../../resource/semantic_conventions/README.md).
|
||||
|
||||
## Event Name Reuse Prohibition
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ An exception SHOULD be recorded as an `Event` on the span during which it occurr
|
|||
The name of the event MUST be `"exception"`.
|
||||
|
||||
A typical template for an auto-instrumentation implementing this semantic convention
|
||||
using an [API-provided `recordException` method](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#record-exception)
|
||||
using an [API-provided `recordException` method](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#record-exception)
|
||||
could look like this (pseudo-Java):
|
||||
|
||||
```java
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ and various HTTP versions like 1.1, 2 and SPDY.
|
|||
|
||||
## Name
|
||||
|
||||
HTTP spans MUST follow the overall [guidelines for span names](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#span).
|
||||
HTTP spans MUST follow the overall [guidelines for span names](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#span).
|
||||
HTTP server span names SHOULD be `{http.request.method} {http.route}` if there is a
|
||||
(low-cardinality) `http.route` available.
|
||||
HTTP server span names SHOULD be `{http.request.method}` if there is no (low-cardinality)
|
||||
|
|
@ -67,7 +67,7 @@ default span name.
|
|||
|
||||
## Status
|
||||
|
||||
[Span Status](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status) MUST be left unset if HTTP status code was in the
|
||||
[Span Status](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#set-status) MUST be left unset if HTTP status code was in the
|
||||
1xx, 2xx or 3xx ranges, unless there was another error (e.g., network error receiving
|
||||
the response body; or 3xx codes with max redirects exceeded), in which case status
|
||||
MUST be set to `Error`.
|
||||
|
|
|
|||
|
|
@ -57,9 +57,9 @@ and the [cloud resource conventions][cloud]. The following AWS Lambda-specific a
|
|||
### AWS X-Ray Environment Span Link
|
||||
|
||||
If the `_X_AMZN_TRACE_ID` environment variable is set, instrumentation SHOULD try to parse an
|
||||
OpenTelemetry `Context` out of it using the [AWS X-Ray Propagator](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/context/api-propagators.md). If the
|
||||
resulting `Context` is [valid](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#isvalid) then a [Span Link][] SHOULD be added to the new Span's
|
||||
[start options](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#specifying-links) with an associated attribute of `source=x-ray-env` to
|
||||
OpenTelemetry `Context` out of it using the [AWS X-Ray Propagator](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/context/api-propagators.md). If the
|
||||
resulting `Context` is [valid](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#isvalid) then a [Span Link][] SHOULD be added to the new Span's
|
||||
[start options](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#specifying-links) with an associated attribute of `source=x-ray-env` to
|
||||
indicate the source of the linked span.
|
||||
Instrumentation MUST check if the context is valid before using it because the `_X_AMZN_TRACE_ID` environment variable can
|
||||
contain an incomplete trace context which indicates X-Ray isn’t enabled. The environment variable will be set and the
|
||||
|
|
@ -107,7 +107,7 @@ be `<event source> process`. If there are multiple sources in the batch, the nam
|
|||
|
||||
For every message in the event, the [message system attributes][] (not message attributes, which are provided by
|
||||
the user) SHOULD be checked for the key `AWSTraceHeader`. If it is present, an OpenTelemetry `Context` SHOULD be
|
||||
parsed from the value of the attribute using the [AWS X-Ray Propagator](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/context/api-propagators.md) and
|
||||
parsed from the value of the attribute using the [AWS X-Ray Propagator](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/context/api-propagators.md) and
|
||||
added as a link to the span. This means the span may have as many links as messages in the batch.
|
||||
See [compatibility](../../../../supplementary-guidelines/compatibility/aws.md#context-propagation) for more info.
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ See [compatibility](../../../../supplementary-guidelines/compatibility/aws.md#co
|
|||
For the SQS message span, the name MUST be `<event source> process`. The parent MUST be the `CONSUMER` span
|
||||
corresponding to the SQS event. The [message system attributes][] (not message attributes, which are provided by
|
||||
the user) SHOULD be checked for the key `AWSTraceHeader`. If it is present, an OpenTelemetry `Context` SHOULD be
|
||||
parsed from the value of the attribute using the [AWS X-Ray Propagator](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/context/api-propagators.md) and
|
||||
parsed from the value of the attribute using the [AWS X-Ray Propagator](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/context/api-propagators.md) and
|
||||
added as a link to the span.
|
||||
See [compatibility](../../../../supplementary-guidelines/compatibility/aws.md#context-propagation) for more info.
|
||||
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ The span name SHOULD be set to the message destination name and the operation be
|
|||
<destination name> <operation name>
|
||||
```
|
||||
|
||||
The destination name SHOULD only be used for the span name if it is known to be of low cardinality (cf. [general span name guidelines](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#span)).
|
||||
The destination name SHOULD only be used for the span name if it is known to be of low cardinality (cf. [general span name guidelines](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#span)).
|
||||
This can be assumed if it is statically derived from application code or configuration.
|
||||
Wherever possible, the real destination names after resolving logical or aliased names SHOULD be used.
|
||||
If the destination name is dynamic, such as a [conversation ID](#conversations) or a value obtained from a `Reply-To` header, it SHOULD NOT be used for the span name.
|
||||
|
|
@ -544,7 +544,7 @@ Process C: | Span Recv1 |
|
|||
|
||||
Given is a process P, that publishes two messages to a queue Q on messaging system MS, and a process C, which receives them separately in two different operations (Span Recv1 and Recv2) and processes both messages in one batch (Span Proc1).
|
||||
|
||||
Since each span can only have one parent, C3 should not choose a random parent out of C1 and C2, but rather rely on the implicitly selected parent as defined by the [tracing API spec](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md).
|
||||
Since each span can only have one parent, C3 should not choose a random parent out of C1 and C2, but rather rely on the implicitly selected parent as defined by the [tracing API spec](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md).
|
||||
Depending on the implementation, the producing spans might still be available in the meta data of the messages and should be added to C3 as links.
|
||||
The client library or application could also add the receiver span's SpanContext to the data structure it returns for each message. In this case, C3 could also add links to the receiver spans C1 and C2.
|
||||
|
||||
|
|
|
|||
|
|
@ -241,10 +241,10 @@ For remote procedure calls via [gRPC][], additional conventions are described in
|
|||
### gRPC Status
|
||||
|
||||
The table below describes when
|
||||
the [Span Status](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status) MUST be set
|
||||
the [Span Status](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#set-status) MUST be set
|
||||
to `Error` or remain unset
|
||||
depending on the [gRPC status code](https://github.com/grpc/grpc/blob/v1.33.2/doc/statuscodes.md)
|
||||
and [Span Kind](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#spankind).
|
||||
and [Span Kind](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#spankind).
|
||||
|
||||
| gRPC Status Code | `SpanKind.SERVER` Span Status | `SpanKind.CLIENT` Span Status |
|
||||
|---|---|---|
|
||||
|
|
@ -317,7 +317,7 @@ Below is a table of attributes that SHOULD be included on client and server RPC
|
|||
|
||||
### Connect RPC Status
|
||||
|
||||
If `rpc.connect_rpc.error_code` is set, [Span Status](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status) MUST be set to `Error` and left unset in all other cases.
|
||||
If `rpc.connect_rpc.error_code` is set, [Span Status](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.21.0/specification/trace/api.md#set-status) MUST be set to `Error` and left unset in all other cases.
|
||||
|
||||
### Connect RPC Request and Response Metadata
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue