Merge branch 'main' into new-getting-started

open-telemetry · Oct 10, 2024 · 10697a8 · 10697a8
2 parents a52ab44 + 99df0ae
commit 10697a8
Show file tree

Hide file tree

Showing 214 changed files with 984 additions and 225 deletions.
diff --git a/.cspell/es-palabras.txt b/.cspell/es-palabras.txt
@@ -1,2 +1,9 @@
 observabilidad
-telemetría
+telemetría
+inicialización
+configurarlo
+correlacionan
+microservicios
+extensibilidad
+correlacionarse
+deserializa
diff --git a/.gitmodules b/.gitmodules
@@ -19,7 +19,7 @@
 [submodule "content-modules/semantic-conventions"]
 	path = content-modules/semantic-conventions
 	url = https://github.com/open-telemetry/semantic-conventions
-	semconv-pin = v1.27.0
+	semconv-pin = v1.28.0
 [submodule "content-modules/opamp-spec"]
 	path = content-modules/opamp-spec
 	url = https://github.com/open-telemetry/opamp-spec

diff --git a/content-modules/semantic-conventions b/content-modules/semantic-conventions
diff --git a/content/en/docs/collector/_index.md b/content/en/docs/collector/_index.md
@@ -3,7 +3,7 @@ title: Collector
 description: Vendor-agnostic way to receive, process and export telemetry data.
 aliases: [collector/about]
 cascade:
-  vers: 0.110.0
+  vers: 0.111.0
 weight: 270
 ---
 

diff --git a/content/en/docs/collector/architecture.md b/content/en/docs/collector/architecture.md
@@ -34,8 +34,8 @@ processing (or modification), and finally to export.
 Pipelines can operate on three telemetry data types: traces, metrics, and logs.
 The data type is a property of the pipeline defined by its configuration.
 Receivers, processors, and exporters used in a pipeline must support the
-particular data type, otherwise the `ErrDataTypeIsNotSupported` exception is
-reported when the configuration loads.
+particular data type, otherwise the `pipeline.ErrSignalNotSupported` exception
+is reported when the configuration loads.
 
 The following diagram represents a typical pipeline:
 

