open-telemetry · carlosalberto · Oct 10, 2025 · Oct 8, 2025 · Oct 9, 2025 · Oct 9, 2025
@@ -2,11 +2,24 @@ include_fragments = true
 
 accept = ["200..=299", "403"]
 
+remap = [
+  # workaround for https://github.com/lycheeverse/lychee/issues/1729
+  'https://github.com/(.*?)/(.*?)/blob/(.*?)/(.*#.*)$ https://raw.githubusercontent.com/$1/$2/$3/$4',
+  'https://docs.oracle.com/(.*)#.*$ https://docs.oracle.com/$1'
+]
+
 exclude = [
-    # excluding links to pull requests and issues is done for performance
-    "^https://github.com/open-telemetry/opentelemetry-specification/(issues|pull)/\\d+$",
-    # TODO (trask) look into this
-    "^https://docs.google.com/document/d/1d0afxe3J6bQT-I6UbRXeIYNcTIyBQv4axfjKF4yvAPA/edit"
+  # workaround for https://github.com/lycheeverse/lychee/issues/1729
+  '^https://github.com/.*/(pull|issues|commit|compare)/.*#.*$',
+  '.*decision-log.md#L0-L1',
+  # excluding links to pull requests and issues is done for performance
+  '^https://github.com/open-telemetry/opentelemetry-specification/(issues|pull)/\d+$',
+  # TODO (trask) look into this
+  '^https://docs.google.com/.*/edit.*$',
+  'https://semver.org/#spec-item-11',
+  'https://w3c.github.io/trace-context/#trace-id',
+  'https://facebook.github.io/zstd/#small-data',
+  'https://javadoc.io/doc/org.apache.logging.log4j/log4j-api/latest/org.apache.logging.log4j/org/apache/logging/log4j/Logger.html'
 ]
 
 # better to be safe and avoid failures

