From dd24b7bf6831c3dff0296376cf392f12c34a33cd Mon Sep 17 00:00:00 2001 From: Martin Kuba Date: Tue, 3 Oct 2023 15:32:08 -0700 Subject: [PATCH] update broken links --- doc/metrics.md | 4 ++-- doc/tracing.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/metrics.md b/doc/metrics.md index e2f2b5a1472..314fcbaf391 100644 --- a/doc/metrics.md +++ b/doc/metrics.md @@ -286,7 +286,7 @@ await myTask() ## Describing a instrument measurement -Using attributes, kind, and the related [semantic conventions](https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/metrics/semantic_conventions), we can more accurately describe the measurement in a way our metrics backend will more easily understand. The following example uses these mechanisms, which are described below, for recording a measurement +Using attributes, kind, and the related [semantic conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/metrics.md), we can more accurately describe the measurement in a way our metrics backend will more easily understand. The following example uses these mechanisms, which are described below, for recording a measurement of a HTTP request. Each metric instruments allows to associate a description, unit of measure, and the value type. @@ -343,7 +343,7 @@ One problem with metrics names and attributes is recognizing, categorizing, and The use of semantic conventions is always recommended where applicable, but they are merely conventions. For example, you may find that some name other than the name suggested by the semantic conventions more accurately describes your metric, you may decide not to include a metric attribute which is suggested by semantic conventions for privacy reasons, or you may wish to add a custom attribute which isn't covered by semantic conventions. All of these cases are fine, but please keep in mind that if you stray from the semantic conventions, the categorization of metrics in your metrics backend may be affected. -_See the current metrics semantic conventions in the OpenTelemetry Specification repository: _ +_See the current metrics semantic conventions in the OpenTelemetry Specification repository: _ [spec-overview]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md diff --git a/doc/tracing.md b/doc/tracing.md index fb3371d4fa5..77787549bcf 100644 --- a/doc/tracing.md +++ b/doc/tracing.md @@ -76,7 +76,7 @@ server.on("GET", "/user/:id", onGet); ## Describing a Span -Using span relationships, attributes, kind, and the related [semantic conventions](https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/trace/semantic_conventions), we can more accurately describe the span in a way our tracing backend will more easily understand. The following example uses these mechanisms, which are described below. +Using span relationships, attributes, kind, and the related [semantic conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/trace.md), we can more accurately describe the span in a way our tracing backend will more easily understand. The following example uses these mechanisms, which are described below. ```typescript import { NetTransportValues, SemanticAttributes } from '@opentelemetry/semantic-conventions'; @@ -209,6 +209,6 @@ Consumer spans represent the processing of a job created by a producer and may s One problem with span names and attributes is recognizing, categorizing, and analyzing them in your tracing backend. Between different applications, libraries, and tracing backends there might be different names and expected values for various attributes. For example, your application may use `http.status` to describe the HTTP status code, but a library you use may use `http.status_code`. In order to solve this problem, OpenTelemetry uses a library of semantic conventions which describe the name and attributes which should be used for specific types of spans. The use of semantic conventions is always recommended where applicable, but they are merely conventions. For example, you may find that some name other than the name suggested by the semantic conventions more accurately describes your span, you may decide not to include a span attribute which is suggested by semantic conventions for privacy reasons, or you may wish to add a custom attribute which isn't covered by semantic conventions. All of these cases are fine, but please keep in mind that if you stray from the semantic conventions, the categorization of spans in your tracing backend may be affected. -_See the current trace semantic conventions in the OpenTelemetry Specification repository: _ +_See the current trace semantic conventions in the OpenTelemetry Specification repository: _ [spec-overview]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md