Merge branch 'open-telemetry:main' into main

Author: kerneljack

.github/workflows/ossf-scorecard.yml

@@ -42,6 +42,6 @@ jobs:
       # Upload the results to GitHub's code scanning dashboard (optional).
       # Commenting out will disable upload of results to your repo's Code Scanning dashboard
       - name: 'Upload to code-scanning'
-        uses: github/codeql-action/upload-sarif@39edc492dbe16b1465b0cafca41432d857bdb31a # v3.29.1
+        uses: github/codeql-action/upload-sarif@181d5eefc20863364f96762470ba6f862bdef56b # v3.29.2
         with:
           sarif_file: results.sarif

.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.34.0
+	semconv-pin = v1.35.0
 [submodule "content-modules/opamp-spec"]
 	path = content-modules/opamp-spec
 	url = https://github.com/open-telemetry/opamp-spec

content-modules/semantic-conventions

@@ -71,6 +71,25 @@ service:
                 port: 8888
 ```
 
+If you want to add additional labels to the Prometheus metrics, you can add them
+with `prometheus::with_resource_constant_labels`:
+
+```yaml
+prometheus:
+  host: '0.0.0.0'
+  port: 8888
+  with_resource_constant_labels:
+    included:
+      - label_key
+```
+
+And then reference the labels in `service::telemetry::resource`:
+
+```yaml
+resource:
+  label_key: label_value
+```
+
 {{% alert title="Internal telemetry configuration changes" %}}
 
 As of Collector [v0.123.0], the `service::telemetry::metrics::address` setting
@@ -110,6 +129,29 @@ service:
       level: detailed
 ```
 