@@ -289,7 +289,7 @@ on each other), the owner should try to get people aligned by:
 
 If none of the above worked and the PR has been stuck for more than 2 weeks, the
 owner should bring it to the [OpenTelemetry Specification SIG
-meeting](https://github.com/open-telemetry/community#cross-language-specification).
+meeting](https://github.com/open-telemetry/community/blob/main/README.md#specification-sigs).
 
 [nvm]: https://github.com/nvm-sh/nvm/blob/master/README.md#installing-and-updating
 

@@ -29,7 +29,7 @@ misspell-correction:	$(MISSPELL)
 markdown-link-check:
 	docker run --rm \
 		--mount 'type=bind,source=$(PWD),target=/home/repo' \
-		lycheeverse/lychee:sha-2aa22f8@sha256:2e3786630482c41f9f2dd081e06d7da1c36d66996e8cf6573409b8bc418d48c4 \
+		lycheeverse/lychee:sha-8222559@sha256:6f49010cc46543af3b765f19d5319c0cdd4e8415d7596e1b401d5b4cec29c799 \
 		--config home/repo/.lychee.toml \
 		--root-dir /home/repo \
 		-v \
@@ -39,7 +39,7 @@ markdown-link-check:
     # see https://github.com/open-telemetry/opentelemetry-specification/pull/4554
 	docker run --rm \
 		--mount 'type=bind,source=$(PWD),target=/home/repo' \
-		lycheeverse/lychee:sha-2aa22f8@sha256:2e3786630482c41f9f2dd081e06d7da1c36d66996e8cf6573409b8bc418d48c4 \
+		lycheeverse/lychee:sha-8222559@sha256:6f49010cc46543af3b765f19d5319c0cdd4e8415d7596e1b401d5b4cec29c799 \
 		--config home/repo/.lychee.toml \
 		--root-dir /home/repo \
 		--max-redirects 0 \

@@ -29,7 +29,7 @@ APAC timezone friendly meetings are held on request. See
 [OpenTelemetry calendar](https://github.com/open-telemetry/community#calendar).
 
 Escalations to technical committee may be made over the
-[e-mail](https://github.com/open-telemetry/community#tc-technical-committee).
+[e-mail](https://github.com/open-telemetry/community/blob/main/README.md#mailing-lists).
 Technical committee holds regular meetings, notes are held
 [here](https://docs.google.com/document/d/1hOHPCu5TGenqTeWPB9qQB_qd33uITZBcvK1FnWxYJAw/edit?usp=sharing).
 

@@ -11,7 +11,7 @@
 - Reviewer:
   - Person whose Approval is needed to merge the PR.
 - Sponsor:
-  - The [specification sponsors](https://github.com/open-telemetry/community/blob/main/community-membership.md#specification-sponsor), identified as the assignee of the issue, is responsible for the completion of the issue.
+  - The [specification sponsors](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#specification-sponsor), identified as the assignee of the issue, is responsible for the completion of the issue.
 - Triager:
   - This person is responsible for applying appropriate labels as outlined below,
     following up on issues to ensure they are complete,

@@ -89,7 +89,7 @@ There are some languages that will have OpenTelemetry support before they have D
 
 ### Governance of the auto-instrumentation libraries
 
-Each `auto-instr-foo` repository must have at least one [Maintainer](https://github.com/open-telemetry/community/blob/main/community-membership.md#maintainer) in common with the main `opentelemetry-foo` language repository. There are no other requirements or constraints about the set of maintainers/approvers for the main language repository and the respective auto-instrumentation repository; in particular, there may be maintainers/approvers of the main language repository that are not maintainers/approvers for the auto-instrumentation repository, and vice versa.
+Each `auto-instr-foo` repository must have at least one [Maintainer](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer) in common with the main `opentelemetry-foo` language repository. There are no other requirements or constraints about the set of maintainers/approvers for the main language repository and the respective auto-instrumentation repository; in particular, there may be maintainers/approvers of the main language repository that are not maintainers/approvers for the auto-instrumentation repository, and vice versa.
 
 ### Mini-FAQ about this proposal
 

@@ -57,5 +57,5 @@ instance configured with it's own `Resource`.
 * [opentelemetry-specification/62](https://github.com/open-telemetry/opentelemetry-specification/issues/62)
 * [opentelemetry-specification/61](https://github.com/open-telemetry/opentelemetry-specification/issues/61)
 
-[otelsvc-receiver]: https://github.com/open-telemetry/opentelemetry-collector#config-receivers
-[create-metric]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#create-metric
+[otelsvc-receiver]: https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/README.md
+[create-metric]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#get-a-meter
@@ -93,7 +93,7 @@ When an error is returned by the server it falls into 2 broad categories: retrya
 
 - Not-retryable errors indicate that processing of telemetry data failed and the client MUST NOT retry sending the same telemetry data. The telemetry data MUST be dropped. This can happen, for example, when the request contains bad data and cannot be deserialized or otherwise processed by the server. The client SHOULD maintain a counter of such dropped data.
 
-When using gRPC transport the server SHOULD indicate retryable errors using code [Unavailable](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status.WithDetails) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40) containing 0 value of RetryDelay. Here is a sample Go code to illustrate:
+When using gRPC transport the server SHOULD indicate retryable errors using code [Unavailable](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40) containing 0 value of RetryDelay. Here is a sample Go code to illustrate:
 
 ```go
   // Do this on server side.
@@ -106,7 +106,7 @@ When using gRPC transport the server SHOULD indicate retryable errors using code
   return st.Err()
 ```
 
-To indicate not-retryable errors the server is recommended to use code [InvalidArgument](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status.WithDetails) using [BadRequest](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L119). Other gRPC status code may be used if it is more appropriate. Here is a sample Go code to illustrate:
+To indicate not-retryable errors the server is recommended to use code [InvalidArgument](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status) using [BadRequest](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L119). Other gRPC status code may be used if it is more appropriate. Here is a sample Go code to illustrate:
 
 ```go
   // Do this on server side.
@@ -148,7 +148,7 @@ OTLP allows backpressure signalling.
 
 If the server is unable to keep up with the pace of data it receives from the client then it SHOULD signal that fact to the client. The client MUST then throttle itself to avoid overwhelming the server.
 
-To signal backpressure when using gRPC transport, the server SHOULD return an error with code [Unavailable](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status.WithDetails) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40). Here is a sample Go code to illustrate:
+To signal backpressure when using gRPC transport, the server SHOULD return an error with code [Unavailable](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40). Here is a sample Go code to illustrate:
 
 ```go
   // Do this on server side.
@@ -265,7 +265,7 @@ Both FlatBuffers and Capnproto are worth to be re-evaluated for future versions
 
 It is also worth researching transports other than gRPC. Other transports are not included in this RFC due to time limitations.
 
-Experimental implementation of OTLP over WebSockets exists and was researched as an alternate. WebSockets were not chosen as the primary transport for OTLP due to lack or immaturity of certain capabilities (such as [lack of universal support](https://github.com/gorilla/websocket#gorilla-websocket-compared-with-other-packages) for [RFC 7692](https://datatracker.ietf.org/doc/html/rfc7692) message compression extension). Despite limitations the experimental implementation demonstrated good performance and WebSocket transport will be considered for inclusion in a future OTLP Extensions RFC.
+Experimental implementation of OTLP over WebSockets exists and was researched as an alternate. WebSockets were not chosen as the primary transport for OTLP due to lack or immaturity of certain capabilities (such as lack of universal support for [RFC 7692](https://datatracker.ietf.org/doc/html/rfc7692) message compression extension). Despite limitations the experimental implementation demonstrated good performance and WebSocket transport will be considered for inclusion in a future OTLP Extensions RFC.
 
 ## Open Questions
 

@@ -52,7 +52,7 @@ In fact, these repositories often calls for other set of skills and customer's u
 On contrib repository creation, new set of approvers and maintainers can be added as we do for any new repository, without time/contribution requirements.
 Repository maintainers are also encouraged to promote contributors to approver/maintainer role in this repository
 based on targeted contributions and expertise of the contrib repository rather than overall SIG scope.
-It is important to keep the process fair and inclusive by following the formal guidance published [here](https://github.com/open-telemetry/community/blob/main/community-membership.md#maintainer).
+It is important to keep the process fair and inclusive by following the formal guidance published [here](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer).
 A contrib repository may leverage the CODEOWNERS functionality of GitHub to assign maintainers to individual packages
 even if this means granting write permissions to the whole repo.
 The goal should be to distribute the load of reviewing PRs and accepting changes as much as possible, while keeping reliability and overall quality of components and fair governance.

@@ -804,7 +804,7 @@ dictionary and schema information.  This remains an area for study.
 ### Further-integrated compression techniques
 
 ZSTD offers a training mode, which can be used to tune the algorithm for a selected type of data. The result of this
-training is a dictionary that can be used to compress the data. Using this [dictionary](http://facebook.github.io/zstd/#small-data)
+training is a dictionary that can be used to compress the data. Using this [dictionary](https://facebook.github.io/zstd/#small-data)
 can dramatically improve the compression rate for small batches. This future development will build on both the gRPC
 stream approach used in this proposal and the ability to send a ZSTD dictionary over the OTel Arrow stateful protocol,
 allowing us to train the ZSTD algorithm on the first batches and then update the configuration of the ZSTD

@@ -30,7 +30,7 @@ Here are a few situations that require recording of Events, there will be more.
   - Swift on iOS has Logger interface that has methods corresponding to severity level too.
 - The current Log APIs do not have a standard way to pass event attributes.
   - It may be possible to use the interpolation string args as the parameter to pass event attributes. However, the logging spec seems to map the human readable message (which is obtained after replacing the args in the interpolated string) to the Body field of LogRecord.
-  - Log4j has an EventLogger interface that can be used to create structured messages with arbitrary key-value pairs, but log4j is not commonly used in Android apps as it is not officially supported on Android as per this [Stack Overflow thread](https://stackoverflow.com/questions/60398799/disable-log4j-jmx-on-android/60407849#60407849) by one of log4j’s maintainers.
+  - Log4j has an EventLogger interface that can be used to create structured messages with arbitrary key-value pairs, but log4j is not commonly used in Android apps as it is not officially supported on Android as per this [Stack Overflow thread](https://stackoverflow.com/a/60407849) by one of log4j’s maintainers.
   - In Python, logging.LogRecord's extra field is mapped to Otel LogRecord's attributes but this field is a hidden field and not part of the public interface.
 - The current Log APIs have a message parameter which could map to the Body field of LogRecord. However, this is restricted to String messages and does not allow for structured logs.
 

@@ -217,7 +217,7 @@ Note that there is no consistent mapping between environment variable names and
 
 Configuration files *MUST* support environment variable expansion. While this accommodates the scenario in which a configuration file needs to reference sensitive data and is not able to be stored securely, environment variable expansion is not limited to sensitive data.
 
-As a starting point for development, the syntax for environment variable expansion *MAY* mirror the [collector](https://opentelemetry.io/docs/collector/configuration/#configuration-environment-variables).
+As a starting point for development, the syntax for environment variable expansion *MAY* mirror the [collector](https://opentelemetry.io/docs/collector/configuration/#environment-variables).
 
 For example, given an environment where `API_KEY=1234`, the configuration file contents:
 

@@ -87,7 +87,7 @@ Have suggestions? Concerns? Questions? **Please** raise an issue or raise the ma
 
 ## Background on the OpenTelemetry OTEP process
 
-Our OTEP process borrows from the [Rust RFC](https://github.com/rust-lang/rfcs) and [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements) processes, the former also being [very influential](https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/0000-kep-process#prior-art) on the latter; as well as the [OpenTracing OTEP](https://github.com/opentracing/specification/blob/master/rfc_process.md) process. Massive kudos and thanks to the respective authors and communities for providing excellent prior art 💖
+Our OTEP process borrows from the [Rust RFC](https://github.com/rust-lang/rfcs) and [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements) processes, the former also being [very influential](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md#prior-art) on the latter; as well as the [OpenTracing OTEP](https://github.com/opentracing/specification/blob/master/rfc_process.md) process. Massive kudos and thanks to the respective authors and communities for providing excellent prior art 💖
 
 [slack-image]: https://img.shields.io/badge/Slack-4A154B?style=for-the-badge&logo=slack&logoColor=white
 [slack-url]: https://cloud-native.slack.com/archives/C01N7PP1THC
@@ -322,7 +322,7 @@ Today, [Prometheus compatibility](../../specification/compatibility/prometheus_a
 Here's a list of requirements for the solution:
 
 - Existing prometheus/OpenTelemetry users should be able to migrate from where they are today.
-- Any solution MUST work with the [info-typed metrics](https://github.com/prometheus/proposals/blob/main/proposals/2024-04-10-native-support-for-info-metrics-metadata.md#goals) being added in prometheus.
+- Any solution MUST work with the [info-typed metrics](https://github.com/prometheus/proposals/blob/main/proposals/0037-native-support-for-info-metrics-metadata.md#goals) being added in prometheus.
   - Resource descriptive attributes should leverage `info()` or metadata.
   - Resource identifying attributes need more thought/design from OpenTelemetry semconv + entities WG.
   - Note: Current `info()` design will only work with `target_info` metric by default (other info metrics can be specified per `info` call), and `job/instance` labels for joins.  These labels MUST be generated by the OTLP endpoint in prometheus.

@@ -36,7 +36,7 @@ terms as follows:
 ## How profiling aligns with the OpenTelemetry vision
 
 The [OpenTelemetry
-vision](https://opentelemetry.io/community/mission/#vision-mdash-the-world-we-imagine-for-otel-end-users)
+vision](https://opentelemetry.io/community/mission/#vision)
 states:
 
 _Effective observability is powerful because it enables developers to innovate

@@ -220,7 +220,7 @@ Disclaimer: this list of features is still a work in progress, please refer to t
 | Create empty |  | + | + | + | + | + | + | + | + | + | + | + |
 | [Merge (v2)](specification/resource/sdk.md#merge) |  | + | + |  | + | + | + | + | + | + | + |  |
 | Retrieve attributes |  | + | + | + | + | + | + | + | + | + | + | + |
-| [Default value](https://github.com/open-telemetry/semantic-conventions/tree/main/docs/resource#semantic-attributes-with-dedicated-environment-variable) for service.name |  | + | + |  | + | + | + | + |  | + | + |  |
+| [Default value](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/resource/README.md#semantic-attributes-with-dedicated-environment-variable) for service.name |  | + | + |  | + | + | + | + |  | + | + |  |
 | [Resource detector](specification/resource/sdk.md#detecting-resource-information-from-the-environment) interface/mechanism |  | + | + | + | + | + | + | + | + | + | + | + |
 | [Resource detectors populate Schema URL](specification/resource/sdk.md#detecting-resource-information-from-the-environment) |  | + | + |  |  |  | - | + |  |  | - |  |