Merge branch 'main' into renovate/github-actions-deps

Author: carlosalberto

CONTRIBUTING.md

@@ -158,7 +158,8 @@ To check for typos, run the following command:
 make misspell
 ```
 
-> **NOTE**: The `misspell` make target will also fetch and build the tool if
+> [!NOTE]
+> The `misspell` make target will also fetch and build the tool if
 > necessary. You'll need [Go](https://go.dev) to build the spellchecker.
 
 To quickly fix typos, use

oteps/0156-columnar-encoding.md

@@ -190,7 +190,8 @@ the compression ratio. This is illustrated in the following diagram.
 
 ![Traffic reduction](img/0156_traffic_reduction_use_case.png)
 
-> Note 1: A fallback mechanism can be used to handle the case where the new protocol is not supported by the target.
+> [!NOTE]
+> **1:** A fallback mechanism can be used to handle the case where the new protocol is not supported by the target.
 > More on this mechanism in this [section](#protocol-extension-and-fallback-mechanism).
 
 #### Phase 2
@@ -274,6 +275,7 @@ service ArrowMetricsService {
 }
 ```
 
+> [!INFORMATION]
 > **Unary RPC vs Stream RPC**: We use a stream-oriented protocol **to get rid of the overhead of specifying the schema
 > and dictionaries for each batch.** A state will be maintained receiver side to keep track of the schemas and
 > dictionaries. The [Arrow IPC format](#arrow-ipc-format) has been designed to follow this pattern and also allows the
@@ -391,7 +393,8 @@ By storing Arrow buffers in a protobuf field of type 'bytes' we can leverage the
 protobuf implementations (e.g. C++, Java, Rust) in order to get the most out of Arrow (relying on zero-copy ser/deser
 framework).
 
-> Note: By default, ZSTD compression is enabled at the Arrow IPC level in order to benefit from the best compression
+> [!NOTE]
+> By default, ZSTD compression is enabled at the Arrow IPC level in order to benefit from the best compression
 > ratio regardless of the collector configuration. However, this compression can be disabled to enable it at the global
 > gRPC level if it makes more sense for a particular configuration.
 
@@ -450,7 +453,8 @@ To indicate not-retryable errors the server is recommended to use code INVALID_A
 details
 via `error_message`.
 
-> Note: [Appendix A](#appendix-a---protocol-buffer-definitions) contains the full protobuf definition.
+> [!NOTE]
+> [Appendix A](#appendix-a---protocol-buffer-definitions) contains the full protobuf definition.
 
 ### Mapping OTel Entities to Arrow Records
 
@@ -489,7 +493,8 @@ same schema are grouped in a homogeneous stream. The first message sent contains
 the schema definition and the dictionaries. The following messages will not need to define the schema anymore.
 The dictionaries will only be sent again when their content change. The following diagram illustrates this process.
 
-> Note: The approach of using a single Arrow record per OTel entity, which employs list, struct, and union Arrow data
+> [!NOTE]
+> The approach of using a single Arrow record per OTel entity, which employs list, struct, and union Arrow data
 > types, was not adopted mainly due to the inability to sort each level of the OTel hierarchy independently. The mapping
 > delineated in this document, on average, provides a superior compression ratio.
 
@@ -533,7 +538,8 @@ engines.
 - The avoidance of complex Arrow data types (like union, list of struct) optimizes compatibility with the Arrow
 ecosystem.
 
-> Note: Complex attribute values could also be encoded in protobuf once the `pdata` library provides support for it.
+> [!NOTE]
+> Complex attribute values could also be encoded in protobuf once the `pdata` library provides support for it.
 
 #### Spans Arrow Mapping
 
@@ -581,7 +587,8 @@ As usual, each of these Arrow records is sorted by specific columns to optimize
 batch of metrics containing a large number of data points sharing the same attributes and timestamp will be highly
 compressible (multivariate time-series scenario).
 
-> Note: every OTLP timestamps are represented as Arrow timestamps as Epoch timestamps with nanosecond precision. This representation will
+> [!NOTE]
+> every OTLP timestamps are represented as Arrow timestamps as Epoch timestamps with nanosecond precision. This representation will
 > simplify the integration with the rest of the Arrow ecosystem (numerous time/date functions are supported in
 > DataFusion for example).
 > Note: aggregation_temporality is represented as an Arrow dictionary with a dictionary index of type int8. This OTLP

oteps/0243-app-telemetry-schema-vision-roadmap.md

@@ -109,9 +109,10 @@ and [Honeycomb Query Assistant](https://www.honeycomb.io/blog/introducing-query-
 are likely to become increasingly prevalent and efficient in the near future,
 thanks to the adoption of a schema-first approach.
 
-> **Note: The names and formats of these concepts are still under discussion. A
+> [!NOTE]
+> The names and formats of these concepts are still under discussion. A
 > detailed analysis of pros and cons will be covered later in the document. The
-> final decision will be deferred to future dedicated OTEPs.**
+> final decision will be deferred to future dedicated OTEPs.
 
 Another problem this proposal aims to address is the inherent complexity of the
 ecosystem where OpenTelemetry is utilized but not fully addressed by existing

oteps/0258-env-context-baggage-carriers.md

@@ -65,7 +65,8 @@ and produced by an arbitrary TextMapPropagator.
 
 Consider the following diagram in the context of process forking:
 
-> Note: The diagram is simply an example and simplification of process forking.
+> [!NOTE]
+> The diagram is simply an example and simplification of process forking.
 > There are other ways to spawn processes which are more performant like
 > exec().
 
@@ -78,7 +79,8 @@ propagate context to the child process such that it can be tied to the parent.
 Without `TRACEPARENT`, a tracing backend would not be able to connect the child
 process spans to the parent span, forming an end-to-end trace.
 
-> Note: While the below exclusively follows the W3C Specification translated
+> [!NOTE]
+> While the below exclusively follows the W3C Specification translated
 > into environment variables, this proposal is not exclusive to W3C and is
 > instead focused on the mechanism of Text Map Propagation with a potential set
 > of well-known environment variable names. See the [Core Specification
@@ -102,7 +104,8 @@ This could be set in the environment as follows:
 export TRACEPARENT=00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
 ```
 
-> Note: The value of TRACEPARENT is a combination of the above field values as
+> [!NOTE]
+> The value of TRACEPARENT is a combination of the above field values as
 > unsigned integer values serialized as ASCII strings, delimited by `-`.
 
 The `tracestate` (lowercase) header is defined in [W3C

oteps/trace/0174-http-semantic-conventions.md

@@ -19,7 +19,8 @@ stable state is a crucial step for users and instrumentation authors, as it
 allows them to rely on [stability guarantees](../../specification/versioning-and-stability.md#semantic-conventions-stability),
 and thus to ship and use stable instrumentation.
 
-> NOTE. This OTEP captures a scope for changes should be done to existing
+> [!NOTE]
+> This OTEP captures a scope for changes should be done to existing
 experimental semantic conventions for HTTP, but does not propose solutions.
 
 ## Roadmap for v1.0
@@ -43,7 +44,8 @@ some steps can be worked on in parallel.
 
 ## Scope for v1.0: scenarios and open questions
 
-> NOTE. The scope defined here is subject for discussions and can be adjusted
+> [!NOTE]
+> The scope defined here is subject for discussions and can be adjusted
   until this OTEP is merged.
 
 Scenarios and open questions mentioned below must be addressed via separate PRs.
@@ -111,7 +113,8 @@ Some attributes can contain potentially sensitive information. Most likely, by
 default web frameworks/http clients should not expose that. For example,
 `http.target` has a query string that may contain credentials.
 
-> NOTE. We didn’t omit security concerns from v1.0 on purpose, it’s just not
+> [!NOTE]
+> We didn’t omit security concerns from v1.0 on purpose, it’s just not
   something we’ve fleshed out so far.
 
 ### Sampling for noop case
@@ -135,7 +138,8 @@ Need some real-life/expertize here.
 
 ### Request/Response body capturing
 
-> NOTE. This is technically out-of-scope, but we should have an idea how to let
+> [!NOTE]
+> This is technically out-of-scope, but we should have an idea how to let
   users do it
 
 There is a lot of user feedback that they want it, but

specification/configuration/data-model.md

@@ -10,7 +10,7 @@ weight: 2
 <!-- toc -->
 
 - [Overview](#overview)
-  * [Stability definition](#stability-definition)
+  * [Versioning policy and stability guarantees](#versioning-policy-and-stability-guarantees)
   * [File-based configuration model](#file-based-configuration-model)
     + [YAML file format](#yaml-file-format)
     + [Environment variable substitution](#environment-variable-substitution)
@@ -34,9 +34,9 @@ The data model itself is an abstraction with multiple built-in representations:
 * [File-based configuration model](#file-based-configuration-model)
 * [SDK in-memory configuration model](./sdk.md#in-memory-configuration-model)
 
-### Stability definition
+### Versioning policy and stability guarantees
 
-See `opentelemetry-configuration` [stability definition](https://github.com/open-telemetry/opentelemetry-configuration?tab=readme-ov-file#stability-definition).
+See `opentelemetry-configuration` [versioning policy](https://github.com/open-telemetry/opentelemetry-configuration/blob/main/VERSIONING.md).
 
 ### File-based configuration model
 

specification/context/env-carriers.md

@@ -159,7 +159,8 @@ Windows.
 
 ## Supplementary Guidelines
 
-> **IMPORTANT**: This section is non-normative and provides implementation
+> [!IMPORTANT]
+> This section is non-normative and provides implementation
 > guidance only. It does not add requirements to the specification.
 
 Language implementations of OpenTelemetry have flexibility in how they implement

specification/entities/data-model.md

@@ -39,7 +39,8 @@ the `service` entity is related to the `process` entity. The process normally
 also runs on a host, so we say that the `process` entity is related to the
 `host` entity.
 
-> Note: Entity relationship modelling will be refined in future specification
+> [!NOTE]
+> Entity relationship modelling will be refined in future specification
 > work.
 
 The data model below defines a logical model for an entity (irrespective of the
@@ -69,7 +70,8 @@ the identity was generated from the process itself, e.g. via SDK, or by an
 OpenTelemetry Collector running on the same host, or by some other system
 describing the process.
 
-> Aside: There are many ways to accomplish repeatable identifying attributes
+> [!TIP]
+> There are many ways to accomplish repeatable identifying attributes
 > across multiple observers. While many successful systems rely on pushing down
 > identity from a central registry or knowledge store, OpenTelemetry must
 > support all possible scenarios.

specification/metrics/data-model.md

@@ -224,7 +224,8 @@ for telemetry collection purposes. The best example of this is the Histogram
 metric where raw events are recorded in a compressed format rather than
 individual timeseries.
 
-> Note: The above picture shows how one instrument can transform events into
+> [!NOTE]
+> The above picture shows how one instrument can transform events into
 > more than one type of metric stream. There are caveats and nuances for when
 > and how to do this.  Instrument and metric configuration are outlined
 > in the [metrics API specification](api.md).
@@ -1238,7 +1239,8 @@ sums to be reported, the timeseries model we target does not support delta
 counters.  To this end, converting from delta to cumulative needs to be defined
 so that backends can use this mechanism.
 
-> Note: This is not the only possible Delta to Cumulative algorithm.  It is
+> [!NOTE]
+> This is not the only possible Delta to Cumulative algorithm.  It is
 > just one possible implementation that fits the OTel Data Model.
 
 Converting from delta points to cumulative point is inherently a stateful

specification/resource/README.md

@@ -62,7 +62,8 @@ through their `kubectl` or Kubernetes UIs to find the specific process
 generating telemetry.   This is as important as being able to uniquely identify
 one process from another.
 
-> Aside: Observability signals SHOULD be actionable.  Knowing a process is
+> [!TIP]
+> Observability signals SHOULD be actionable.  Knowing a process is
 > struggling is not as useful as being able to scale up a deployment to take
 > load off the struggling process.