+You can further configure how metrics from the Collector are emitted by using
+[`views`](/docs/specs/otel/metrics/sdk/#view). For example, the following
+configuration updates the metric named `otelcol_process_uptime` to emit a new
+name `process_uptime` and description:
+
+```yaml
+service:
+  telemetry:
+    metrics:
+      views:
+        - selector:
+            instrument_name: otelcol_process_uptime
+            instrument_type:
+          stream:
+            name: process_uptime
+            description: The amount of time the Collector has been up
+```
+
+You can also use `views` to update the resulting aggregation, attributes, and
+cardinality limits. For the full list of options, see the examples in the
+OpenTelemetry Configuration schema
+[repository](https://github.com/open-telemetry/opentelemetry-configuration/blob/f4e9046682d4386ea533ef7ba6ad30a5ce4451b4/examples/kitchen-sink.yaml#L440).
+
 ### Configure internal logs
 
 Log output is found in `stderr`. You can configure logs in the config

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

@@ -11,7 +11,7 @@ weight: 22
 
 ## Version support
 
-OpenTelemetry-Python supports Python 3.8 and higher.
+OpenTelemetry-Python supports Python 3.9 and higher.
 
 ## Installation
 

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

@@ -70,14 +70,14 @@ OTEL_INSTRUMENTATION_AWS_SDK_ENABLED=true
 
 {{% /tab %}} {{% tab JavaScript %}}
 
-The Lambda layer supports Node.js v14+ Lambda runtimes. For more information
+The Lambda layer supports Node.js v18+ Lambda runtimes. For more information
 about supported JavaScript and Node.js versions, see the
 [OpenTelemetry JavaScript documentation](https://github.com/open-telemetry/opentelemetry-js).
 
 {{% /tab %}} {{% tab Python %}}
 
-The Lambda layer supports Python 3.8 and Python 3.9 Lambda runtimes. For more
-information about supported Python versions, see the
+The Lambda layer supports Python 3.9+ Lambda runtimes. For more information
+about supported Python versions, see the
 [OpenTelemetry Python documentation](https://github.com/open-telemetry/opentelemetry-python/blob/main/README.md#supported-runtimes)
 and the package on [PyPi](https://pypi.org/project/opentelemetry-api/).
 
@@ -93,9 +93,9 @@ and the package on [RubyGem](https://rubygems.org/search?query=opentelemetry).
 ### Configure `AWS_LAMBDA_EXEC_WRAPPER`
 
 Change the entry point of your application by setting
-`AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler` for Node.js, Java, or Ruby, and
-`AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrument` for Python. These wrapper scripts
-will invoke your Lambda application with the automatic instrumentation applied.
+`AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler` for Node.js, Java, Ruby, or Python.
+This wrapper script invokes your Lambda application with the automatic
+instrumentation applied.
 
 ### Add the ARN of Instrumentation Lambda Layer
 

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

@@ -56,7 +56,7 @@ To see the full range of configuration options, see
 
 A number of popular Node.js libraries are auto-instrumented. For the full list,
 see
-[supported instrumentation](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/metapackages/auto-instrumentations-node#supported-instrumentations).
+[supported instrumentation](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/packages/auto-instrumentations-node#supported-instrumentations).
 
 ## Troubleshooting
 

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

@@ -62,7 +62,7 @@ prefix.
 For example, to enable only
 [@opentelemetry/instrumentation-http](https://github.com/open-telemetry/opentelemetry-js/tree/main/experimental/packages/opentelemetry-instrumentation-http)
 and
-[@opentelemetry/instrumentation-express](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node/opentelemetry-instrumentation-express)
+[@opentelemetry/instrumentation-express](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/packages/instrumentation-express)
 instrumentations:
 
 ```shell
@@ -77,7 +77,7 @@ comma-separated list of the instrumentation library names without the
 `@opentelemetry/instrumentation-` prefix.
 
 For example, to disable only
-[@opentelemetry/instrumentation-fs](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node/instrumentation-fs)
+[@opentelemetry/instrumentation-fs](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/packages/instrumentation-fs)
 and
 [@opentelemetry/instrumentation-grpc](https://github.com/open-telemetry/opentelemetry-js/tree/main/experimental/packages/opentelemetry-instrumentation-grpc)
 instrumentations:

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

@@ -0,0 +1,102 @@
+---
+default_lang_commit: 8a5b880c16d49257a147c2c3ec4a6ef6fcee8e20
+---
+
+将遥测数据发送到 [OpenTelemetry Collector](/docs/collector/)，以确保其被正确导出。
+在生产环境中使用 Collector 是最佳实践。若要可视化你的遥测数据，可将其导出到后端系统，例如
+[Jaeger](https://jaegertracing.io/)、[Zipkin](https://zipkin.io/)、
+[Prometheus](https://prometheus.io/)，或某个[特定厂商的](/ecosystem/vendors/)后端。
+
+{{ if $name }}
+
+## 可用的导出器 {#available-exporters}
+
+镜像仓库中包含一份 [{{ $name }} 可用导出器的列表][reg]。
+
+{{ end }}
+
+{{ if not $name }}
+
+镜像仓库中包含[按语言分类的导出器列表][reg]。
+
+{{ end }}
+
+在所有导出器中，[OpenTelemetry 协议 (OTLP)][OTLP] 导出器是以 OpenTelemetry 数据模型为基础设计的，
+能够无信息丢失地输出 OTel 数据。此外，许多处理遥测数据的工具都支持 OTLP
+（例如 [Prometheus]、[Jaeger] 和大多数[厂商][vendors]），在你需要时为你提供高度的灵活性。
+若要了解更多关于 OTLP 的信息，请参阅 [OTLP 规范][OTLP]。
+
+[Jaeger]: /blog/2022/jaeger-native-otlp/
+[OTLP]: /docs/specs/otlp/
+[Prometheus]: https://prometheus.io/docs/prometheus/2.55/feature_flags/#otlp-receiver
+[reg]: </ecosystem/registry/?component=exporter&language={{ $lang }}>
+[vendors]: /ecosystem/vendors/
+
+{{ if $name }}
+
+本页面介绍了主要的 OpenTelemetry {{ $name }} 导出器以及如何进行配置。
+
+{{ end }}
+
+{{ if $zeroConfigPageExists }}
+
+{{% alert title=注意 %}}
+
+如果你使用了[零代码自动插桩](</docs/zero-code/{{ $langIdAsPath }}>)，
+你可以参考[配置指南](</docs/zero-code/{{ $langIdAsPath }}/configuration/>)来了解如何设置导出器。
+
+{{% /alert %}}
+
+{{ end }}
+
+{{ if $supportsOTLP }}
+
+## OTLP
+
+### Collector 设置 {#collector-setup}
+
+{{% alert title=注意 %}}
+
+如果你已经配置好 OTLP Collector 或后端，可以跳过此部分，
+直接[设置应用的 OTLP 导出器依赖](#otlp-dependencies)。
+
+{{% /alert %}}
+
+为测试和验证你的 OTLP 导出器，你可以运行一个 Docker 容器形式的 Collector，将遥测数据直接输出到控制台。
+
+在一个空目录下创建名为 `collector-config.yaml` 的文件，并添加以下内容：
+
+```yaml
+receivers:
+  otlp:
+    protocols:
+      grpc:
+        endpoint: 0.0.0.0:4317
+      http:
+        endpoint: 0.0.0.0:4318
+exporters:
+  debug:
+    verbosity: detailed
+service:
+  pipelines:
+    traces:
+      receivers: [otlp]
+      exporters: [debug]
+    metrics:
+      receivers: [otlp]
+      exporters: [debug]
+    logs:
+      receivers: [otlp]
+      exporters: [debug]
+```
+
+然后运行以下命令，在 Docker 容器中启动 Collector：
+
+```shell
+docker run -p 4317:4317 -p 4318:4318 --rm -v $(pwd)/collector-config.yaml:/etc/otelcol/config.yaml otel/opentelemetry-collector
+```
+
+现在，这个 Collector 已能通过 OTLP 接收遥测数据。
+之后你可能需要配置 Collector，将遥测数据发送到你的可观测性后端。
+
+{{ end }}

content/zh/docs/_includes/exporters/intro.md

@@ -0,0 +1,12 @@
+---
+params:
+  aResource: 进程
+default_lang_commit: 8a5b880c16d49257a147c2c3ec4a6ef6fcee8e20
+---
+
+[资源]({{ $resourceHRef }})以资源属性的形式表示产生遥测数据的实体。例如，
+{{ $aResource }} 产生的遥测数据运行在 Kubernetes 的容器中，那么它会具有
+{{ $aResource }} 的名称、Pod 名称、命名空间，可能还有部署名称。这四个属性都可以包含在资源中。
+
+在你的可观测性后端中，你可以使用资源信息来更好地调查异常行为。例如，
+如果你的追踪或指标数据表明系统中存在延迟，你可以将问题定位到特定的容器、Pod 或 Kubernetes 部署上。