Merge branch 'main' into nsb

Author: irinascurtu

.gitmodules

@@ -20,7 +20,7 @@
 [submodule "content-modules/semantic-conventions"]
 	path = content-modules/semantic-conventions
 	url = https://github.com/open-telemetry/semantic-conventions
-	semconv-pin = v1.30.0
+	semconv-pin = v1.31.0
 [submodule "content-modules/opamp-spec"]
 	path = content-modules/opamp-spec
 	url = https://github.com/open-telemetry/opamp-spec

content-modules/semantic-conventions

@@ -255,5 +255,5 @@ transparent and effective AI ecosystem.
 
 Don’t miss this opportunity to help shape the future of industry standards for
 GenAI Observability! Join us on the [CNCF Slack](https://slack.cncf.io)
-`#otel-genai-instrumentation-wg` channel, or by attending a
+`#otel-genai-instrumentation` channel, or by attending a
 [GenAI SIG meeting](https://github.com/open-telemetry/community/blob/main/projects/gen-ai.md#meeting-times).

content/en/blog/2025/ai-agent-observability/index.md

@@ -5,16 +5,15 @@ aliases: [instrumenting]
 weight: 15
 ---
 
-In order to make a system observable, it must be **instrumented**: That is, code
-from the system's components must emit [traces](/docs/concepts/signals/traces/),
-[metrics](/docs/concepts/signals/metrics/), and
-[logs](/docs/concepts/signals/logs/).
+For a system to be [observable], it must be **instrumented**: that is, code from
+the system's components must emit [signals], such as [traces], [metrics], and
+[logs].
 
 Using OpenTelemetry, you can instrument your code in two primary ways:
 
-1. [Code-based solutions](/docs/concepts/instrumentation/code-based) via
-   official [APIs and SDKs for most languages](/docs/languages/)
-2. [Zero-code solutions](/docs/concepts/instrumentation/zero-code/)
+1. [Code-based solutions](code-based/) via official
+   [APIs and SDKs for most languages](/docs/languages/)
+2. [Zero-code solutions](zero-code/)
 
 **Code-based** solutions allow you to get deeper insight and rich telemetry from
 your application itself. They let you use the OpenTelemetry API to generate
@@ -37,20 +36,24 @@ solutions. The following things are also a part of OpenTelemetry:
 - Libraries can leverage the OpenTelemetry API as a dependency, which will have
   no impact on applications using that library, unless the OpenTelemetry SDK is
   imported.
-- For each [signal](/docs/concepts/signals) (traces, metrics, logs) you have
-  several methods at your disposals to create, process, and export them.
-- With [context propagation](/docs/concepts/context-propagation) built into the
+- For each of the [signals] you have several methods at your disposal to create,
+  process, and export them.
+- With [context propagation](../context-propagation/) built into the
   implementations, you can correlate signals regardless of where they are
   generated.
-- [Resources](/docs/concepts/resources) and
-  [Instrumentation Scopes](/docs/concepts/instrumentation-scope) allow grouping
-  of signals, by different entities, like, the
-  [host](/docs/specs/semconv/resource/host/),
+- [Resources](../resources/) and
+  [Instrumentation Scopes](../instrumentation-scope/) allow grouping of signals,
+  by different entities, like, the [host](/docs/specs/semconv/resource/host/),
   [operating system](/docs/specs/semconv/resource/os/) or
   [K8s cluster](/docs/specs/semconv/resource/k8s/#cluster)
 - Each language-specific implementation of the API and SDK follows the
   requirements and expectations of the
   [OpenTelemetry specification](/docs/specs/otel/).
-- [Semantic Conventions](/docs/concepts/semantic-conventions) provide a common
-  naming schema that can be used for standardization across code bases and
-  platforms.
+- [Semantic Conventions](../semantic-conventions/) provide a common naming
+  schema that can be used for standardization across code bases and platforms.
+
+[logs]: ../signals/traces/
+[metrics]: ../signals/traces/
+[observable]: ../observability-primer/#what-is-observability
+[signals]: ../signals/
+[traces]: ../signals/traces/

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

@@ -43,8 +43,8 @@ more information.
 ## Style checks
 
 To make sure that contributions follow our [style guide](../style-guide/) we
-have implemented a set of checks that verify style guide rules and fail l if
-they find any issues.
+have implemented a set of checks that verify style guide rules and fail if they
+find any issues.
 
 The following list describes current checks and what you can do to fix related
 errors:
@@ -64,7 +64,7 @@ issues. Run `npm run check:text` again and manually fix the remaining issues.
 This check verifies that
 [standards and consistency for Markdown files are enforced](../style-guide/#markdown-standards).
 
-If any issues are found, run `npm:run format` to fix most issues. For more
+If any issues are found, run `npm run:format` to fix most issues. For more
 complex issues, run `npm run check:markdown` and apply the suggested changes.
 
 ### SPELLING check

content/en/docs/contributing/pr-checks.md

@@ -0,0 +1,24 @@
+---
+---
+
+This is the OpenTelemetry {{ $name }} documentation. OpenTelemetry is an
+observability framework -- an API, SDK, and tools that are designed to aid in
+the generation and collection of application telemetry data such as metrics,
+logs, and traces. This documentation is designed to help you understand how to
+get started using OpenTelemetry {{ $name }}.
+
+## Status and Releases
+
+The current status of the major functional components for OpenTelemetry
+{{ $name }} is as follows:
+
+| Traces              | Metrics              | Logs              |
+| ------------------- | -------------------- | ----------------- |
+| {{ $tracesStatus }} | {{ $metricsStatus }} | {{ $logsStatus }} |
+
+For releases, including the [latest release][], see [Releases]. {{ $.Inner }}
+
+[latest release]:
+  <https://github.com/open-telemetry/opentelemetry-{{ $lang }}/releases/latest>
+[Releases]:
+  <https://github.com/open-telemetry/opentelemetry-{{ $lang }}/releases>

content/en/docs/languages/_includes/index-intro.md

@@ -7,7 +7,7 @@ aliases: [/java, /java/metrics, /java/tracing]
 cascade:
   vers:
     instrumentation: 2.13.3
-    otel: 1.47.0
+    otel: 1.48.0
     contrib: 1.44.0
     semconv: 1.30.0
 weight: 18

content/en/docs/languages/java/_index.md

@@ -1,50 +1,48 @@
 ---
 title: What is OpenTelemetry?
-description: A short explanation of what OpenTelemetry is and isn't.
+description: A brief explanation of what OpenTelemetry is and isn't.
 aliases: [/about, /docs/concepts/what-is-opentelemetry, /otel]
 weight: 150
 ---
 
 OpenTelemetry is:
 
-- An [Observability](/docs/concepts/observability-primer/#what-is-observability)
-  framework and toolkit designed to create and manage telemetry data such as
-  [traces](/docs/concepts/signals/traces/),
-  [metrics](/docs/concepts/signals/metrics/), and
-  [logs](/docs/concepts/signals/logs/).
-- Vendor- and tool-agnostic, meaning that it can be used with a broad variety of
-  Observability backends, including open source tools like
-  [Jaeger](https://www.jaegertracing.io/) and
-  [Prometheus](https://prometheus.io/), as well as commercial offerings.
-- Not an observability backend like Jaeger, Prometheus, or other commercial
-  vendors.
-- Focused on the generation, collection, management, and export of telemetry. A
-  major goal of OpenTelemetry is that you can easily instrument your
-  applications or systems, no matter their language, infrastructure, or runtime
-  environment. The storage and visualization of telemetry is intentionally left
-  to other tools.
+- An **[observability] framework and toolkit** designed to facilitate the
+
+  - [Generation][instr]
+  - Export
+  - [Collection](../concepts/components/#collector)
+
+  of [telemetry data][] such as [traces], [metrics], and [logs].
+
+- **Open source**, as well as **vendor- and tool-agnostic**, meaning that it can
+  be used with a broad variety of observability backends, including open source
+  tools like [Jaeger] and [Prometheus], as well as commercial offerings.
+  OpenTelemetry is **not** an observability backend itself.
+
+A major goal of OpenTelemetry is to enable easy instrumentation of your
+applications and systems, regardless of the programming language,
+infrastructure, and runtime environments used.
+
+The backend (storage) and the frontend (visualization) of telemetry data are
+intentionally left to other tools.
 
 ## What is observability?
 
-[Observability](/docs/concepts/observability-primer/#what-is-observability) is
-the ability to understand the internal state of a system by examining its
-outputs. In the context of software, this means being able to understand the
-internal state of a system by examining its telemetry data, which includes
-traces, metrics, and logs.
+[Observability] is the ability to understand the internal state of a system by
+examining its outputs. In the context of software, this means being able to
+understand the internal state of a system by examining its telemetry data, which
+includes traces, metrics, and logs.
 
-To make a system observable, it must be
-[instrumented](/docs/concepts/instrumentation). That is, the code must emit
-[traces](/docs/concepts/signals/traces/),
-[metrics](/docs/concepts/signals/metrics/), or
-[logs](/docs/concepts/signals/logs/). The instrumented data must then be sent to
-an observability backend.
+To make a system observable, it must be [instrumented][instr]. That is, the code
+must emit [traces], [metrics], or [logs]. The instrumented data must then be
+sent to an observability backend.
 
 ## Why OpenTelemetry?
 
 With the rise of cloud computing, microservices architectures, and increasingly
 complex business requirements, the need for software and infrastructure
-[observability](/docs/concepts/observability-primer/#what-is-observability) is
-greater than ever.
+[observability] is greater than ever.
 
 OpenTelemetry satisfies the need for observability while following two key
 principles:
@@ -62,24 +60,23 @@ If you want to learn more, take a look at OpenTelemetry's
 
 OpenTelemetry consists of the following major components:
 
-- A [specification](/docs/specs/otel) for all components
-- A standard [protocol](/docs/specs/otlp/) that defines the shape of telemetry
-  data
-- [Semantic conventions](/docs/specs/semconv/) that define a standard naming
-  scheme for common telemetry data types
+- A [specification](../specs/otel) for all components
+- A standard [protocol](../specs/otlp/) that defines the shape of telemetry data
+- [Semantic conventions](../specs/semconv/) that define a standard naming scheme
+  for common telemetry data types
 - APIs that define how to generate telemetry data
-- [Language SDKs](/docs/languages) that implement the specification, APIs, and
+- [Language SDKs](../languages) that implement the specification, APIs, and
   export of telemetry data
 - A [library ecosystem](/ecosystem/registry) that implements instrumentation for
   common libraries and frameworks
 - Automatic instrumentation components that generate telemetry data without
   requiring code changes
-- The [OpenTelemetry Collector](/docs/collector), a proxy that receives,
-  processes, and exports telemetry data
+- The [OpenTelemetry Collector](../collector), a proxy that receives, processes,
+  and exports telemetry data
 - Various other tools, such as the
-  [OpenTelemetry Operator for Kubernetes](/docs/platforms/kubernetes/operator/),
-  [OpenTelemetry Helm Charts](/docs/platforms/kubernetes/helm/), and
-  [community assets for FaaS](/docs/platforms/faas/)
+  [OpenTelemetry Operator for Kubernetes](../platforms/kubernetes/operator/),
+  [OpenTelemetry Helm Charts](../platforms/kubernetes/helm/), and
+  [community assets for FaaS](../platforms/faas/)
 
 OpenTelemetry is used by a wide variety of
 [libraries, services and apps](/ecosystem/integrations/) that have OpenTelemetry
@@ -97,7 +94,7 @@ extended include:
 - Adding a receiver to the OpenTelemetry Collector to support telemetry data
   from a custom source
 - Loading custom instrumentation libraries into an SDK
-- Creating a [distribution](/docs/concepts/distributions/) of an SDK or the
+- Creating a [distribution](../concepts/distributions/) of an SDK or the
   Collector tailored to a specific use case
 - Creating a new exporter for a custom backend that doesn't yet support the
   OpenTelemetry protocol (OTLP)
@@ -108,8 +105,7 @@ designed to make it possible at nearly every level.
 
 ## History
 
-OpenTelemetry is a
-[Cloud Native Computing Foundation (CNCF)](https://www.cncf.io) project that is
+OpenTelemetry is a [Cloud Native Computing Foundation][] (CNCF) project that is
 the result of a [merger] between two prior projects,
 [OpenTracing](https://opentracing.io) and [OpenCensus](https://opencensus.io).
 Both of these projects were created to solve the same problem: the lack of a
@@ -119,12 +115,22 @@ they merged to form OpenTelemetry and combine their strengths while offering a
 single solution.
 
 If you are currently using OpenTracing or OpenCensus, you can learn how to
-migrate to OpenTelemetry in the [Migration guide](/docs/migration/).
+migrate to OpenTelemetry in the [Migration guide](../migration/).
 
 [merger]:
   https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
 
 ## What next?
 
-- [Getting started](/docs/getting-started/) — jump right in!
-- Learn about [OpenTelemetry concepts](/docs/concepts/).
+- [Getting started](../getting-started/) — jump right in!
+- Learn about [OpenTelemetry concepts](../concepts/).
+
+[Cloud Native Computing Foundation]: https://www.cncf.io
+[instr]: ../concepts/instrumentation
+[Jaeger]: https://www.jaegertracing.io/
+[logs]: ../concepts/signals/logs/
+[metrics]: ../concepts/signals/metrics/
+[observability]: ../concepts/observability-primer/#what-is-observability
+[Prometheus]: https://prometheus.io/
+[telemetry data]: ../concepts/signals/
+[traces]: ../concepts/signals/traces/

content/en/docs/what-is-opentelemetry.md

@@ -7,7 +7,7 @@ aliases:
 cascade:
   vers:
     instrumentation: 2.13.3
-    otel: 1.47.0
+    otel: 1.48.0
 ---
 
 Common options for zero-code instrumentation with Java are the Java agent JAR,

content/en/docs/zero-code/java/_index.md

@@ -93,7 +93,7 @@ span link connecting it to the producer trace.
 ## Capturing enduser attributes
 
 You can configure the agent to capture
-[general identity attributes](/docs/specs/semconv/general/attributes/#general-identity-attributes)
+[general identity attributes](/docs/specs/semconv/attributes-registry/enduser/)
 (`enduser.id`, `enduser.role`, `enduser.scope`) from instrumentation libraries
 like
 [JavaEE/JakartaEE Servlet](https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/servlet)

content/en/docs/zero-code/java/agent/instrumentation/_index.md

@@ -0,0 +1,5 @@
+---
+title: 2025
+weight: -2025
+default_lang_commit: 94d77ab8cbfe5552a7cd68bf677be86c574a613a
+---