Merge branch 'main' into update_sync_gauge_example

.github/workflows/check-spelling.yml

@@ -13,7 +13,7 @@ jobs:
         with:
           # Files should be consistent with check:spelling files
           files: |
-            content/**/*.md
+            content/en/*.md
             layouts/**/*.md
             data/**/*
           config: .cspell.yml

.textlintrc.yml

@@ -158,3 +158,6 @@ rules:
       - ['screen[- ]shot(s)?', screenshot$1]
       - ['time[- ]stamp(s)?', timestamp$1]
       - ["uid['’]?(s)?", UID$1]
+      # Enable the following to find and replace "instrumentation module/package" with "instrumentation library":
+      # - ["(auto(matic)?[- ])?instrumentation (module|package)", "instrumentation library"]
+      # - ["(auto(matic)?[- ])?instrumentation (modules|packages)", "instrumentation libraries"]

content/en/blog/2022/dotnet-instrumentation-first-beta.md

@@ -12,9 +12,9 @@ of the
 [OpenTelemetry .NET Automatic Instrumentation](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation)
 project!
 
-Without this project, .NET developers need to use instrumentation packages to
+Without this project, .NET developers need to use instrumentation libraries to
 automatically generate telemetry data. For example, to instrument inbound
-ASP.NET Core requests, you need to use the ASP.NET Core instrumentation package
+ASP.NET Core requests, you need to use the ASP.NET Core instrumentation library
 and initialize it with the OpenTelemetry SDK.
 
 Now, developers can use

content/en/blog/2022/troubleshooting-nodejs.md

@@ -122,7 +122,7 @@ such as serverless, can import packages before the instrumentation code has a
 chance to run. This can be easily missed.
 
 To diagnose this issue, enable logging and verify you are seeing your
-instrumentation package being loaded. For example:
+instrumentation library being loaded. For example:
 
 ```nocode
 @opentelemetry/instrumentation-http Applying patch for [email protected]
@@ -337,7 +337,7 @@ provider.shutdown();
 ## Package Versions Compatibility
 
 Some issues can be a result of incompatible or old versions of SDK and
-instrumentation packages.
+instrumentation libraries.
 
 ### SDK versions
 

content/en/blog/2023/end-user-discussions-03.md

@@ -154,8 +154,8 @@ Additional suggestions:
 
 - Start with dev or testing environments first to build trust in the software
 - Choose a stack where OTel is more robust, such as Java and Node.js
-- For countering developer resistance, using auto-instrumentation modules to
-- start with is a good step
+- For countering developer resistance, using automatic instrumentation to start
+  with is a good step
 
 #### 2 - Starting and scaling
 

content/en/blog/2023/end-user-q-and-a-01.md

@@ -275,7 +275,7 @@ any suggestions for improvement!
 There is also a huge focus on
 [stabilizing semantic conventions](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#),
 and as part of that effort, maintainers plan to go through the existing
-instrumentation packages and to make sure that they’re all up to date with the
+instrumentation libraries and to make sure that they’re all up to date with the
 latest conventions. While it’s very well-maintained for certain languages, such
 as Java, that is not the case for other languages, such as Node.js.
 

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

@@ -123,7 +123,7 @@ considerations to help you decide how to minimize dependency hell:
   package, so that will never cause issues for users who don't use it. You can
   keep it in your repository, or
   [add it to OpenTelemetry](https://github.com/open-telemetry/oteps/blob/main/text/0155-external-modules.md#contrib-components),
-  so it will ship with other instrumentation packages.
+  so it will ship with other instrumentation libraries.
 - Semantic Conventions are [stable, but subject to evolution][]: while this does
   not cause any functional issues, you may need to update your instrumentation
   every once in a while. Having it in a preview plugin or in OpenTelemetry

content/en/docs/faas/lambda-auto-instrument.md

@@ -87,8 +87,7 @@ and the package on [PyPi](https://pypi.org/project/opentelemetry-api/).
 Change the entry point of your application by setting
 `AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler` for Node.js or Java, and
 `AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrument` for Python. These wrapper scripts
-will invoke your Lambda application with the auto instrumentation package
-applied.
+will invoke your Lambda application with the automatic instrumentation applied.
 
 ### Add the ARN of Instrumentation Lambda Layer
 

content/en/docs/languages/erlang/libraries.md

@@ -33,8 +33,8 @@ end
 
 Where `{package}` is the name of the instrumentation.
 
-Note that some instrumentation packages might have prerequisites. Check the
-documentation of each instrumentation package for further instructions.
+Note that some instrumentation libraries might have prerequisites. Check the
+documentation of each instrumentation library for further instructions.
 
 ## Available instrumentation libraries
 

content/en/docs/languages/js/getting-started/nodejs.md

@@ -147,7 +147,7 @@ First, install the Node SDK and autoinstrumentations package.
 The Node SDK lets you initialize OpenTelemetry with several configuration
 defaults that are correct for the majority of use cases.
 
-The `auto-instrumentations-node` package installs instrumentation packages that
+The `auto-instrumentations-node` package installs instrumentation libraries that
 will automatically create spans corresponding to code called in libraries. In
 this case, it provides instrumentation for Express, letting the example app
 automatically create spans for each incoming request.

content/en/docs/languages/js/libraries.md

@@ -59,7 +59,7 @@ npm install --save @opentelemetry/auto-instrumentations-web
 {{% /tab %}} {{< /tabpane >}}
 
 Note, that using those metapackages increases your dependency graph size. Use
-individual instrumentation packages if you know exactly which ones you need.
+individual instrumentation libraries if you know exactly which ones you need.
 
 ### Registration
 

content/en/docs/languages/net/libraries.md

@@ -32,7 +32,7 @@ creating a [TracerProvider](/docs/concepts/signals/traces/#tracer-provider).
 ## Note on Versioning
 
 The Semantic Conventions (Standards) for attribute names are not currently
-stable therefore the instrumentation package is currently not in a released
+stable therefore the instrumentation library is currently not in a released
 state. That doesn't mean that the functionality itself is not stable, only that
 the names of some of the attributes may change in the future, some may be added,
 some may be removed. This means that you need to use the `--prerelease` flag, or
@@ -51,7 +51,7 @@ dotnet add package OpenTelemetry.Extensions.Hosting
 dotnet add package OpenTelemetry.Exporter.Console
 ```
 
