Fix site links into updated spec pages (open-telemetry#3397)

Author: chalin

.htmltest.yml

@@ -11,10 +11,6 @@ IgnoreURLs: # list of regexs of paths or URLs to be ignored
   - ^/community/end-user/feedback-survey/$
   - ^(/docs/migration/)?opencensus/$
 
-  # TODO(@chalin) remove once the website pages have caught up with latest semconv changes:
-  - ^/docs/specs/otel/\w+/semantic_conventions
-  - \#instrument-advice
-
   - ^https://deploy-preview-\d+--opentelemetry.netlify.app/
   - ^https://www\.googletagmanager\.com
 

content/en/blog/2022/debug-otel-with-otel/index.md

@@ -254,7 +254,7 @@ COPY opentelemetry_module.conf /etc/nginx/conf.d
   /blog/2022/instrument-nginx/#put-nginx-between-two-services
 [localhost:16686]: http://localhost:16686/
 [http request & response headers]:
-  /docs/specs/otel/trace/semantic_conventions/http/#http-request-and-response-headers
+  /docs/specs/semconv/http/http-spans/#common-attributes
 [rfc7230]: https://httpwg.org/specs/rfc7230.html#field.order
 [added some checks to the module for nginx]:
   https://github.com/open-telemetry/opentelemetry-cpp-contrib/pull/204

content/en/blog/2022/instrument-kafka-clients/index.md

@@ -23,7 +23,7 @@ difficult to track how messages are moved around. This is where OpenTelemetry
 comes into the picture. It provides multiple instrumentation libraries for
 adding tracing to messaging based applications. Of course, there is one for
 Apache Kafka clients. It also defines the specification of semantic conventions
-for [messaging systems](/docs/specs/otel/trace/semantic_conventions/messaging/).
+for [messaging systems](/docs/specs/semconv/messaging/messaging-spans/).
 
 But usually, the architecture can even be more complicated: having applications
 not able to connect directly to the Apache Kafka cluster and talking its own

content/en/blog/2022/k8s-metadata/index.md

@@ -248,14 +248,13 @@ sidecar, or when one collector as an agent report to another collector.
 
 - [K8sattributes processor documentation][k8sattributesprocessor]
 - [K8sattributes processor RBAC](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/processor/k8sattributesprocessor#hdr-RBAC)
-- [OpenTelemetry Kubernetes attributes](/docs/specs/otel/resource/semantic_conventions/k8s)
+- [OpenTelemetry Kubernetes attributes](/docs/specs/semconv/resource/k8s)
 - [Resource detector processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md)
 
 [pr#832]: https://github.com/open-telemetry/opentelemetry-operator/pull/832
 [opentelemetry operator]:
   https://github.com/open-telemetry/opentelemetry-operator
 [k8sattributesprocessor]:
   https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/processor/k8sattributesprocessor
-[kubernetes resource semantic conventions]:
-  /docs/specs/otel/resource/semantic_conventions/k8s
+[kubernetes resource semantic conventions]: /docs/specs/semconv/resource/k8s
 [vert.x example app]: https://github.com/jaegertracing/vertx-create-span

content/en/blog/2022/knative/index.md

@@ -162,7 +162,7 @@ might not have an immediate impact on the user, however, it will enable users to
 start natively reporting data in OpenTelemetry format (OTLP).
 
 Another recently merged change is the addition of
-[Cloudevents semantic attributes into the OpenTelemetry specification](/docs/specs/otel/trace/semantic_conventions/cloudevents).
+[Cloudevents semantic attributes into the OpenTelemetry specification](/docs/specs/semconv/cloudevents/cloudevents-spans/).
 The document standardizes attributes related to CloudEvents. The screenshot
 below is from the demo application that is still not using the standardized
 attribute names:
@@ -210,5 +210,5 @@ instrumentation libraries explicitly in the code or even
 - [Zipkin B3](https://github.com/openzipkin/b3-propagation)
 - [W3C Trace-Context](https://www.w3.org/TR/trace-context/)
 - [OpenTelemetry instrumentation for Cloudevents Golang SDK](https://github.com/cloudevents/sdk-go/tree/main/observability/opentelemetry/v2)
-- [Cloudevents OpenTelemetry attributes](/docs/specs/otel/trace/semantic_conventions/cloudevents/)
+- [Cloudevents OpenTelemetry attributes](/docs/specs/semconv/cloudevents/cloudevents-spans/)
 - [Knative tracing demo](https://github.com/pavolloffay/knative-tracing)

content/en/blog/2023/http-conventions-stability.md

@@ -7,9 +7,8 @@ cSpell:ignore: stalnaker trask
 ---
 
 The OpenTelemetry community is beginning the final push to declare HTTP
-[tracing](/docs/specs/otel/trace/semantic_conventions/http/) and
-[metrics](/docs/specs/otel/metrics/semantic_conventions/http-metrics/) semantic
-conventions stable!
+[tracing](/docs/specs/semconv/http/http-spans/) and
+[metrics](/docs/specs/semconv/http/http-metrics/) semantic conventions stable!
 
 Following the recently proposed
 [Semantic Convention Process](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE),

content/en/docs/collector/trace-receiver.md

@@ -1467,7 +1467,7 @@ minimize the conflicts across all the different types of telemetry generation
 entities that it may need to represent.
 
 These guidelines are known as Resource Semantic Conventions and are
-[documented in the OTel specification](/docs/specs/otel/resource/semantic_conventions/).
+[documented in the OTel specification](/docs/specs/semconv/resource/).
 
 When creating your own attributes to represent your own telemetry generation
 entities, you should follow the guideline provided by the specification:
@@ -1509,15 +1509,14 @@ func fillResourceWithAtm(resource *pcommon.Resource, atm Atm){
 The resource semantic conventions also have prescriptive attribute names and
 well-known values to represent telemetry generation entities that are common and
 applicable across different domains like
-[compute unit](/docs/specs/otel/resource/semantic_conventions/#compute-unit),
-[environment](/docs/specs/otel/resource/semantic_conventions/#compute-unit) and
-others.
+[compute unit](/docs/specs/semconv/resource/#compute-unit),
+[environment](/docs/specs/semconv/resource/#compute-unit) and others.
 
 So, when you look at the `BackendSystem` entity, it has fields representing
-[OS](/docs/specs/otel/resource/semantic_conventions/os/) related information and
-[Cloud](/docs/specs/otel/resource/semantic_conventions/cloud/) related
-information, and we will use the attribute names and values prescribed by the
-resource semantic convention to represent that information on its `Resource`.
+[OS](/docs/specs/semconv/resource/os/) related information and
+[Cloud](/docs/specs/semconv/resource/cloud/) related information, and we will
+use the attribute names and values prescribed by the resource semantic
+convention to represent that information on its `Resource`.
 
 All the resource semantic convention attribute names and well known-values are
 kept within the

content/en/docs/collector/transforming-telemetry.md

@@ -82,9 +82,9 @@ processors:
 ```
 
 The resource processor has an identical configuration, but applies only to
-[resource attributes](/docs/specs/otel/resource/semantic_conventions/). Use the
-resource processor to modify infrastructure metadata related to telemetry. For
-example, this inserts the Kubernetes cluster name:
+[resource attributes](/docs/specs/semconv/resource/). Use the resource processor
+to modify infrastructure metadata related to telemetry. For example, this
+inserts the Kubernetes cluster name:
 
 ```yaml
 processors:

content/en/docs/concepts/glossary.md

@@ -356,11 +356,11 @@ on web pages when requested. See [more][zpages].
 
 ### Semantic Conventions
 
-#### **[Resource Conventions](/docs/specs/otel/resource/semantic_conventions)**
+#### **[Resource Conventions](/docs/specs/semconv/resource/)**
 
-#### **[Span Conventions](/docs/specs/otel/trace/semantic_conventions)**
+#### **[Span Conventions](/docs/specs/semconv/general/trace/)**
 
-#### **[Metric Conventions](/docs/specs/otel/metrics/semantic_conventions)**
+#### **[Metric Conventions](/docs/specs/semconv/general/metrics/)**
 
 [baggage]: /docs/specs/otel/baggage/api/
 [attribute]: /docs/specs/otel/common/#attributes

content/en/docs/concepts/instrumentation/libraries.md

@@ -24,10 +24,9 @@ and document hooks:
 
 ## Semantic Conventions
 
-Check out available
-[semantic conventions](/docs/specs/otel/trace/semantic_conventions/) that cover
-web-frameworks, RPC clients, databases, messaging clients, infra pieces and
-more!
+Check out available [semantic conventions](/docs/specs/semconv/general/trace/)
+that cover web-frameworks, RPC clients, databases, messaging clients, infra
+pieces and more!
 
 If your library is one of those things - follow the conventions, they are the
 main source of truth and tell which information should be included on spans.
@@ -199,8 +198,7 @@ private Response selectWithTracing(Query query) {
 ```
 
 Follow conventions to populate attributes! If there is no applicable one, check
-out
-[general conventions](/docs/specs/otel/trace/semantic_conventions/span-general/).
+out [general conventions](/docs/specs/semconv/general/attributes/).
 
 ### Nested network and other spans
 
@@ -298,8 +296,8 @@ In the case of a messaging system, you may receive more than one message at
 once. Received messages become
 [_links_](/docs/instrumentation/java/manual/#create-spans-with-links) on the
 span you create. Refer to
-[messaging conventions](/docs/specs/otel/trace/semantic_conventions/messaging/)
-for details (WARNING: messaging conventions are
+[messaging conventions](/docs/specs/semconv/messaging/messaging-spans/) for
+details (WARNING: messaging conventions are
 [under constructions](https://github.com/open-telemetry/oteps/pull/173) 🚧).
 
 ### Injecting context

content/en/docs/concepts/sdk-configuration/general-sdk-configuration.md

@@ -8,8 +8,7 @@ cSpell:ignore: ottrace
 
 ## `OTEL_SERVICE_NAME`
 
-Sets the value of the
-[`service.name`](/docs/specs/otel/resource/semantic_conventions/#service)
+Sets the value of the [`service.name`](/docs/specs/semconv/resource/#service)
 resource attribute.
 
 **Default value:** `"unknown_service"`
@@ -30,7 +29,7 @@ for more details.
 **Default value:** Empty.
 
 See
-[Resource semantic conventions](/docs/specs/otel/resource/semantic_conventions/#semantic-attributes-with-sdk-provided-default-value)
+[Resource semantic conventions](/docs/specs/semconv/resource/#semantic-attributes-with-sdk-provided-default-value)
 for semantic conventions to follow for common resource types.
 
 **Example:**

content/en/docs/concepts/semantic-conventions.md

@@ -4,13 +4,14 @@ description: Common names for different kinds of operations and data.
 weight: 30
 ---
 
-OpenTelemetry defines Semantic Conventions (sometimes called Semantic
-Attributes) that specify common names for different kinds of operations and
-data. The benefit to using Semantic Conventions is in following a common naming
-scheme that can be standardized across a codebase, libraries, and platforms.
+OpenTelemetry defines [Semantic Conventions](/docs/specs/semconv/) (sometimes
+called Semantic Attributes) that specify common names for different kinds of
+operations and data. The benefit to using Semantic Conventions is in following a
+common naming scheme that can be standardized across a codebase, libraries, and
+platforms.
 
 Currently, Semantic Conventions are available for traces, metrics and resources:
 
-- [Trace Semantic Conventions](/docs/specs/otel/trace/semantic_conventions/)
-- [Metric Semantic Conventions](/docs/specs/otel/metrics/semantic_conventions/)
-- [Resource Semantic Conventions](/docs/specs/otel/resource/semantic_conventions/)
+- [Trace Semantic Conventions](/docs/specs/semconv/general/trace/)
+- [Metric Semantic Conventions](/docs/specs/semconv/general/metrics/)
+- [Resource Semantic Conventions](/docs/specs/semconv/resource/)

content/en/docs/concepts/signals/metrics.md

@@ -49,8 +49,8 @@ instrument is defined by:
 - Description (optional)
 
 The name, unit, and description are chosen by the developer or defined via
-[semantic conventions](/docs/specs/otel/metrics/semantic_conventions/) for
-common ones like request and process metrics.
+[semantic conventions](/docs/specs/semconv/general/metrics/) for common ones
+like request and process metrics.
 
 The instrument kind is one of the following:
 

content/en/docs/concepts/signals/traces.md

@@ -268,10 +268,10 @@ Attributes have the following rules that each language SDK implements:
   an array of these values
 
 Additionally, there are
-[Semantic Attributes](/docs/specs/otel/trace/semantic_conventions/), which are
-known naming conventions for metadata that is typically present in common
-operations. It's helpful to use semantic attribute naming wherever possible so
-that common kinds of metadata are standardized across systems.
+[Semantic Attributes](/docs/specs/semconv/general/trace/), which are known
+naming conventions for metadata that is typically present in common operations.
+It's helpful to use semantic attribute naming wherever possible so that common
+kinds of metadata are standardized across systems.
 
 ### Span Events
 

content/en/docs/demo/services/ad.md

@@ -119,8 +119,8 @@ The following custom metrics are currently available:
 
 The following auto-instrumented metrics are available for the application:
 
-- [Runtime metrics for the JVM](/docs/specs/otel/metrics/semantic_conventions/runtime-environment-metrics/#jvm-metrics).
-- [Latency metrics for RPCs](/docs/specs/otel/metrics/semantic_conventions/rpc-metrics/#rpc-server)
+- [Runtime metrics for the JVM](/docs/specs/semconv/runtime/jvm-metrics/).
+- [Latency metrics for RPCs](/docs/specs/semconv/rpc/rpc-metrics/#rpc-server)
 
 ## Logs
 

content/en/docs/instrumentation/erlang/resources.md

@@ -89,7 +89,6 @@ Custom resource detectors can be created by implementing the
 which contains a single callback `get_resource/1` that returns an
 [`otel_resource`](https://hexdocs.pm/opentelemetry/1.3.0/otel_resource.html).
 
-Note that there are
-[semantic conventions](/docs/specs/otel/resource/semantic_conventions/) defined
-for `resource` that should be followed if they apply when adding new resource
-attributes.
+Note that there are [semantic conventions](/docs/specs/semconv/resource/)
+defined for `resource` that should be followed if they apply when adding new
+resource attributes.

content/en/docs/instrumentation/go/manual.md

@@ -890,7 +890,7 @@ You’ll also want to configure an appropriate exporter to
 telemetry backends.
 
 [opentelemetry specification]: /docs/specs/otel/
-[trace semantic conventions]: /docs/specs/otel/trace/semantic_conventions/
+[trace semantic conventions]: /docs/specs/semconv/general/trace/
 [instrumentation library]: ../libraries/
 [`go.opentelemetry.io/otel`]: https://pkg.go.dev/go.opentelemetry.io/otel
 [`go.opentelemetry.io/otel/exporters/stdout/stdoutmetric`]:

content/en/docs/instrumentation/java/automatic/agent-config.md

@@ -107,10 +107,9 @@ Common settings that apply to multiple instrumentations at once.
 ### Peer service name
 
 The
-[peer service name](/docs/specs/otel/trace/semantic_conventions/span-general/#general-remote-service-attributes)
+[peer service name](/docs/specs/semconv/general/attributes/#general-remote-service-attributes)
 is the name of a remote service to which a connection is made. It corresponds to
-`service.name` in the
-[resource](/docs/specs/otel/resource/semantic_conventions/#service) for the
+`service.name` in the [resource](/docs/specs/semconv/resource/#service) for the
 local service.
 
 {{% config_option name="otel.instrumentation.common.peer-service-mapping" %}}
@@ -159,7 +158,7 @@ following property to disable it:
 
 You can configure the agent to capture predefined HTTP headers as span
 attributes, according to the
-[semantic convention](/docs/specs/otel/trace/semantic_conventions/http/#http-request-and-response-headers).
+[semantic convention](/docs/specs/semconv/http/http-spans/#common-attributes).
 Use the following properties to define which HTTP headers you want to capture:
 
 {{% config_option name="otel.instrumentation.http.client.capture-request-headers" %}}

content/en/docs/instrumentation/java/manual.md

@@ -837,7 +837,7 @@ span.setAttribute("http.url", url.toString());
 There are semantic conventions for spans representing operations in well-known
 protocols like HTTP or database calls. Semantic conventions for these spans are
 defined in the specification at
-[Trace Semantic Conventions](/docs/specs/otel/trace/semantic_conventions/).
+[Trace Semantic Conventions](/docs/specs/semconv/general/trace/).
 
 First add the semantic conventions as a dependency to your application:
 

content/en/docs/instrumentation/java/resources.md

@@ -17,11 +17,10 @@ resource detection below.
 ## Detecting resources from common environments
 
 You can use `ResourceProvider`s for filling in attributes related to common
-environments, like
-[Container](/docs/specs/otel/resource/semantic_conventions/container/),
-[Host](/docs/specs/otel/resource/semantic_conventions/host/) or
-[Operating System](/docs/specs/otel/resource/semantic_conventions/os/). These
-can be used with or without
+environments, like [Container](/docs/specs/semconv/resource/container/),
+[Host](/docs/specs/semconv/resource/host/) or
+[Operating System](/docs/specs/semconv/resource/os/). These can be used with or
+without
 [auto-configuration](/docs/instrumentation/java/manual/#automatic-configuration).
 
 To use those providers, add the following dependency:

content/en/docs/instrumentation/js/manual.md

@@ -920,8 +920,8 @@ function rollTheDice(rolls, min, max) {
 There are semantic conventions for spans representing operations in well-known
 protocols like HTTP or database calls. Semantic conventions for these spans are
 defined in the specification at
-[Trace Semantic Conventions](/docs/specs/otel/trace/semantic_conventions/). In
-the simple example of this guide the source code attributes can be used.
+[Trace Semantic Conventions](/docs/specs/semconv/general/trace/). In the simple
+example of this guide the source code attributes can be used.
 
 First add the semantic conventions as a dependency to your application:
 

content/en/docs/instrumentation/js/resources.md

@@ -254,11 +254,9 @@ list
 [here](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/detectors/node).
 
 [getting started - node.js]: /docs/instrumentation/js/getting-started/nodejs/
-[process and process runtime resources]:
-  /docs/specs/otel/resource/semantic_conventions/process/
-[host]: /docs/specs/otel/resource/semantic_conventions/host/
-[cloud]: /docs/specs/otel/resource/semantic_conventions/cloud/
-[deployment]:
-  /docs/specs/otel/resource/semantic_conventions/deployment_environment/
-[service]: /docs/specs/otel/resource/semantic_conventions/#service
-[os]: /docs/specs/otel/resource/semantic_conventions/os/
+[process and process runtime resources]: /docs/specs/semconv/resource/process/
+[host]: /docs/specs/semconv/resource/host/
+[cloud]: /docs/specs/semconv/resource/cloud/
+[deployment]: /docs/specs/semconv/resource/deployment-environment/
+[service]: /docs/specs/semconv/resource/#service
+[os]: /docs/specs/semconv/resource/os/