diff --git a/content/en/docs/collector/building/receiver.md b/content/en/docs/collector/building/receiver.md
@@ -520,8 +520,8 @@ func createTracesReceiver(_ context.Context, params receiver.CreateSettings, bas
 ```
 
 You now have all the necessary components to successfully instantiate your
-receiver factory using the `receiver.NewFactory` function. Go ahead and and
-update your `NewFactory()` function in your `factory.go` file as follow:
+receiver factory using the `receiver.NewFactory` function. Go ahead and update
+your `NewFactory()` function in your `factory.go` file as follows:
 
 ```go
 // NewFactory creates a factory for tailtracer receiver.

diff --git a/content/en/docs/collector/custom-collector.md b/content/en/docs/collector/custom-collector.md
@@ -164,6 +164,13 @@ processors:
 receivers:
   - gomod:
       go.opentelemetry.io/collector/receiver/otlpreceiver {{% version-from-registry collector-receiver-otlp %}}
+
+providers:
+  - gomod: go.opentelemetry.io/collector/confmap/provider/envprovider v1.16.0
+  - gomod: go.opentelemetry.io/collector/confmap/provider/fileprovider v1.16.0
+  - gomod: go.opentelemetry.io/collector/confmap/provider/httpprovider v0.110.0
+  - gomod: go.opentelemetry.io/collector/confmap/provider/httpsprovider v0.110.0
+  - gomod: go.opentelemetry.io/collector/confmap/provider/yamlprovider v0.110.0
 ```
 
 {{% alert color="primary" title="Tip" %}}

diff --git a/content/en/docs/concepts/glossary.md b/content/en/docs/concepts/glossary.md
@@ -358,4 +358,4 @@ on web pages when requested. See [more][zpages].
 [trace]: /docs/specs/otel/overview#traces
 [tracer]: /docs/specs/otel/trace/api#tracer
 [zpages]:
-  https://github.com/open-telemetry/opentelemetry-specification/blob/main/experimental/trace/zpages.md
+  https://github.com/open-telemetry/opentelemetry-specification/blob/main/development/trace/zpages.md
diff --git a/content/en/docs/concepts/signals/traces.md b/content/en/docs/concepts/signals/traces.md
@@ -26,8 +26,8 @@ verbose.
 {
   "name": "hello",
   "context": {
-    "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2",
-    "span_id": "0x051581bf3cb55c13"
+    "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
+    "span_id": "051581bf3cb55c13"
   },
   "parent_id": null,
   "start_time": "2022-04-29T18:52:58.114201Z",
@@ -57,10 +57,10 @@ Note that it has a `trace_id` field indicating the trace, but has no
 {
   "name": "hello-greetings",
   "context": {
-    "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2",
-    "span_id": "0x5fb397be34d26b51"
+    "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
+    "span_id": "5fb397be34d26b51"
   },
-  "parent_id": "0x051581bf3cb55c13",
+  "parent_id": "051581bf3cb55c13",
   "start_time": "2022-04-29T18:52:58.114304Z",
   "end_time": "2022-04-29T22:52:58.114561Z",
   "attributes": {
@@ -96,10 +96,10 @@ that matches the `span_id` of the `hello` span.
 {
   "name": "hello-salutations",
   "context": {
-    "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2",
-    "span_id": "0x93564f51e1abe1c2"
+    "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
+    "span_id": "93564f51e1abe1c2"
   },
-  "parent_id": "0x051581bf3cb55c13",
+  "parent_id": "051581bf3cb55c13",
   "start_time": "2022-04-29T18:52:58.114492Z",
   "end_time": "2022-04-29T18:52:58.114631Z",
   "attributes": {

diff --git a/content/en/docs/demo/architecture.md b/content/en/docs/demo/architecture.md
@@ -129,7 +129,7 @@ subgraph tdf[Telemetry Data Flow]
         subgraph oc[OTel Collector]
             style oc fill:#97aef3,color:black;
             oc-grpc[/"OTLP Receiver<br/>listening on<br/>grpc://localhost:4317"/]
-            oc-http[/"OTLP Receiver<br/>listening on <br/>localhost:4318<br/>localhost:4318"/]
+            oc-http[/"OTLP Receiver<br/>listening on <br/>localhost:4318<br/>"/]
             oc-proc(Processors)
             oc-prom[/"OTLP HTTP Exporter"/]
             oc-otlp[/"OTLP Exporter"/]

diff --git a/content/en/docs/kubernetes/collector/components.md b/content/en/docs/kubernetes/collector/components.md
@@ -554,7 +554,7 @@ started.
 
 For objects configuring for pulling, the receiver will use the Kubernetes API to
 periodically list all the objects in the Cluster. Each object will be converted
-to its own log. For objects configured for watching, the receiver creates a a
+to its own log. For objects configured for watching, the receiver creates a
 stream with the Kubernetes API and which receives updates as the objects change.
 
 To see which objects are available for collection run in your cluster run

diff --git a/content/en/docs/languages/erlang/propagation.md b/content/en/docs/languages/erlang/propagation.md
@@ -25,7 +25,7 @@ propagators. By default the global propagators used are the W3C
 [Trace Context](https://w3c.github.io/trace-context/) and
 [Baggage](https://www.w3.org/TR/baggage/) formats.
 
-You can configure global propagators using the the OTP application environment
+You can configure global propagators using the OTP application environment
 variable `text_map_propagators`:
 
 {{< tabpane text=true >}} {{% tab Erlang %}}

diff --git a/content/en/docs/languages/java/performance.md b/content/en/docs/languages/java/performance.md
@@ -78,12 +78,12 @@ settings. See [Scaling](/docs/collector/scaling/).
 ## Constraints impacting the performance of the Java agent
 
 In general, the more telemetry you collect from your application, the greater
-the the impact on agent overhead. For example, tracing methods that aren't
-relevant to your application can still produce considerable agent overhead
-because tracing such methods is computationally more expensive than running the
-method itself. Similarly, high cardinality tags in metrics might increase memory
-usage. Debug logging, if turned on, also increases write operations to disk and
-memory usage.
+the impact on agent overhead. For example, tracing methods that aren't relevant
+to your application can still produce considerable agent overhead because
+tracing such methods is computationally more expensive than running the method
+itself. Similarly, high cardinality tags in metrics might increase memory usage.
+Debug logging, if turned on, also increases write operations to disk and memory
+usage.
 
 Some instrumentations, for example JDBC or Redis, produce high span volumes that
 increase agent overhead. For more information on how to turn off unnecessary

diff --git a/content/en/docs/zero-code/java/agent/instrumentation/_index.md b/content/en/docs/zero-code/java/agent/instrumentation/_index.md
@@ -43,8 +43,8 @@ For example, if set to the following:
 ```
 
 Then, requests to `1.2.3.4` will have no override for `peer.service` attribute,
-while `1.2.3.4:443` will have have `peer.service` of `cats-service` and requests
-to `dogs-abcdef123.serverlessapis.com:80/api/v1` will have an attribute of
+while `1.2.3.4:443` will have `peer.service` of `cats-service` and requests to
+`dogs-abcdef123.serverlessapis.com:80/api/v1` will have an attribute of
 `dogs-api`.
 
 {{% /config_option %}}

diff --git a/content/es/docs/concepts/context-propagation.md b/content/es/docs/concepts/context-propagation.md
@@ -0,0 +1,49 @@
+---
+title: Propagación de contexto
+weight: 10
+description: Aprende sobre el concepto que habilita el trazado distribuido.
+default_lang_commit: 4966f752eb35f97c095ed1c813972c2ab38f0b1a
+---
+
+Con la propagación de contexto, [Señales](/docs/concepts/signals) pueden
+correlacionarse entre sí, independientemente de dónde se generen. Aunque no está
+limitado a las trazas, la propagación de contexto permite que las
+[trazas](/docs/concepts/signals/traces) construyan información causal sobre un
+sistema a través de servicios que están distribuidos arbitrariamente a través de
+límites de procesos y redes.
+
+Para entender la propagación de contexto, necesitas comprender dos conceptos
+separados: contexto y propagación.
+
+## Contexto
+
+El contexto es un objeto que contiene la información para que el servicio emisor
+y receptor, o la
+[unidad de ejecución](/docs/specs/otel/glossary/#execution-unit), puedan
+correlacionar una señal con otra.
+
+Por ejemplo, si el servicio A llama al servicio B, entonces un span del servicio
+A cuyo ID está en el contexto será usado como el span padre para el próximo span
+creado en el servicio B. El ID de traza que está en el contexto también se usará
+para el siguiente span creado en el servicio B, lo que significa que el span es
+parte de la misma traza que el span del servicio A.
+
+## Propagación
+
+La propagación es el mecanismo que mueve el contexto entre servicios y procesos.
+Serializa o deserializa el objeto de contexto y proporciona la información
+relevante para ser propagada de un servicio a otro.
+
+La propagación generalmente es manejada por bibliotecas de instrumentación y es
+transparente para el usuario. En caso de que necesites propagar manualmente el
+contexto, puedes utilizar la
+[API de Propagadores](/docs/specs/otel/context/api-propagators/).
+
+OpenTelemetry mantiene varios propagadores oficiales. El propagador
+predeterminado utiliza los encabezados especificados por la especificación de
+[W3C TraceContext](https://www.w3.org/TR/trace-context/).
+
+## Especificación
+
+Para aprender más sobre la Propagación de Contexto, consulta la
+[especificación de Contexto](/docs/specs/otel/context/).
diff --git a/content/es/docs/concepts/distributions.md b/content/es/docs/concepts/distributions.md
@@ -0,0 +1,115 @@
+---
+title: Distribuciones
+description: >-
+  Una distribución, que no debe confundirse con un fork, es una versión
+  personalizada de un componente de OpenTelemetry.
+weight: 190
+default_lang_commit: 4966f752eb35f97c095ed1c813972c2ab38f0b1a
+---
+
+Los proyectos de OpenTelemetry consisten en múltiples
+[componentes](../components) que soportan múltiples [señales](../signals). La
+implementación de referencia de OpenTelemetry está disponible como:
+
+- [Bibliotecas de instrumentación específicas por lenguaje](../instrumentation)
+- Un archivo [binario de Collector](/docs/concepts/components/#collector)
+
+Cualquier implementación de referencia puede ser personalizada como una
+distribución.
+
+## ¿Qué es una distribución?
+
+Una distribución es una versión personalizada de un componente de OpenTelemetry.
+Una distribución es un envoltorio alrededor de un repositorio upstream de
+OpenTelemetry con algunas personalizaciones. Las distribuciones no deben
+confundirse con _forks_.
+
+Las personalizaciones en una distribución pueden incluir:
+
+- Scripts para facilitar el uso o personalizar el uso para un backend o
+  proveedor específico.
+- Cambios en la configuración predeterminada requeridos para un backend,
+  proveedor o usuario final.
+- Opciones de empaquetado adicionales que pueden ser específicas de un proveedor
+  o usuario final.
+- Cobertura adicional de pruebas, rendimiento y seguridad más allá de lo que
+  ofrece OpenTelemetry.
+- Capacidades adicionales más allá de lo que ofrece OpenTelemetry.
+- Menos capacidades de las que ofrece OpenTelemetry.
+
+Las distribuciones en general caen en las siguientes categorías:
+
+- **"Pura":** Estas distribuciones proporcionan la misma funcionalidad que el
+  _upstream_ y son 100% compatibles. Las personalizaciones generalmente mejoran
+  la facilidad de uso o el empaquetado. Estas personalizaciones pueden ser
+  específicas de un backend, proveedor o usuario final.
+- **"Plus":** Estas distribuciones proporcionan funcionalidades adicionales
+  sobre el upstream a través de componentes adicionales. Ejemplos incluyen
+  bibliotecas de instrumentación o exportadores de proveedores que no han sido
+  integrados al proyecto de OpenTelemetry.
+- **"Minus":** Estas distribuciones proporcionan un subconjunto de funcionalidad
+  del upstream. Ejemplos de esto incluyen la eliminación de bibliotecas de
+  instrumentación o receptores, procesadores, exportadores o extensiones que se
+  encuentran en el proyecto de OpenTelemetry Collector. Estas distribuciones
+  pueden ser proporcionadas para aumentar las consideraciones de soporte y
+  seguridad.
+
+## ¿Quién puede crear una distribución?
+
+Cualquiera puede crear una distribución. Hoy en día, varios
+[proveedores](/ecosystem/vendors/) ofrecen
+[distribuciones](/ecosystem/distributions/). Además, los usuarios finales pueden
+considerar crear una distribución si desean utilizar componentes en el
+[Registro](/ecosystem/registry/) que no han sido integrados al proyecto de
+OpenTelemetry.
+
+## ¿Contribución o distribución?
+
+Antes de seguir leyendo y aprender cómo crear tu propia distribución, pregúntate
+si tus aportes sobre un componente de OpenTelemetry serían beneficiosas para
+todos y, por lo tanto, deberían incluirse en las implementaciones de referencia:
+
+- ¿Pueden generalizarse tus scripts para "facilitar el uso"?
+- ¿Pueden tus cambios en la configuración predeterminada ser la mejor opción
+  para todos?
+- ¿Son realmente específicas tus opciones de empaquetado adicionales?
+- ¿Podrían tus coberturas adicionales de pruebas, rendimiento y seguridad
+  funcionar también con la implementación de referencia?
+- ¿Has consultado con la comunidad si tus capacidades adicionales podrían formar
+  parte del estándar?
+
+## Creando tu propia distribución
+
+### Collector
+
+Una guía sobre cómo crear tu propia distribución está disponible en este
+artículo:
+["Building your own OpenTelemetry Collector distribution"](https://medium.com/p/42337e994b63)
+
+Si estás creando tu propia distribución, el
+[OpenTelemetry Collector Builder](https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder)
+podría ser un buen punto de partida.
+
+### Bibliotecas de instrumentación específicas por lenguaje
+
+Existen mecanismos de extensibilidad específicos por lenguaje para personalizar
+las bibliotecas de instrumentación:
+
+- [Agente de Java](/docs/zero-code/java/agent/extensions)
+
+## Sigue las pautas
+
+Al usar material del proyecto OpenTelemetry, como el logotipo y el nombre para
+tu distribución, asegúrate de estar alineado con las [Pautas de Marketing de
+OpenTelemetry para Organizaciones Contribuyentes][guidelines].
+
+El proyecto OpenTelemetry no certifica distribuciones en este momento. En el
+futuro, OpenTelemetry podría certificar distribuciones y socios de manera
+similar al proyecto Kubernetes. Al evaluar una distribución, asegúrate de que
+usar la distribución no resulte en un bloqueo con el proveedor.
+
+> Cualquier soporte para una distribución proviene de los autores de la
+> distribución y no de los autores de OpenTelemetry.
+
+[guidelines]:
+  https://github.com/open-telemetry/community/blob/main/marketing-guidelines.md