-Then you can install the Instrumentation packages
+Then you can install the instrumentation libraries:
 
 ```sh
 dotnet add package OpenTelemetry.Instrumentation.AspNetCore --prerelease

content/en/docs/languages/php/getting-started.md

@@ -142,7 +142,7 @@ Next, you’ll use the OpenTelemetry PHP extension to
      open-telemetry/opentelemetry-auto-slim
    ```
 
-With the OpenTelemetry PHP extension set up and an auto-instrumentation package
+With the OpenTelemetry PHP extension set up and an instrumentation library
 installed, you can now run your application and generate some traces:
 
 ```sh

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

@@ -30,7 +30,7 @@ pip install opentelemetry-exporter-{exporter}
 pip install opentelemetry-instrumentation-{instrumentation}
 ```
 
-These are for exporter and instrumentation packages respectively. The Jaeger,
+These are for exporter and instrumentation libraries respectively. The Jaeger,
 Zipkin, Prometheus, OTLP and OpenCensus Exporters can be found in the
 [exporter](https://github.com/open-telemetry/opentelemetry-python/blob/main/exporter/)
 directory of the repository. Instrumentations and additional exporters can be

content/en/docs/zero-code/java/spring-boot-starter/additional-instrumentations.md

@@ -1,6 +1,6 @@
 ---
 title: Additional instrumentation
-weight: 50
+weight: 60
 ---
 
 The OpenTelemetry Spring Boot starter provides

content/en/docs/zero-code/java/spring-boot-starter/annotations.md

@@ -1,57 +1,95 @@
 ---
 title: Annotations
-weight: 60
+weight: 50
+cSpell:ignore: proxys
 ---
 
 For most users, the out-of-the-box instrumentation is completely sufficient and
 nothing more has to be done. Sometimes, however, users wish to create
 [spans](/docs/concepts/signals/traces/#spans) for their own custom code without
-doing too much code change.
+needing to make many code changes.
 
-## Available annotations
-
-This feature uses spring-aop to wrap methods annotated with `@WithSpan` in a
-span. The arguments to the method can be captured as attributed on the created
-span by annotating the method parameters with `@SpanAttribute`.
-
-> **Note**: this annotation can only be applied to bean methods managed by the
-> spring application context. To learn more about aspect weaving in spring, see
-> [spring-aop](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop).
-
-| Feature     | Property                                   | Default Value | Description                       |
-| ----------- | ------------------------------------------ | ------------- | --------------------------------- |
-| `@WithSpan` | `otel.instrumentation.annotations.enabled` | true          | Enables the WithSpan annotations. |
+If you add the `WithSpan` annotation to a method, the method is wrapped in a
+span. The `SpanAttribute` annotation allows you to capture the method arguments
+as attributes.
 
 ```java
-import org.springframework.stereotype.Component;
-
 import io.opentelemetry.instrumentation.annotations.SpanAttribute;
 import io.opentelemetry.instrumentation.annotations.WithSpan;
-import io.opentelemetry.api.trace.Span;
-import io.opentelemetry.api.trace.SpanKind;
-
-/**
- * Test WithSpan
- */
-@Component
-public class TracedClass {
 
     @WithSpan
-    public void tracedMethod() {
+    public void tracedMethod(@SpanAttribute parameter) {
     }
+```
 
-    @WithSpan(value="span name")
-    public void tracedMethodWithName() {
-        Span currentSpan = Span.current();
-        currentSpan.addEvent("ADD EVENT TO tracedMethodWithName SPAN");
-        currentSpan.setAttribute("isTestAttribute", true);
-    }
+{{% alert title="Note" color="info" %}} The OpenTelemetry annotations use Spring
+AOP based on proxys.
+
+These annotations work only for the methods of the proxy. You can learn more in
+the
+[Spring documentation](https://docs.spring.io/spring-framework/reference/core/aop/proxying.html).
 
-    @WithSpan(kind = SpanKind.CLIENT)
-    public void tracedClientSpan() {
+In the following example, the `WithSpan` annotation won't do anything when the
+GET endpoint is called:
+
+```java
+@RestController
+public class MyControllerManagedBySpring {
+
+    @GetMapping("/ping")
+    public void aMethod() {
+        anotherMethod();
     }
 
-    public void tracedMethodWithAttribute(@SpanAttribute("attributeName") String parameter) {
+    @WithSpan
+    public void anotherMethod() {
     }
 }
 ```
+
+{{% /alert %}}
+
+{{% alert title="Note" color="info" %}}
+
+To be able to use the OpenTelemetry annotations, you have to add the Spring Boot
+Starter AOP dependency to your project:
+
+{{< tabpane text=true >}} {{% tab header="Maven (`pom.xml`)" lang=Maven %}}
+
+```xml
+<dependencies>
+  <dependency>
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-aop</artifactId>
+  </dependency>
+</dependencies>
+```
+
+{{% /tab %}} {{% tab header="Gradle (`gradle.build`)" lang=Gradle %}}
+
+```kotlin
+dependencies {
+  implementation("org.springframework.boot:spring-boot-starter-aop")
+}
+```
+
+{{% /tab %}} {{< /tabpane >}}
+
+{{% /alert %}}
+
+You can disable the OpenTelemetry annotations by setting the
+`otel.instrumentation.annotations.enabled` property to `false`.
+
+You can customize the span by using the elements of the `WithSpan` annotation:
+
+| Name    | Type       | Description           | Default Value       |
+| ------- | ---------- | --------------------- | ------------------- |
+| `value` | `String`   | Span name             | ClassName.Method    |
+| `kind`  | `SpanKind` | Span kind of the span | `SpanKind.INTERNAL` |
+
+You can set the attribute name from the `value` element of the `SpanAttribute`
+annotation:
+
+| Name    | Type     | Description    | Default Value         |
+| ------- | -------- | -------------- | --------------------- |
+| `value` | `String` | Attribute name | Method parameter name |

content/en/docs/zero-code/js/configuration.md

@@ -51,7 +51,7 @@ By default, all
 [supported instrumentation libraries](https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/metapackages/auto-instrumentations-node/README.md#supported-instrumentations)
 are enabled, but you can use the environment variable
 `OTEL_NODE_ENABLED_INSTRUMENTATIONS` to enable only certain instrumentations by
-providing a comma-separated list of the instrumentation package names without
+providing a comma-separated list of the instrumentation library names without
 the `@opentelemetry/instrumentation-` prefix.
 
 For example, to enable only

content/en/docs/zero-code/net/instrumentations.md

@@ -38,8 +38,8 @@ is the case-sensitive name of the instrumentation.
 ## Traces instrumentations
 
 **Status**: [Mixed](/docs/specs/otel/versioning-and-stability). Traces are
-stable, but particular instrumentation are in Experimental status due to lack of
-stable semantic convention.
+stable, but particular instrumentation libraries are in Experimental status due
+to lack of stable semantic convention.
 
 | ID                    | Instrumented library                                                                                                                                                                                               | Supported versions     | Instrumentation type | Status                                                    |
 | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------- | -------------------- | --------------------------------------------------------- |

content/en/docs/zero-code/net/nuget-packages.md

@@ -42,14 +42,14 @@ dotnet add [<PROJECT>] package OpenTelemetry.AutoInstrumentation
 
 If the application references packages that can be instrumented, but, require
 other packages for the instrumentation to work the build will fail and prompt
-you to either add the missing instrumentation package or to skip the
+you to either add the missing instrumentation library or to skip the
 instrumentation of the corresponding package:
 
 ```terminal
 ~packages/opentelemetry.autoinstrumentation.buildtasks/1.6.0/build/OpenTelemetry.AutoInstrumentation.BuildTasks.targets(29,5): error : OpenTelemetry.AutoInstrumentation: add a reference to the instrumentation package 'MongoDB.Driver.Core.Extensions.DiagnosticSources' version 1.4.0 or add 'MongoDB.Driver.Core' to the property 'SkippedInstrumentations' to suppress this error.
 ```
 
-To resolve the error either add the recommended instrumentation package or skip
+To resolve the error either add the recommended instrumentation library or skip
 the instrumentation of the listed package by adding it to the
 `SkippedInstrumentation` property, example:
 

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

@@ -31,8 +31,8 @@ example, if you already installed the `flask` package, running
 `opentelemetry-instrumentation-flask` for you.
 
 > **NOTE:** If you leave out `-a install`, the command will simply list out the
-> recommended auto-instrumentation packages to be installed. More information
-> can be found
+> recommended instrumentation libraries to be installed. More information can be
+> found
 > [here](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/opentelemetry-instrumentation#opentelemetry-bootstrap).
 
 ## Configuring the agent

content/zh/docs/migration/_index.md

@@ -0,0 +1,26 @@
+---
+title: 迁移
+description: 如何迁移到 OpenTelemetry
+weight: 950
+default_lang_commit: 4b1f5e382758278e1e56e7b197bd349c17fdf9cb
+---
+
+## OpenTracing 和 OpenCensus
+
+OpenTelemetry 是 OpenTracing 和 OpenCensus 的合并版本。
+从一开始，OpenTelemetry 就被定位[成为 OpenTracing 和 OpenCensus 的下一个主要版本][]。
+因此，OpenTelemetry 项目的[关键目标][]之一是提供与两个项目的向后兼容性以及为现有用户提供迁移方案。
+
+如果你来自其中一个项目，你可以遵循 [OpenTracing](opentracing/) 和
+[OpenCensus](opencensus/) 的迁移指南。
+
+## Jaeger 客户端
+
+[Jaeger 社区](https://www.jaegertracing.io/)弃用了他们的[客户端库](https://www.jaegertracing.io/docs/latest/client-libraries/)并建议使用
+OpenTelemetry 的 API、SDK 和插桩器。
+
+自 v1.35 起，Jaeger 后端可以通过 OpenTelemetry 协议（OTLP）接收链路数据。
+因此，你可以将 OpenTelemetry SDK 和收集器从使用 Jaeger 导出器迁移到 OTLP 导出器。
+
+[成为 OpenTracing 和 OpenCensus 的下一个主要版本]: https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
+[关键目标]: https://medium.com/opentracing/merging-opentracing-and-opencensus-f0fe9c7ca6f0

data/ecosystem/distributions.yaml

@@ -99,3 +99,7 @@
   url: https://github.com/elastic/elastic-otel-node
   docsUrl: https://github.com/elastic/elastic-otel-node
   components: [Node]
+- name: Elastic Distribution for OpenTelemetry Python
+  url: https://github.com/elastic/elastic-otel-python
+  docsUrl: https://github.com/elastic/elastic-otel-python
+  components: [Python]

data/registry/instrumentation-js-fastify.yml

@@ -6,7 +6,7 @@ tags:
   - Node.js
   - fastify
 license: Apache 2.0
-description: OpenTelemetry fastify automatic instrumentation package
+description: OpenTelemetry fastify automatic instrumentation library
 authors:
   - name: OpenTelemetry Authors
 urls:

data/registry/instrumentation-js-nestjs.yml

@@ -7,7 +7,7 @@ tags:
   - instrumentation
   - nestjs
 license: Apache 2.0
-description: OpenTelemetry NestJS automatic instrumentation package
+description: OpenTelemetry NestJS automatic instrumentation library
 authors:
   - name: OpenTelemetry Authors
 urls: