From 184a5c3d342eacaceacf20f410555ddeb08978a0 Mon Sep 17 00:00:00 2001 From: Victor Date: Thu, 14 Nov 2024 01:47:40 +0100 Subject: [PATCH 1/5] Translate en-es Ref [es] Spanish folder localization docs/kubernetes #5227 --- content/es/docs/kubernetes/_index.md | 2 +- content/es/docs/kubernetes/getting-started.md | 293 +++++++++ content/es/docs/kubernetes/helm/_index.md | 22 + content/es/docs/kubernetes/helm/collector.md | 367 +++++++++++ content/es/docs/kubernetes/helm/demo.md | 58 ++ content/es/docs/kubernetes/helm/operator.md | 47 ++ content/es/docs/kubernetes/operator/_index.md | 69 ++ .../es/docs/kubernetes/operator/automatic.md | 605 ++++++++++++++++++ .../kubernetes/operator/target-allocator.md | 94 +++ 9 files changed, 1556 insertions(+), 1 deletion(-) create mode 100644 content/es/docs/kubernetes/getting-started.md create mode 100644 content/es/docs/kubernetes/helm/_index.md create mode 100644 content/es/docs/kubernetes/helm/collector.md create mode 100644 content/es/docs/kubernetes/helm/demo.md create mode 100644 content/es/docs/kubernetes/helm/operator.md create mode 100644 content/es/docs/kubernetes/operator/_index.md create mode 100644 content/es/docs/kubernetes/operator/automatic.md create mode 100644 content/es/docs/kubernetes/operator/target-allocator.md diff --git a/content/es/docs/kubernetes/_index.md b/content/es/docs/kubernetes/_index.md index 68624ff84df6..94ed9f2632c3 100644 --- a/content/es/docs/kubernetes/_index.md +++ b/content/es/docs/kubernetes/_index.md @@ -3,7 +3,7 @@ title: OpenTelemetry con Kubernetes linkTitle: Kubernetes weight: 350 description: Usando OpenTelemetry con Kubernetes -default_lang_commit: d638c386ae327328ff35604df54fa6ddd8b51b65 +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 --- ## Introducción diff --git a/content/es/docs/kubernetes/getting-started.md b/content/es/docs/kubernetes/getting-started.md new file mode 100644 index 000000000000..591c10788dac --- /dev/null +++ b/content/es/docs/kubernetes/getting-started.md @@ -0,0 +1,293 @@ +--- +title: Primeros Pasos +weight: 1 +# prettier-ignore +cSpell:ignore: filelog filelogreceiver kubelet kubeletstats kubeletstatsreceiver loggingexporter otlpexporter sattributes sattributesprocessor sclusterreceiver sobjectsreceiver +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +--- + +Esta página te guiará a través de la forma más rápida de comenzar a monitorear tu +clúster de Kubernetes utilizando OpenTelemetry. Se centrará en la recolección de métricas y +registros para clústeres de Kubernetes, nodos, pods y contenedores, así como en habilitar +el clúster para soportar servicios que emiten datos OTLP. + +Si estás buscando ver OpenTelemetry en acción con Kubernetes, el mejor lugar +para comenzar es la [OpenTelemetry Demo](/docs/demo/kubernetes-deployment/). La +demo está destinada a ilustrar la implementación de OpenTelemetry, pero no está +destinada a ser un ejemplo de cómo monitorear Kubernetes en sí. Una vez que +termines con esta guía, puede ser un experimento divertido instalar la demo y +ver cómo todo el monitoreo responde a una carga de trabajo activa. + +Si estás buscando comenzar a migrar de Prometheus a OpenTelemetry, o si +estás interesado en usar el OpenTelemetry Collector para recolectar métricas de Prometheus, +consulta [Prometheus Receiver](../collector/components/#prometheus-receiver). + +## Overview + +Kubernetes expone mucha telemetría importante de muchas maneras diferentes. Tiene +registros, eventos, métricas para muchos objetos diferentes y los datos generados por sus +cargas de trabajo. + +Para recolectar todos estos datos, utilizaremos el +[OpenTelemetry Collector](/docs/collector/). El collector tiene muchas herramientas diferentes +a su disposición que le permiten recolectar eficientemente todos estos datos y +mejorarlos de maneras significativas. + +Para recolectar todos los datos, necesitaremos dos instalaciones del collector, una como un +[Daemonset](/docs/collector/deployment/agent/) y una como un +[Deployment](/docs/collector/deployment/gateway/). La instalación del Daemonset del +collector se utilizará para recolectar telemetría emitida por servicios, registros y +métricas para nodos, pods y contenedores. La instalación de despliegue del +collector se utilizará para recolectar métricas para el clúster y eventos. + +Para instalar el collector, utilizaremos el +[OpenTelemetry Collector Helm chart](../helm/collector/), que viene con algunas +opciones de configuración que facilitarán la configuración del collector. Si no estás +familiarizado con Helm, consulta [el sitio del proyecto Helm](https://helm.sh/). Si +estás interesado en usar un operador de Kubernetes, consulta +[OpenTelemetry Operator](../operator/), pero esta guía se centrará en el Helm +chart. + +## Preparation + +Esta guía asumirá el uso de un [Kind cluster](https://kind.sigs.k8s.io/), +pero eres libre de usar cualquier clúster de Kubernetes que consideres adecuado. + +Suponiendo que ya tienes +[Kind instalado](https://kind.sigs.k8s.io/#installation-and-usage), crea un nuevo +clúster tipo: + +```sh +kind create cluster +``` + +Suponiendo que ya tiene [Helm instalado](https://helm.sh/docs/intro/install/), +Agregue el gráfico de timón de OpenTelemetry Collector para que pueda instalarse +más tarde. + +```sh +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +``` + +## Daemonset Collector + +El primer paso para recopilar la telemetría de Kubernetes es implementar un +daemonset instancia del Colector de telemetría OpenTelemetry para recopilar +telemetría relacionada con nodos y cargas de trabajo que se ejecutan en esos +nodos. Se utiliza un daemonset para garantizar que esto La instancia del +recopilador está instalada en todos los nodos. Cada instancia del El recopilador +en el daemonset recopilará datos solo del nodo en el que se encuentra corriendo. + +Esta instancia del recopilador utilizará los siguientes componentes: + +- [OTLP Receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver): + para recopilar trazas, métricas y registros de aplicaciones. +- [Kubernetes Attributes Processor](../collector/components/#kubernetes-attributes-processor): + para agregar metadatos de Kubernetes a la telemetría de la aplicación + entrante. +- [Kubeletstats Receiver](../collector/components/#kubeletstats-receiver): a + extrae métricas de nodo, pod y contenedor del servidor API en un kubelet. +- [Filelog Receiver](../collector/components/#filelog-receiver): para recopilar + Registros de Kubernetes y registros de aplicaciones escritos en stdout/stderr. + +Vamos a descomponerlos. + +### Receptor OTLP + +El +[OTLP Receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver) +es la mejor solución para recopilar trazas, métricas y registros en el +[OTLP format](/docs/specs/otel/protocol/). Si usted está emitiendo la aplicación +La telemetría en otro formato, hay una buena posibilidad de que +[the Collector has a receiver for it](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver), +pero para este tutorial asumiremos que la telemetría está formateada en OTLP. + +Aunque no es un requisito, es una práctica común para las aplicaciones que se +ejecutan en Un nodo para emitir sus trazas, métricas y registros a un +recopilador que se ejecuta en el el mismo nodo. Esto mantiene las interacciones +de red simples y permite una fácil correlación de Metadatos de Kubernetes usando +el atributo `k8sattribute` + +El [Kubeletstats Receiver](../collector/components/#kubeletstats-receiver) es El +receptor que reúne métricas sobre el nodo. Recopilará métricas como Uso de la +memoria del contenedor, uso de la CPU del pod y errores de red de nodos. Todos +los La telemetría incluye metadatos de Kubernetes como el nombre del pod o el +nombre del nodo. Ya que estamos mediante el procesador de atributos de +Kubernetes, podremos correlacionar nuestros rastreos, métricas y registros de +aplicaciones con las métricas producidas por el Receptor Kubeletstats. + +### Receptor de registro de archivos + +El [Filelog Receiver](../collector/components/#filelog-receiver) recogerá +registros escritos en stdout/stderr siguiendo los registros en los que +Kubernetes escribe `/var/log/pods/*/*/*.log`. Al igual que la mayoría de los +registros de seguimiento, el receptor de registro de archivos proporciona Un +conjunto robusto de acciones que le permiten analizar el archivo como lo +necesite. + +Es posible que algún día necesite configurar un receptor de registro de archivos +por su cuenta, pero para esto Un recorrido por el gráfico de timón de +OpenTelemetry se encargará de todo el complejo configuración para usted. Además, +extraerá metadatos útiles de Kubernetes Basado en el nombre del archivo. Ya que +estamos usando el procesador de atributos de Kubernetes, Podremos correlacionar +las trazas, métricas y registros de la aplicación con el registros producidos +por el receptor Filelog. + +--- + +El gráfico del timón del colector de OpenTelemetry hace que se configuren todos +estos componentes En un daemonset la instalación del colector es fácil. También +se encargará de todo de los detalles específicos de Kubernetes, como RBAC, +montajes y puertos host. + +Una advertencia: el gráfico no envía los datos a ningún backend de forma +predeterminada. Si usted Si realmente quieres usar tus datos en tu backend +favorito, tendrás que configurarlo un exportador. + +Lo que usaremos es el siguiente `values.yaml` + +```yaml +mode: daemonset + +image: + repository: otel/opentelemetry-collector-k8s + +presets: + +# Habilita el procesador K8Sattributes y lo agrega a las tuberías de rastreo, métricas y registros + +kubernetesAttributes: + enabled: true + +# Habilita el receptor KubeletstatsReceiver y lo agrega a las canalizaciones de métricas + +kubeletMetrics: + enabled: true + +# Habilita el receptor de archivos y lo agrega a las canalizaciones de registros + +logsCollection: + enabled: true +# El gráfico solo incluye el exportador de tala por defecto + +# Si desea enviar sus datos a algún lugar, debe + +# Configurar un exportador, como el otlexportador + +# configuración: +# exportadores: +# Ayuda: +# Punto final: "" +# servicio: +# tuberías: +# trazas: +# Exportadores: [ otlp ] +# Métricas: +# Exportadores: [ otlp ] +# registros: +# Exportadores: [ otlp ] +``` + +Para usar este `values.yaml` con el gráfico, guárdelo en su archivo preferido y, +a continuación, ejecute el siguiente comando para instalar el gráfico + +```sh +helm install otel-collector open-telemetry/opentelemetry-collector --values +``` + +Ahora debería tener una instalación de daemonset del Colector de telemetría +abierta Ejecutándose en el clúster recopilando telemetría de cada nodo. + +## Deployment Collector + +El siguiente paso para recopilar la telemetría de Kubernetes es implementar una +implementación instancia del Coleccionista para reunir telemetría relacionada +con el cúmulo en su conjunto. + +Una implementación con exactamente una réplica garantiza que no se produzcan +duplicados datos. + +Esta instancia del Recopilador utilizará los siguientes componentes: + +- [Kubernetes Cluster Receiver](../collector/components/#kubernetes-cluster-receiver):para + recopilar métricas de nivel de clúster y eventos de entidad. + +- [Kubernetes Objects Receiver](../collector/components/#kubernetes-objects-receiver):para + recopilar objetos, como eventos, del servidor API de Kubernetes. + +Vamos a descomponerlos. + +### Kubernetes Cluster Receiver + +El +[Kubernetes Cluster Receiver](../collector/components/#kubernetes-cluster-receiver) +es la solución del Coleccionista para recopilar métricas sobre el estado del +grupo en conjunto. Este receptor puede recopilar métricas sobre las condiciones +del nodo, pod fases, reinicios de contenedores, implementaciones disponibles y +deseadas, y más. + +### Kubernetes Objects Receiver + +El +[Kubernetes Objects Receiver](../collector/components/#kubernetes-objects-receiver) +es la solución del Coleccionista para recolectar objetos de Kubernetes como +registros. Aunque Cualquier objeto puede ser recogido, un caso de uso común e +importante es recoger Eventos de Kubernetes. + +--- + +El gráfico de timón de OpenTelemetry Collector optimiza la configuración de +todos los estos componentes en una instalación de implementación del Collector. +También Cuide todos los detalles específicos de Kubernetes, como RBAC y +montajes. + +Una advertencia: el gráfico no envía los datos a ningún backend de forma +predeterminada. Si usted Si realmente quieres usar tus datos en tu backend +preferido, tendrás que Configure un exportador usted mismo. + +Lo que usaremos es el siguiente `values.yaml`: + +```yaml +mode: deployment + +image: + repository: otel/opentelemetry-collector-k8s + + # Solo queremos uno de estos recolectores - más y produciríamos datos duplicados +replicaCount: 1 + +presets: +# Habilita K8Sclusterreceiver y lo agrega a las canalizaciones de métricas + +clusterMetrics: + enabled: true + # Permite que K8sobjectsreceiver recopile eventos únicamente y los agregue a las canalizaciones de logs +kubernetesEvents: + enabled: true +## El gráfico solo incluye el exportador de registro de forma predeterminada +## Si desea enviar sus datos a algún lugar, debe +## Configurar un exportador, como el otlexportador + +# configuración: +# exportadores: +# Ayuda: +# Punto final: "" +# servicio: +# tuberías: +# trazas: +# Exportadores: [ otlp ] +# Métricas: +# Exportadores: [ otlp ] +# registros: +# Exportadores: [ otlp ] +``` + +Para usar este `values.yaml` con el gráfico, guárdelo en su archivo preferido y, +a continuación, ejecute el siguiente comando para instalar el gráfico: + +```sh +helm install otel-collector-cluster open-telemetry/opentelemetry-collector --values +``` + +Ahora debería tener una instalación de implementación del recopilador +ejecutándose en su clúster que recopila métricas y eventos de clúster diff --git a/content/es/docs/kubernetes/helm/_index.md b/content/es/docs/kubernetes/helm/_index.md new file mode 100644 index 000000000000..f5fd42f26b3a --- /dev/null +++ b/content/es/docs/kubernetes/helm/_index.md @@ -0,0 +1,22 @@ +--- +Title: Gráficos de Helm de OpenTelemetry +linkTitle: Gráficos de Helm +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +--- + +## Introducción + +[Helm](https://helm.sh/) es una solución CLI para administrar aplicaciones de +Kubernetes. + +Si eligió usar Helm, puede usar [OpenTelemetry Helm Charts] +(https://github.com/open-telemetry/opentelemetry-helm-charts) para gestionar las +instalaciones del [OpenTelemetry Collector](/docs/collector), +[OpenTelemetry Operator](/docs/kubernetes/operator), y +[OpenTelemetry Demo](/docs/demo). + +Agregue el repositorio OpenTelemetry Helm con: + +```sh +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +``` diff --git a/content/es/docs/kubernetes/helm/collector.md b/content/es/docs/kubernetes/helm/collector.md new file mode 100644 index 000000000000..05357bf51098 --- /dev/null +++ b/content/es/docs/kubernetes/helm/collector.md @@ -0,0 +1,367 @@ +--- +title: Gráfico de coleccionista de OpenTelemetry +linkTitle: Gráfico de recopiladores +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +# prettier-ignore +cSpell:ignore: debugexporter filelogio filelogreceiver hostmetricsreceiver kubelet kubeletstats kubeletstatsreceiver otlphttp sattributesprocessor sclusterreceiver sobjectsreceiver statefulset +--- + +## Introducción + +El [OpenTelemetry Collector](/docs/collector) es una herramienta importante para +supervisar un clúster de Kubernetes y todos los servicios que se encuentran en +él. Para facilitar la instalación y la gestión de una implementación de +recopiladores en una red Kubernetes la comunidad OpenTelemetry creó el +[OpenTelemetry Collector Helm Chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-collector). +Este gráfico de timón se puede utilizar para instalar un recopilador como +Deployment, Daemonset, o Statefulset. + +### Instalación del gráfico + +Para instalar el gráfico con el nombre de la versión +`my-opentelemetry-collector`, ejecute el comandos siguientes: + +```sh +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm install my-opentelemetry-collector open-telemetry/opentelemetry-collector \ + --set image.repository="otel/opentelemetry-collector-k8s" \ + --set mode= \ +``` + +### Configuración + +El gráfico de recopiladores de OpenTelemetry requiere que mode esté establecido. mode puede ser daemonset, deployment o statefulset dependiendo de qué tipo de La implementación de Kubernetes requiere su caso de uso. + +Cuando se instala, el gráfico proporciona algunos componentes de recopilador predeterminados para obtener Empezó. De forma predeterminada, la configuración del recopilador tendrá el siguiente aspecto: + +```yaml +exporters: + # NOTA: Antes de v0.86.0, use el registro(login) en lugar de la depuración(debug). + debug: {} +extensions: + health_check: {} +processors: + batch: {} + memory_limiter: + check_interval: 5s + limit_percentage: 80 + spike_limit_percentage: 25 +receivers: + jaeger: + protocols: + grpc: + endpoint: ${env:MY_POD_IP}:14250 + thrift_compact: + endpoint: ${env:MY_POD_IP}:6831 + thrift_http: + endpoint: ${env:MY_POD_IP}:14268 + otlp: + protocols: + grpc: + endpoint: ${env:MY_POD_IP}:4317 + http: + endpoint: ${env:MY_POD_IP}:4318 + prometheus: + config: + scrape_configs: + - job_name: opentelemetry-collector + scrape_interval: 10s + static_configs: + - targets: + - ${env:MY_POD_IP}:8888 + zipkin: + endpoint: ${env:MY_POD_IP}:9411 +service: + extensions: + - health_check + pipelines: + logs: + exporters: + - debug + processors: + - memory_limiter + - batch + receivers: + - otlp + metrics: + exporters: + - debug + processors: + - memory_limiter + - batch + receivers: + - otlp + - prometheus + traces: + exporters: + - debug + processors: + - memory_limiter + - batch + receivers: + - otlp + - jaeger + - zipkin + telemetry: + metrics: + address: ${env:MY_POD_IP}:8888 +``` + +El gráfico también habilitará puertos basados en los receptores predeterminados. Predeterminado La configuración se puede eliminar estableciendo el valor en +`null` en su `values.yaml`. Los puertos también se pueden deshabilitar en +`values.yaml`. + +Puede agregar/modificar cualquier parte de la configuración utilizando la sección `config` en Tus `values.yaml`. Al cambiar una canalización, debe enumerar explícitamente todas las componentes que están en la canalización, incluidos los componentes predeterminados. + +Por ejemplo, para deshabilitar las métricas y las canalizaciones de registro y los receptores no superiores: + +```yaml +config: + receivers: + jaeger: null + prometheus: null + zipkin: null + service: + pipelines: + traces: + receivers: + - otlp + metrics: null + logs: null +ports: + jaeger-compact: + enabled: false + jaeger-thrift: + enabled: false + jaeger-grpc: + enabled: false + zipkin: + enabled: false +``` + +Todas las opciones de configuración (con comentarios) disponibles en el gráfico pueden ser visto en su +[values.yaml file](https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-collector/values.yaml). + +### Ajustes preestablecidos + +Muchos de los componentes importantes que el Colector de telemetría OpenTelemetry utiliza para monitorizar Kubernetes requiere una configuración especial en la propia implementación de Kubernetes del Coleccionista. Para facilitar el uso de estos componentes, el Colector de telemetría abierta El gráfico viene con algunos ajustes preestablecidos que, cuando están habilitados, manejan la configuración compleja para estos importantes componentes. + +Los ajustes preestablecidos deben utilizarse como punto de partida. Configuran básico, pero rico, funcionalidad para sus componentes relacionados. Si su caso de uso requiere extra configuración de estos componentes se recomienda NO utilizar el ajuste preestablecido y en su lugar, configure manualmente el componente y cualquier cosa que requiera (volúmenes, RBAC, etc.). + +#### Configuración preestablecida de la colección de registros + +El Colector de telemetría OpenTelemetry se puede utilizar para recopilar los registros enviados a la salida estándar por contenedores Kubernetes. + +Esta característica está deshabilitada de forma predeterminada. Tiene los siguientes requisitos en orden Para habilitar de forma segura: + +- Requiere el + [Filelog receiver](/docs/kubernetes/collector/components/#filelog-receiver) + incluidos en la imagen del Coleccionista, como el + [Contrib distribution of the Collector](https://github.com/open-telemetry/opentelemetry-collector-releases/pkgs/container/opentelemetry-collector-releases%2Fopentelemetry-collector-contrib). +- Aunque no es un requisito estricto, se recomienda que este ajuste preestablecido se utilice con `mode=daemonset`. El `filelogreceiver` solo podrá recopilar registros en el nodo en el que se ejecuta el recopilador y varios recopiladores configurados en el El mismo nodo producirá datos duplicados + +Para habilitar esta característica, establezca la propiedad +`presets.logsCollection.enabled` en `true`. Cuando está habilitado, el gráfico agregará un `filelogreceiver` a los `logs` tubería. Este receptor está configurado para leer los archivos donde Kubernetes Container Runtime escribe la salida de la consola de todos los contenedores (`/var/log/pods/*/*/*.log`). + +Aquí hay un ejemplo `values.yaml`: + +```yaml +mode: daemonset +presets: + logsCollection: + enabled: true +``` + +La canalización de registros predeterminada del gráfico utiliza el +`debugexporter`. Emparejado con el `logsCollection` preset `filelogreceiver` es fácil alimentar accidentalmente el exportó registros de nuevo en el recopilador, lo que puede causar una "explosión de registro". + +Para evitar el bucle, la configuración predeterminada del receptor excluye el Registros del propio coleccionista. Si desea incluir los registros del recopilador, asegúrese de Reemplace el exportador `debug` por un exportador que +no envíe registros a Salida estándar del colector. + +Aquí hay un ejemplo `values.yaml` que reemplaza el exportador `debug` +predeterminado en La canalización `logs` con un exportador `otlphttp` que envía +los registros del contenedor a `https://example.com:55681` punto final. También +utiliza `presets.logsCollection.includeCollectorLogs` para indicar al preset que +habilite Colección de los registros del coleccionista. + +```yaml +mode: daemonset + +presets: + logsCollection: + enabled: true + includeCollectorLogs: true + +config: + exporters: + otlphttp: + endpoint: https://example.com:55681 + service: + pipelines: + logs: + exporters: + - otlphttp +``` + +#### Atributos preestablecidos de Kubernetes + +El recopilador de OpenTelemetry se puede configurar para agregar metadatos de +Kubernetes, como como `k8s.pod.name`, `k8s.namespace.name` y `k8s.node.name`, a +los registros, métricas y rastros. Se recomienda encarecidamente utilizar el +ajuste preestablecido o habilitar el `k8sattributesprocessor` manualmente. + +Debido a consideraciones de RBAC, esta característica está deshabilitada de +forma predeterminada. Tiene el los siguientes requisitos: + +- Requiere el + [Kubernetes Attributes processor](/docs/kubernetes/collector/components/#kubernetes-attributes-processor) + se incluirán en la imagen del Coleccionista, como el + [Contrib distribution of the Collector](https://github.com/open-telemetry/opentelemetry-collector-releases/pkgs/container/opentelemetry-collector-releases%2Fopentelemetry-collector-contrib). + +Para habilitar esta característica, establezca la propiedad +`presets.kubernetesAttributes.enabled` a `true`. Cuando está habilitado, el +gráfico agregará los roles RBAC necesarios al ClusterRole y agregará un +`k8sattributesprocessor` a cada canalización habilitada. + +Aquí hay un ejemplo `values.yaml`: + +```yaml +mode: daemonset +presets: + kubernetesAttributes: + enabled: true +``` + +#### Métricas de Kubelet preestablecidas + +El Colector de telemetría abierta se puede configurar para recopilar nodos, pods y métricas de contenedor del servidor API en un kubelet. + +Esta característica está deshabilitada de forma predeterminada. Tiene los siguientes requisitos: + +- Requiere el + [Kubeletstats receiver](/docs/kubernetes/collector/components/#kubeletstats-receiver) + se incluirán en la imagen del Coleccionista, como el + +- [Contrib distribution of the Collector](https://github.com/open-telemetry/opentelemetry-collector-releases/pkgs/container/opentelemetry-collector-releases%2Fopentelemetry-collector-contrib). +- Aunque no es un requisito estricto, se recomienda que este ajuste + preestablecido se utilice con `mode=daemonset`. El `kubeletstatsreceiver` solo + podrá recoger métricas en el nodo en el que se está ejecutando el recopilador + y múltiples configuraciones Los recopiladores del mismo nodo producirán datos + duplicados. + +Para habilitar esta característica, establezca la propiedad +`presets.kubeletMetrics.enabled` en `true`. Cuando está habilitado, el gráfico +agregará los roles RBAC necesarios al ClusterRole y agregará un +`kubeletstatsreceiver` a la canalización de métricas. + +Aquí hay un ejemplo `values.yaml`: + +```yaml +mode: daemonset +presets: + kubeletMetrics: + enabled: true +``` + +#### Métricas de clúster preestablecidas + +El recopilador de OpenTelemetry se puede configurar para recopilar métricas de nivel de clúster desde el servidor API de Kubernetes. Estas métricas incluyen muchas de ellas recopilado por Kube State Metrics. + +Esta característica está deshabilitada de forma predeterminada. Tiene los siguientes requisitos: + +- Requiere el + [Receptor de clúster de Kubernetes](/docs/kubernetes/collector/components/#kubernetes-cluster-receiver) + se incluirán en la imagen del Coleccionista, como el + [Distribución de Contrib del Coleccionista](https://github.com/open-telemetry/opentelemetry-collector-releases/pkgs/container/opentelemetry-collector-releases%2Fopentelemetry-collector-contrib). +- Aunque no es un requisito estricto, se recomienda que este ajuste + preestablecido se utilice con `mode=deployment` o `mode=statefulset` con una + única réplica. Correr `k8sclusterreceiver` en varios colectores producirá + datos duplicados. + +Para habilitar esta característica, establezca la propiedad +`presets.clusterMetrics.enabled` en `verdadero`. Cuando está habilitado, el +gráfico agregará los roles RBAC necesarios al ClusterRole y agregará un +`k8sclusterreceiver` a la canalización de métricas. + +Aquí hay un ejemplo `values.yaml`: + +```yaml +mode: deployment +replicaCount: 1 +presets: + clusterMetrics: + enabled: true +``` + +#### Eventos preestablecidos de Kubernetes + +El Colector de telemetría abierta se puede configurar para recopilar eventos de Kubernetes. + +Esta característica está deshabilitada de forma predeterminada. Tiene los siguientes requisitos: + +- Requiere el + [Receptor de objetos Kubernetes](/docs/kubernetes/collector/components/#kubernetes-objects-receiver) + se incluirán en la imagen del Coleccionista, como el + [Distribución de Contrib del Coleccionista](https://github.com/open-telemetry/opentelemetry-collector-releases/pkgs/container/opentelemetry-collector-releases%2Fopentelemetry-collector-contrib). +- Aunque no es un requisito estricto, se recomienda que este ajuste + preestablecido se utilice con `mode=deployment` o `mode=statefulset` con una + única réplica. Correr `k8sclusterreceiver` en varios colectores producirá + datos duplicados. + +Para habilitar esta característica, establezca la propiedad +`presets.kubernetesEvents.enabled` en `true`. Cuando está habilitado, el gráfico +agregará los roles RBAC necesarios al ClusterRole y agregará un +`k8sobjectsreceiver` a la configuración de la canalización de registros a solo +eventos de recopilador. + +Aquí hay un ejemplo `values.yaml`: + +```yaml +mode: deployment +replicaCount: 1 +presets: + kubernetesEvents: + enabled: true +``` + +#### Métricas de host preestablecidas + +El recopilador de telemetría abierta se puede configurar para recopilar métricas de host desde Nodos de Kubernetes. + +Esta característica está deshabilitada de forma predeterminada. Tiene los siguientes requisitos: + +- Requiere el + [Host Metrics receiver](/docs/kubernetes/collector/components/#host-metrics-receiver) + se incluirán en la imagen del Coleccionista, como el + [Distribución de Contrib del Coleccionista](https://github.com/open-telemetry/opentelemetry-collector-releases/pkgs/container/opentelemetry-collector-releases%2Fopentelemetry-collector-contrib). +- Aunque no es un requisito estricto, se recomienda que este ajuste + preestablecido se utilice con `mode=daemonset`. El `hostmetricsreceiver` solo + podrá recolectar métricas en el nodo en el que se está ejecutando el + recopilador y múltiples configuraciones Los recopiladores del mismo nodo + producirán datos duplicados. + +Para habilitar esta característica, establezca la propiedad +`presets.hostMetrics.enabled` en `verdadero`. Cuando está habilitado, el gráfico +agregará los volúmenes necesarios y volumeMounts y agregará un +`hostmetricsReceiver` a la canalización de métricas. Métricas predeterminadas se +desguazarán cada 10 segundos y se habilitarán los siguientes desguazadores: + +- CPU +- Cargar +- memoria +- disco +- sistema de archivos[^1] +- red + +Aquí hay un ejemplo `values.yaml`: + +```yaml +mode: daemonset +presets: + hostMetrics: + enabled: true +``` + +[^1] debido a alguna superposición con el preajuste `kubeletMetrics` de algunos +tipos de sistema de archivos y los puntos de montaje se excluyen de forma +predeterminada. diff --git a/content/es/docs/kubernetes/helm/demo.md b/content/es/docs/kubernetes/helm/demo.md new file mode 100644 index 000000000000..d6cf13dd2c0f --- /dev/null +++ b/content/es/docs/kubernetes/helm/demo.md @@ -0,0 +1,58 @@ +--- +title: Gráfico de demostración de OpenTelemetry +linkTitle: Gráfico de demostración +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +--- + +La [OpenTelemetry Demo](/docs/demo/) es un sistema distribuido basado en microservicios +destinado a ilustrar la implementación de OpenTelemetry en un entorno cercano al real. +Como parte de ese esfuerzo, la comunidad de OpenTelemetry creó el +[OpenTelemetry Demo Helm Chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-demo) +para que pueda ser instalado fácilmente en Kubernetes. + +## Configuración + +El `values.yaml` predeterminado del chart de Demo está listo para ser instalado. Todos +los componentes han tenido sus límites de memoria ajustados para optimizar el rendimiento, lo que puede +causar problemas si tu clúster no es lo suficientemente grande. La instalación completa está +restringida a ~4 Gigabytes de memoria, pero puede usar menos. + +Todas las opciones de configuración (con comentarios) disponibles en el chart se pueden +ver en su +[`values.yaml` file](https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-demo/values.yaml), +y las descripciones detalladas se pueden encontrar en el +[README del chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-demo#chart-parameters). + +## Instalación + +Para instalar el chart con el nombre de lanzamiento `my-otel-demo`, ejecuta el siguiente +comando: + +```sh +helm install my-otel-demo open-telemetry/opentelemetry-demo +``` + +Una vez instalado, todos los servicios están disponibles a través del proxy Frontend (http://localhost:8080) ejecutando estos comandos: + +```sh +kubectl port-forward svc/my-otel-demo-frontendproxy 8080:8080 +``` + +Una vez que el proxy esté expuesto, también puedes visitar las siguientes rutas + +| Componente | Ruta | +| ----------------- | --------------------------------- | +| Tienda web | | +| Grafana | | +| Interfaz de Flags | | +| Interfaz de Carga | | +| Interfaz de Jaeger | | + +Para que los spans de la tienda web sean recolectados, debes exponer el receptor OTLP/HTTP del OpenTelemetry Collector: + +```sh +kubectl port-forward svc/my-otel-demo-otelcol 4318:4318 +``` + +Para más detalles sobre el uso de la demo en Kubernetes, consulta +[Kubernetes deployment](/docs/demo/kubernetes-deployment/). diff --git a/content/es/docs/kubernetes/helm/operator.md b/content/es/docs/kubernetes/helm/operator.md new file mode 100644 index 000000000000..bcd871af63b6 --- /dev/null +++ b/content/es/docs/kubernetes/helm/operator.md @@ -0,0 +1,47 @@ +--- +title: Gráfico del operador de OpenTelemetry +linkTitle: Gráfico del operador +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +--- + +## Introducción + +El [OpenTelemetry Operator](/docs/kubernetes/operator) es un operador de Kubernetes +que gestiona [OpenTelemetry Collectors](/docs/collector) y +la auto-instrumentación de cargas de trabajo. Una de las formas de instalar el OpenTelemetry +Operator es a través del +[OpenTelemetry Operator Helm Chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator). + +Para un uso detallado del OpenTelemetry Operator, visita su +[docs](/docs/kubernetes/operator). + +### Instalación del Chart + +Para instalar el chart con el nombre de lanzamiento `my-opentelemetry-operator`, ejecuta los +siguientes comandos: + +```console +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm install my-opentelemetry-operator open-telemetry/opentelemetry-operator \ + --set "manager.collectorImage.repository=otel/opentelemetry-collector-k8s" \ + --set admissionWebhooks.certManager.enabled=false \ + --set admissionWebhooks.autoGenerateCert.enabled=true +``` + +Esto instalará un OpenTelemetry Operator con un certificado autofirmado y un secreto. + +### Configuración + +El `values.yaml` predeterminado del chart del Operator está listo para ser instalado, pero se espera que Cert Manager ya esté presente en el clúster. + +En Kubernetes, para que el servidor API se comunique con el componente webhook, el webhook requiere un certificado TLS que el servidor API esté configurado para confiar. Hay varias formas diferentes que puedes usar para generar/configurar el certificado TLS requerido. + +- El método más fácil y predeterminado es instalar el [cert-manager](https://cert-manager.io/docs/) y establecer `admissionWebhooks.certManager.create` en `true`. De esta manera, cert-manager generará un certificado autofirmado. Consulta [cert-manager installation](https://cert-manager.io/docs/installation/kubernetes/) para más detalles. +- Puedes proporcionar tu propio Emisor configurando el valor `admissionWebhooks.certManager.issuerRef`. Necesitarás especificar el `kind` (Issuer o ClusterIssuer) y el `name`. Ten en cuenta que este método también requiere la instalación de cert-manager. +- Puedes usar un certificado autofirmado generado automáticamente estableciendo `admissionWebhooks.certManager.enabled` en `false` y `admissionWebhooks.autoGenerateCert.enabled` en `true`. Helm creará un certificado autofirmado y un secreto para ti. +- Puedes usar tu propio certificado autofirmado generado estableciendo ambos `admissionWebhooks.certManager.enabled` y `admissionWebhooks.autoGenerateCert.enabled` en `false`. Debes proporcionar los valores necesarios a `admissionWebhooks.cert_file, admissionWebhooks.key_file` y `admissionWebhooks.ca_file`. +- Puedes cargar webhooks y certificados personalizados desactivando .`Values.admissionWebhooks.create` y `admissionWebhooks.certManager.enabled` mientras estableces el nombre de tu secreto de certificado personalizado en `admissionWebhooks.secretName`. +- Puedes desactivar los webhooks por completo desactivando .`Values.admissionWebhooks.create` y estableciendo la variable de entorno .`Values.manager.env.ENABLE_WEBHOOKS` en `false`. + +Todas las opciones de configuración (con comentarios) disponibles en el chart se pueden ver en su +[values.yaml file](https://github.com/open-telemetry/opentelemetry-helm-charts/blob/main/charts/opentelemetry-operator/values.yaml). diff --git a/content/es/docs/kubernetes/operator/_index.md b/content/es/docs/kubernetes/operator/_index.md new file mode 100644 index 000000000000..358a13b556a5 --- /dev/null +++ b/content/es/docs/kubernetes/operator/_index.md @@ -0,0 +1,69 @@ +--- +title: OpenTelemetry Operator para Kubernetes +linkTitle: Operador de Kubernetes +description: + Una implementación de un Operador de Kubernetes, que gestiona coleccionistas y la auto-instrumentación de la carga de trabajo utilizando las bibliotecas de instrumentación de OpenTelemetry. +aliases: + - /docs/operator + - /docs/k8s-operator + - /docs/kubernetes-operator +redirects: + - { from: /docs/operator/*, to: ':splat' } + - { from: /docs/k8s-operator/*, to: ':splat' } + - { from: /docs/kubernetes-operator/*, to: ':splat' } +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +--- + +## Introducción + +El OpenTelemetry Operator es una implementación de un +[Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/). + +El operador gestiona: + +- OpenTelemetry Collector +- [auto-instrumentation of the workloads using OpenTelemetry instrumentation libraries](https://github.com/open-telemetry/opentelemetry-operator#opentelemetry-auto-instrumentation-injection) + +## Empezando + +Para instalar el operador en un clúster existente, asegúrate de tener cert-manager +instalado y ejecuta: + +```bash +kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml +``` + +Una vez que el despliegue `opentelemetry-operator` esté listo, crea una instancia de OpenTelemetry Collector (otelcol), como: + +```console +$ kubectl apply -f - < Si deseas usar la auto-instrumentación de Go, necesitas habilitar la puerta de +> características. Consulta +> [Controlando las capacidades de instrumentación](https://github.com/open-telemetry/opentelemetry-operator#controlling-instrumentation-capabilities) +> para más detalles. + +## Crear un OpenTelemetry Collector (Opcional) + +Es una buena práctica enviar telemetría desde contenedores a un +[OpenTelemetry Collector](../../collector/) en lugar de directamente a un backend. +El Collector ayuda a simplificar la gestión de secretos, desacopla los problemas de exportación de datos +(como la necesidad de hacer reintentos) de tus aplicaciones, y te permite agregar datos adicionales +a tu telemetría, como con el +[k8sattributesprocessor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/k8sattributesprocessor) +componente. Si decides no usar un Collector, puedes saltar a la siguiente +sección. + +El operador proporciona una +[Definición de Recurso Personalizado (CRD) para el OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-operator/blob/main/docs/api.md#opentelemetrycollector) +que se utiliza para crear una instancia del Collector que el operador gestiona. +El siguiente ejemplo despliega el Collector como un despliegue (el predeterminado), pero +hay otros +[módulos de despliegue](https://github.com/open-telemetry/opentelemetry-operator#deployment-modes) +que se pueden usar. + +Al usar el modo `Deployment`, el operador también creará un servicio que +se puede usar para interactuar con el Collector. El nombre del servicio es el nombre +del recurso `OpenTelemetryCollector` precedido por `-collector`. Para nuestro +ejemplo, será `demo-collector`. + +```bash +kubectl apply -f - < A partir de la versión v0.67.0 del operador, el recurso de Instrumentación establece automáticamente +> `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` y `OTEL_EXPORTER_OTLP_METRICS_PROTOCOL` +> en `http/protobuf` para los servicios de Python. Si usas una versión anterior del +> O operador, **DEBES** establecer estas variables de entorno en `http/protobuf`, +> o la auto-instrumentación de Python no funcionará. + +#### Auto-instrumentando registros de Python + +Por defecto, la auto-instrumentación de registros de Python está deshabilitada. Si deseas habilitar esta función, debes establecer las variables de entorno `OTEL_LOGS_EXPORTER` y `OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED` de la siguiente manera: + +```yaml +apiVersion: opentelemetry.io/v1alpha1 +kind: Instrumentation +metadata: + name: python-instrumentation + namespace: application +spec: + exporter: + endpoint: http://demo-collector:4318 + env: + propagators: + - tracecontext + - baggage + python: + env: + - name: OTEL_LOGS_EXPORTER + value: otlp_proto_http + - name: OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED + value: 'true' +``` + +> Ten en cuenta que `OTEL_LOGS_EXPORTER` debe establecerse explícitamente en `otlp_proto_http`, de lo contrario, +> se predetermina a gRPC. + +#### Excluyendo la auto-instrumentación {#python-excluding-auto-instrumentation} + +Por defecto, la auto-instrumentación de Python se envía con +[muchas bibliotecas de instrumentación](https://github.com/open-telemetry/opentelemetry-operator/blob/main/autoinstrumentation/python/requirements.txt). + Esto facilita la instrumentación, pero puede resultar en demasiados datos o datos no deseados. Si hay paquetes que no deseas instrumentar, puedes establecer la variable de entorno `OTEL_PYTHON_DISABLED_INSTRUMENTATIONS`. + +```yaml +apiVersion: opentelemetry.io/v1alpha1 +kind: Instrumentation +metadata: + name: demo-instrumentation +spec: + exporter: + endpoint: http://demo-collector:4318 + propagators: + - tracecontext + - baggage + sampler: + type: parentbased_traceidratio + argument: '1' + python: + env: + - name: OTEL_PYTHON_DISABLED_INSTRUMENTATIONS + value: + +``` + +Consulta la +[documentación de configuración del agente de Python](/docs/zero-code/python/configuration/#disabling-specific-instrumentations) + para más detalles. + +#### Aprende más {#python-learn-more} + +Para peculiaridades específicas de Python, consulta +[documentación del operador de OpenTelemetry para Python](/docs/zero-code/python/operator/#python-specific-topics) + y la +[documentación de configuración del agente de Python](/docs/zero-code/python/configuration/). + +### Go + +El siguiente comando crea un recurso de Instrumentación básico que está configurado específicamente para instrumentar servicios de Go. + +```bash +kubectl apply -f - <` es el espacio de nombres en el que se despliega el recurso de `Instrumentation`: + +```sh +kubectl describe otelinst -n +``` + +Salida de ejemplo: + +```yaml +Name: python-instrumentation +Namespace: application +Labels: app.kubernetes.io/managed-by=opentelemetry-operator +Annotations: instrumentation.opentelemetry.io/default-auto-instrumentation-apache-httpd-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd:1.0.3 + instrumentation.opentelemetry.io/default-auto-instrumentation-dotnet-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-dotnet:0.7.0 + instrumentation.opentelemetry.io/default-auto-instrumentation-go-image: + ghcr.io/open-telemetry/opentelemetry-go-instrumentation/autoinstrumentation-go:v0.2.1-alpha + instrumentation.opentelemetry.io/default-auto-instrumentation-java-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:1.26.0 + instrumentation.opentelemetry.io/default-auto-instrumentation-nodejs-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-nodejs:0.40.0 + instrumentation.opentelemetry.io/default-auto-instrumentation-python-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.39b0 +API Version: opentelemetry.io/v1alpha1 +Kind: Instrumentation +Metadata: + Creation Timestamp: 2023-07-28T03:42:12Z + Generation: 1 + Resource Version: 3385 + UID: 646661d5-a8fc-4b64-80b7-8587c9865f53 +Spec: +... + Exporter: + Endpoint: http://demo-collector.opentelemetry.svc.cluster.local:4318 +... + Propagators: + tracecontext + baggage + Python: + Image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.39b0 + Resource Requirements: + Limits: + Cpu: 500m + Memory: 32Mi + Requests: + Cpu: 50m + Memory: 32Mi + Resource: + Sampler: +Events: +``` + +### ¿Los registros del OTel Operator muestran algún error de auto-instrumentación? + +Verifica los registros del OTel Operator en busca de errores relacionados con la auto-instrumentación ejecutando este comando: + +```sh +kubectl logs -l app.kubernetes.io/name=opentelemetry-operator --container manager -n opentelemetry-operator-system --follow +``` + +### ¿Se desplegaron los recursos en el orden correcto? + +¡El orden importa! El recurso de `Instrumentation` necesita ser desplegado antes de desplegar la aplicación, de lo contrario, la auto-instrumentación no funcionará. + +Recuerda la anotación de auto-instrumentación: + +```yaml +annotations: + instrumentation.opentelemetry.io/inject-python: 'true' +``` + +La anotación anterior le dice al OTel Operator que busque un objeto `Instrumentation` en el espacio de nombres del pod. También le dice al operador que inyecte la auto-instrumentación de Python en el pod. + +Cuando el pod se inicia, la anotación le dice al operador que busque un objeto de Instrumentación en el espacio de nombres del pod y que inyecte la auto-instrumentación en el pod. Agrega un +[init-container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) + al pod de la aplicación, llamado opentelemetry-auto-instrumentation, que se utiliza para inyectar la auto-instrumentación en el contenedor de la aplicación. + +Sin embargo, si el recurso de `Instrumentation` no está presente para cuando se despliega la aplicación, el init-container no puede ser creado. Por lo tanto, si la aplicación se despliega antes de desplegar el recurso de `Instrumentation`, la auto-instrumentación fallará. + +Para asegurarte de que el init-container `opentelemetry-auto-instrumentation` se haya iniciado correctamente (o incluso se haya iniciado en absoluto), ejecuta el siguiente comando: + +```sh +kubectl get events -n +``` + +Lo que debería producir algo como esto: + +```text +53s Normal Created pod/py-otel-server-7f54bf4cbc-p8wmj Created container opentelemetry-auto-instrumentation +53s Normal Started pod/py-otel-server-7f54bf4cbc-p8wmj Started container opentelemetry-auto-instrumentation +``` + +Si la salida carece de entradas `Created` y/o `Started` para `opentelemetry-auto-instrumentation`, significa que hay un problema con tu auto-instrumentación. Esto puede ser el resultado de cualquiera de las siguientes razones: + +- El recurso de `Instrumentation` no se instaló (o no se instaló correctamente). +- El recurso de `Instrumentation` se instaló después de que se desplegó la aplicación. +- Hay un error en la anotación de auto-instrumentación, o la anotación está en el lugar incorrecto — consulta el punto #4 a continuación. + +Asegúrate de verificar la salida de `kubectl get events` en busca de errores, ya que estos podrían ayudar a señalar el problema + +### ¿Es correcta la anotación de auto-instrumentación? + +A veces, la auto-instrumentación puede fallar debido a errores en la anotación de auto-instrumentación. + +Aquí hay algunas cosas que verificar: + +- **¿Es la auto-instrumentación para el lenguaje correcto?** Por ejemplo, al instrumentar una aplicación de Python, asegúrate de que la anotación no diga incorrectamente `instrumentation`.`opentelemetry.io/inject-java: "true"` en su lugar. +- **¿Está la anotación de auto-instrumentación en la ubicación correcta?** Al definir un `Deployment`, las anotaciones se pueden agregar en una de dos ubicaciones: `spec.metadata.annotations`, y `spec.template.metadata.annotations`. La anotación de auto-instrumentación debe agregarse a `spec.template.metadata.annotations`, de lo contrario, no funcionará. + +### ¿Se configuró correctamente el punto final de auto-instrumentación? + +El atributo `spec.exporter.endpoint` del recurso de `Instrumentation` define dónde enviar los datos. Esto puede ser un [OTel Collector](/docs/collector/), o cualquier punto final OTLP. Si este atributo se omite, se predetermina a `http://localhost:4317`, que, lo más probable, no enviará datos de telemetría a ningún lugar. + +Al enviar telemetría a un OTel Collector ubicado en el mismo clúster de Kubernetes, `spec.exporter.endpoint` debe hacer referencia al nombre del OTel Collector +[`Service`](https://kubernetes.io/docs/concepts/services-networking/service/). + +Por ejemplo: + +```yaml +spec: + exporter: + endpoint: http://demo-collector.opentelemetry.svc.cluster.local:4317 +``` + +Aquí, el punto final del Collector se establece en +`http://demo-collector.opentelemetry.svc.cluster.local:4317`, donde +`demo-collector` es el nombre del `Service` de Kubernetes del OTel Collector. En el ejemplo anterior, el Collector se está ejecutando en un espacio de nombres diferente al de la aplicación, lo que significa que `opentelemetry.svc.cluster.local` debe ser agregado al nombre del servicio del Collector, donde `opentelemetry` es el espacio de nombres en el que reside el Collector. diff --git a/content/es/docs/kubernetes/operator/target-allocator.md b/content/es/docs/kubernetes/operator/target-allocator.md new file mode 100644 index 000000000000..2993f64876a9 --- /dev/null +++ b/content/es/docs/kubernetes/operator/target-allocator.md @@ -0,0 +1,94 @@ +--- +title: Asignador de Objetivos +description: + Una herramienta para distribuir los objetivos del PrometheusReceiver en todas las instancias de Collector desplegadas +cSpell:ignore: labeldrop labelmap statefulset +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +--- + +El OpenTelemetry Operator viene con un componente opcional, el +[Target Allocator](https://github.com/open-telemetry/opentelemetry-operator/tree/main/cmd/otel-allocator) +(TA). En resumen, el TA es un mecanismo para desacoplar las funciones de descubrimiento de servicios y de recopilación de métricas de Prometheus, de modo que puedan escalarse independientemente. El Collector gestiona las métricas de Prometheus sin necesidad de instalar Prometheus. El TA gestiona la configuración del receptor de Prometheus del Collector. + +El TA cumple dos funciones: + +1. Distribución equitativa de los objetivos de Prometheus entre un grupo de Collectors +2. Descubrimiento de Recursos Personalizados de Prometheus + +## Empezando + +Al crear un Recurso Personalizado (CR) de OpenTelemetryCollector y activar el TA, +el Operator creará un nuevo despliegue y un servicio para servir directivas específicas de `http_sd_config` para cada pod de Collector como parte de ese CR. También cambiará la configuración del receptor de Prometheus en el CR, para que utilice el [http_sd_config](https://prometheus.io/docs/prometheus/latest/http_sd/) del TA. El siguiente ejemplo muestra cómo empezar con el Target Allocator: + +```yaml +apiVersion: opentelemetry.io/v1alpha1 +kind: OpenTelemetryCollector +metadata: + name: collector-with-ta +spec: + mode: statefulset + targetAllocator: + enabled: true + config: | + receivers: + prometheus: + config: + scrape_configs: + - job_name: 'otel-collector' + scrape_interval: 10s + static_configs: + - targets: [ '0.0.0.0:8888' ] + metric_relabel_configs: + - action: labeldrop + regex: (id|name) + replacement: $$1 + - action: labelmap + regex: label_(.+) + replacement: $$1 + + exporters: + # NOTE: Prior to v0.86.0 use `logging` instead of `debug`. + debug: + + service: + pipelines: + metrics: + receivers: [prometheus] + processors: [] + exporters: [debug] +``` + +Detrás de las escenas, el OpenTelemetry Operator convertirá la configuración del Collector después de la reconciliación en lo siguiente: + +```yaml +receivers: + prometheus: + config: + scrape_configs: + - job_name: otel-collector + scrape_interval: 10s + http_sd_configs: + - url: http://collector-with-ta-targetallocator:80/jobs/otel-collector/targets?collector_id=$POD_NAME + metric_relabel_configs: + - action: labeldrop + regex: (id|name) + replacement: $$1 + - action: labelmap + regex: label_(.+) + replacement: $$1 + +exporters: + debug: + +service: + pipelines: + metrics: + receivers: [prometheus] + processors: [] + exporters: [debug] +``` + +Nota cómo el Operator elimina cualquier configuración de descubrimiento de servicios existente (p.ej., `static_configs`, `file_sd_configs`, etc.) de la sección `scrape_configs` y añade una configuración `http_sd_configs` apuntando a una instancia de Target Allocator que él mismo aprovisionó. + +Para obtener información más detallada sobre el TargetAllocator, consulta +[TargetAllocator](https://github.com/open-telemetry/opentelemetry-operator/tree/main/cmd/otel-allocator). From 13e2b443a16f06d25a1f8500ec1b536d6261a78c Mon Sep 17 00:00:00 2001 From: Victorsesan <156327324+Victorsesan@users.noreply.github.com> Date: Fri, 15 Nov 2024 02:05:45 +0100 Subject: [PATCH 2/5] Update content/es/docs/kubernetes/getting-started.md Co-authored-by: Fabrizio Ferri-Benedetti --- content/es/docs/kubernetes/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/kubernetes/getting-started.md b/content/es/docs/kubernetes/getting-started.md index 591c10788dac..2259cb60bb8a 100644 --- a/content/es/docs/kubernetes/getting-started.md +++ b/content/es/docs/kubernetes/getting-started.md @@ -90,7 +90,7 @@ Esta instancia del recopilador utilizará los siguientes componentes: - [Filelog Receiver](../collector/components/#filelog-receiver): para recopilar Registros de Kubernetes y registros de aplicaciones escritos en stdout/stderr. -Vamos a descomponerlos. +Vamos a ver sus partes. ### Receptor OTLP From 40068456cb6b2136516df9436abf0c20a28d433d Mon Sep 17 00:00:00 2001 From: Victor Date: Fri, 15 Nov 2024 02:19:12 +0100 Subject: [PATCH 3/5] Translate en-es Ref [es] Spanish folder localization docs/kubernetes #5227 --- content/es/docs/kubernetes/getting-started.md | 20 +++++++++---------- .../operator/troubleshooting/_index.md | 8 ++++++++ 2 files changed, 18 insertions(+), 10 deletions(-) create mode 100644 content/es/docs/kubernetes/operator/troubleshooting/_index.md diff --git a/content/es/docs/kubernetes/getting-started.md b/content/es/docs/kubernetes/getting-started.md index 591c10788dac..7f3aa0dbfec3 100644 --- a/content/es/docs/kubernetes/getting-started.md +++ b/content/es/docs/kubernetes/getting-started.md @@ -22,7 +22,7 @@ Si estás buscando comenzar a migrar de Prometheus a OpenTelemetry, o si estás interesado en usar el OpenTelemetry Collector para recolectar métricas de Prometheus, consulta [Prometheus Receiver](../collector/components/#prometheus-receiver). -## Overview +## Visión general Kubernetes expone mucha telemetría importante de muchas maneras diferentes. Tiene registros, eventos, métricas para muchos objetos diferentes y los datos generados por sus @@ -48,7 +48,7 @@ estás interesado en usar un operador de Kubernetes, consulta [OpenTelemetry Operator](../operator/), pero esta guía se centrará en el Helm chart. -## Preparation +## Preparación Esta guía asumirá el uso de un [Kind cluster](https://kind.sigs.k8s.io/), pero eres libre de usar cualquier clúster de Kubernetes que consideres adecuado. @@ -61,7 +61,7 @@ clúster tipo: kind create cluster ``` -Suponiendo que ya tiene [Helm instalado](https://helm.sh/docs/intro/install/), +Asumiendo que ya tienes [Helm instalado](https://helm.sh/docs/intro/install/), Agregue el gráfico de timón de OpenTelemetry Collector para que pueda instalarse más tarde. @@ -69,16 +69,16 @@ más tarde. helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts ``` -## Daemonset Collector +## Recolector Daemonset El primer paso para recopilar la telemetría de Kubernetes es implementar un daemonset instancia del Colector de telemetría OpenTelemetry para recopilar telemetría relacionada con nodos y cargas de trabajo que se ejecutan en esos nodos. Se utiliza un daemonset para garantizar que esto La instancia del -recopilador está instalada en todos los nodos. Cada instancia del El recopilador +collector está instalada en todos los nodos. Cada instancia del El collector en el daemonset recopilará datos solo del nodo en el que se encuentra corriendo. -Esta instancia del recopilador utilizará los siguientes componentes: +Esta instancia del collector utilizará los siguientes componentes: - [OTLP Receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver): para recopilar trazas, métricas y registros de aplicaciones. @@ -90,7 +90,7 @@ Esta instancia del recopilador utilizará los siguientes componentes: - [Filelog Receiver](../collector/components/#filelog-receiver): para recopilar Registros de Kubernetes y registros de aplicaciones escritos en stdout/stderr. -Vamos a descomponerlos. +Veamos sus partes. ### Receptor OTLP @@ -104,7 +104,7 @@ pero para este tutorial asumiremos que la telemetría está formateada en OTLP. Aunque no es un requisito, es una práctica común para las aplicaciones que se ejecutan en Un nodo para emitir sus trazas, métricas y registros a un -recopilador que se ejecuta en el el mismo nodo. Esto mantiene las interacciones +collector que se ejecuta en el el mismo nodo. Esto mantiene las interacciones de red simples y permite una fácil correlación de Metadatos de Kubernetes usando el atributo `k8sattribute` @@ -207,7 +207,7 @@ con el cúmulo en su conjunto. Una implementación con exactamente una réplica garantiza que no se produzcan duplicados datos. -Esta instancia del Recopilador utilizará los siguientes componentes: +Esta instancia del collector utilizará los siguientes componentes: - [Kubernetes Cluster Receiver](../collector/components/#kubernetes-cluster-receiver):para recopilar métricas de nivel de clúster y eventos de entidad. @@ -289,5 +289,5 @@ a continuación, ejecute el siguiente comando para instalar el gráfico: helm install otel-collector-cluster open-telemetry/opentelemetry-collector --values ``` -Ahora debería tener una instalación de implementación del recopilador +Ahora debería tener una instalación de implementación del collector ejecutándose en su clúster que recopila métricas y eventos de clúster diff --git a/content/es/docs/kubernetes/operator/troubleshooting/_index.md b/content/es/docs/kubernetes/operator/troubleshooting/_index.md new file mode 100644 index 000000000000..9b469c7728ce --- /dev/null +++ b/content/es/docs/kubernetes/operator/troubleshooting/_index.md @@ -0,0 +1,8 @@ +--- +title: Solución de problemas del OpenTelemetry Operator para Kubernetes +linkTitle: Troubleshooting +description: + Contiene una colección de consejos para solucionar varios aspectos del + OpenTelemetry Kubernetes Operator. Por ejemplo, qué hacer cuando el asignador de objetivos no logra descubrir objetivos de scraping. +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +--- From b6aafb47150c83e6c08a1071c2bff333509a8477 Mon Sep 17 00:00:00 2001 From: Victor Date: Fri, 15 Nov 2024 02:33:12 +0100 Subject: [PATCH 4/5] # --- .github/ISSUE_TEMPLATE/PAGE_FEEDBACK.yml | 27 ++ .github/PULL_REQUEST_TEMPLATE.md | 21 ++ .github/PULL_REQUEST_TEMPLATE/DOCS_UPDATE.md | 6 - .htmltest.yml | 32 +-- assets/js/registrySearch.js | 65 ++++- content/en/docs/collector/quick-start.md | 4 +- .../en/docs/kubernetes/operator/automatic.md | 31 ++- content/en/docs/languages/java/_index.md | 2 +- .../en/docs/languages/java/configuration.md | 34 +-- content/en/docs/languages/java/sdk.md | 52 ++-- content/en/docs/languages/python/exporters.md | 1 - content/en/docs/zero-code/python/operator.md | 4 + content/es/docs/_index.md | 7 - content/es/docs/concepts/components.md | 8 +- .../es/docs/concepts/context-propagation.md | 4 +- content/es/docs/kubernetes/getting-started.md | 4 + content/es/docs/what-is-opentelemetry.md | 2 +- content/ja/docs/_index.md | 10 - .../ja/docs/concepts/context-propagation.md | 4 +- content/ja/docs/concepts/sampling/index.md | 2 +- content/ja/docs/what-is-opentelemetry.md | 2 +- content/pt/docs/_index.md | 18 +- content/pt/docs/concepts/components.md | 2 +- .../pt/docs/concepts/context-propagation.md | 4 +- .../concepts/instrumentation/libraries.md | 11 +- content/pt/docs/concepts/sampling/index.md | 2 +- content/pt/docs/concepts/signals/traces.md | 2 +- content/pt/docs/languages/go/exporters.md | 263 ++++++++++++++++++ content/pt/docs/languages/go/libraries.md | 57 ++++ content/pt/docs/languages/go/registry.md | 10 + content/pt/docs/languages/go/resources.md | 57 ++++ content/pt/docs/languages/go/sampling.md | 48 ++++ content/pt/docs/what-is-opentelemetry.md | 2 +- data/registry-schema.json | 6 +- ...egration-go-traefik-hub-api-management.yml | 3 +- data/registry/exporter-dotnet-inmemory.yml | 2 +- .../exporter-dotnet-prometheus-aspnetcore.yml | 2 +- ...xporter-dotnet-prometheus-httplistener.yml | 2 +- .../exporter-js-sap-cloud-logging.yml | 2 +- data/registry/instrumentation-java-okhttp.yml | 5 + .../instrumentation-ruby-elasticsearch.yml | 2 +- .../partials/ecosystem/registry/entry.html | 35 ++- .../ecosystem/registry/quickinstall/maven.md | 21 ++ .../ecosystem/registry/search-form.html | 44 +++ scripts/check-i18n.sh | 2 +- scripts/content-modules/adjust-pages.pl | 12 +- static/refcache.json | 12 + 47 files changed, 771 insertions(+), 177 deletions(-) create mode 100644 .github/ISSUE_TEMPLATE/PAGE_FEEDBACK.yml create mode 100644 .github/PULL_REQUEST_TEMPLATE.md delete mode 100644 .github/PULL_REQUEST_TEMPLATE/DOCS_UPDATE.md create mode 100644 content/pt/docs/languages/go/exporters.md create mode 100644 content/pt/docs/languages/go/libraries.md create mode 100644 content/pt/docs/languages/go/registry.md create mode 100644 content/pt/docs/languages/go/resources.md create mode 100644 content/pt/docs/languages/go/sampling.md create mode 100644 layouts/partials/ecosystem/registry/quickinstall/maven.md diff --git a/.github/ISSUE_TEMPLATE/PAGE_FEEDBACK.yml b/.github/ISSUE_TEMPLATE/PAGE_FEEDBACK.yml new file mode 100644 index 000000000000..32ad4c4abaaf --- /dev/null +++ b/.github/ISSUE_TEMPLATE/PAGE_FEEDBACK.yml @@ -0,0 +1,27 @@ +name: Page Feedback +description: >- + Used for page feedback from users visiting opentelemetry.io and clicking "no" + if a page was helpful. +title: '[Page Feedback]: summary of your feedback' +body: + - type: input + id: url + attributes: + label: URL + description: >- + The URL of the webpage where you are facing an issue. If not + auto-populated, please copy the URL from the browser address bar. + placeholder: https://opentelemetry.io/ + validations: + required: true + - type: textarea + id: description + attributes: + label: Description + description: + 'How has the page not been helpful? What information is missing? ' + placeholder: >- + Provide details on the problem. The more information you share with us + the faster we can resolve the issue. + validations: + required: true diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 000000000000..63c825bee4f9 --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,21 @@ + diff --git a/.github/PULL_REQUEST_TEMPLATE/DOCS_UPDATE.md b/.github/PULL_REQUEST_TEMPLATE/DOCS_UPDATE.md deleted file mode 100644 index 0fe4d48c2fb8..000000000000 --- a/.github/PULL_REQUEST_TEMPLATE/DOCS_UPDATE.md +++ /dev/null @@ -1,6 +0,0 @@ -## Docs PR Checklist - - - -- [ ] This PR is for a documentation page whose authoritative copy is in the - opentelemetry.io repository. diff --git a/.htmltest.yml b/.htmltest.yml index d2adbac45b64..dff29e7f9298 100644 --- a/.htmltest.yml +++ b/.htmltest.yml @@ -10,40 +10,9 @@ IgnoreDirs: # DO NOT EDIT! IgnoreDirs list is auto-generated from markdown file front matter. # Ignore blog index pages for all locales and in all blog sections (top-level and years) - ^(../)?blog/(\d+/)?page/\d+ - # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - - ^es/docs/concepts/glossary/ - - ^es/docs/concepts/instrumentation/zero-code/ - - ^es/docs/concepts/signals/baggage/ - - ^es/docs/zero-code/php/ - # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - - ^ja/docs/concepts/components/ - - ^ja/docs/concepts/glossary/ - - ^ja/docs/concepts/signals/baggage/ - - ^ja/docs/languages/erlang/sampling/ - - ^ja/docs/languages/js/sampling/ - - ^ja/docs/languages/ruby/sampling/ - - ^ja/docs/zero-code/php/ # TODO drop next line after https://github.com/open-telemetry/opentelemetry.io/issues/5423 is fixed for ja pages: - ^ja/docs/concepts/instrumentation/libraries/ # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - - ^pt/docs/concepts/components/ - - ^pt/docs/concepts/glossary/ - - ^pt/docs/concepts/signals/baggage/ - - ^pt/docs/languages/erlang/instrumentation/ - - ^pt/docs/languages/erlang/sampling/ - - ^pt/docs/languages/js/instrumentation/ - - ^pt/docs/languages/js/sampling/ - - ^pt/docs/languages/net/instrumentation/ - - ^pt/docs/languages/net/libraries/ - - ^pt/docs/languages/net/shim/ - - ^pt/docs/languages/php/instrumentation/ - - ^pt/docs/languages/python/instrumentation/ - - ^pt/docs/languages/ruby/instrumentation/ - - ^pt/docs/languages/ruby/sampling/ - - ^pt/docs/zero-code/php/ - # TODO drop next line after https://github.com/open-telemetry/opentelemetry.io/issues/5423 is fixed for pt pages: - - ^pt/docs/concepts/instrumentation/libraries/ - # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - ^zh/docs/concepts/signals/baggage/ - ^zh/docs/zero-code/php/ # DO NOT EDIT! IgnoreDirs list is auto-generated from markdown file front matter. @@ -81,6 +50,7 @@ IgnoreURLs: # list of regexs of paths or URLs to be ignored - ^https://www.farfetch.com - ^https://www.zocdoc.com - ^https://x.com + - ^https://maven.org # OTel Google calendar - curl returns 200, but the link checker gets a 401: - ^https://calendar.google.com/calendar/embed\?src=google.com_b79e3e90j7bbsa2n2p5an5lf60%40group.calendar.google.com # YouTube playlists sometimes give a 404, although they give a 200 when accessed via browser: diff --git a/assets/js/registrySearch.js b/assets/js/registrySearch.js index d91c590585a3..7673afafe855 100644 --- a/assets/js/registrySearch.js +++ b/assets/js/registrySearch.js @@ -38,6 +38,7 @@ let pathName = window.location.pathname; let searchQuery = ''; let selectedLanguage = 'all'; let selectedComponent = 'all'; +let selectedFlag = 'all'; // Added selectedFlag parseUrlParams(); @@ -49,7 +50,12 @@ if (pathName.includes('registry')) { showBody(); } - if (selectedLanguage !== 'all' || selectedComponent !== 'all') { + // Set the dropdown values from query params + if ( + selectedLanguage !== 'all' || + selectedComponent !== 'all' || + selectedFlag !== 'all' + ) { if (selectedLanguage !== 'all') { document.getElementById('languageDropdown').textContent = document.getElementById( @@ -62,6 +68,10 @@ if (pathName.includes('registry')) { `component-item-${selectedComponent}`, ).textContent; } + if (selectedFlag !== 'all') { + document.getElementById('flagsDropdown').textContent = + document.getElementById(`flag-item-${selectedFlag}`).textContent; + } updateFilters(); } @@ -106,6 +116,22 @@ if (pathName.includes('registry')) { updateFilters(); }), ); + // Flags dropdown event listener + + let flagList = document + .getElementById('flagsFilter') + .querySelectorAll('.dropdown-item'); + + flagList.forEach((element) => + element.addEventListener('click', function (evt) { + let val = evt.target.getAttribute('value'); + selectedFlag = val; + document.getElementById('flagsDropdown').textContent = + evt.target.textContent; + setInput('flag', val); + updateFilters(); + }), + ); }); } @@ -208,24 +234,39 @@ function setInput(key, value) { history.replaceState(null, null, '?' + queryParams.toString()); } -// Filters items based on language and component filters +// Filters items based on language, component and flags function updateFilters() { let allItems = [...document.getElementsByClassName('registry-entry')]; - if (selectedComponent === 'all' && selectedLanguage === 'all') { + if ( + selectedComponent === 'all' && + selectedLanguage === 'all' && + selectedFlag === 'all' + ) { + // Show all items if all filters are set to 'all' allItems.forEach((element) => element.classList.remove('d-none')); } else { + // Apply the filters allItems.forEach((element) => { const dc = element.dataset.registrytype; const dl = element.dataset.registrylanguage; - if ( - (dc === selectedComponent || selectedComponent === 'all') && - (dl === selectedLanguage || selectedLanguage === 'all') - ) { + const df = element.dataset.registryflags + ? element.dataset.registryflags.split(' ').map((f) => f.toLowerCase()) + : []; + + const componentMatches = + dc === selectedComponent || selectedComponent === 'all'; + const languageMatches = + dl === selectedLanguage || selectedLanguage === 'all'; + const flagMatches = + selectedFlag === 'all' || df.includes(selectedFlag.toLowerCase()); + + if (flagMatches) { + console.log('Flag matches:', df); + } + + if (componentMatches && languageMatches && flagMatches) { + // Changed element.classList.remove('d-none'); - } else if (dc === selectedComponent && dl !== selectedLanguage) { - element.classList.add('d-none'); - } else if (dl === selectedLanguage && dc !== selectedComponent) { - element.classList.add('d-none'); } else { element.classList.add('d-none'); } @@ -233,9 +274,11 @@ function updateFilters() { } } +// Parse URL parameters and update variables function parseUrlParams() { let urlParams = new URLSearchParams(window.location.search); searchQuery = urlParams.get('s'); selectedLanguage = urlParams.get('language') || 'all'; selectedComponent = urlParams.get('component') || 'all'; + selectedFlag = urlParams.get('flag') || 'all'; // Added } diff --git a/content/en/docs/collector/quick-start.md b/content/en/docs/collector/quick-start.md index 326f7c2b6f4f..d782ced91ca6 100644 --- a/content/en/docs/collector/quick-start.md +++ b/content/en/docs/collector/quick-start.md @@ -57,11 +57,13 @@ preferred shell. ## Generate and collect telemetry -3. Launch the Collector: +3. Launch the Collector, listening on ports 4317 (for OTLP gRPC), 4318 (for OTLP + HTTP) and 55679 (for ZPages): ```sh docker run \ -p 127.0.0.1:4317:4317 \ + -p 127.0.0.1:4318:4318 \ -p 127.0.0.1:55679:55679 \ otel/opentelemetry-collector-contrib:{{% param vers %}} \ 2>&1 | tee collector-output.txt # Optionally tee output for easier search later diff --git a/content/en/docs/kubernetes/operator/automatic.md b/content/en/docs/kubernetes/operator/automatic.md index 2435e060b81a..887273ba3e12 100644 --- a/content/en/docs/kubernetes/operator/automatic.md +++ b/content/en/docs/kubernetes/operator/automatic.md @@ -361,17 +361,16 @@ time). This means that the configured endpoint must be able to receive OTLP over will connect to the `http` port of the `otlpreceiver` of the Collector created in the previous step. -> As of operator v0.67.0, the Instrumentation resource automatically sets -> `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` and `OTEL_EXPORTER_OTLP_METRICS_PROTOCOL` -> to `http/protobuf` for Python services. If you use an older version of the -> Operator you **MUST** set these env variables to `http/protobuf`, or Python -> auto-instrumentation will not work. +> As of operator v0.108.0, the Instrumentation resource automatically sets +> `OTEL_EXPORTER_OTLP_PROTOCOL` to `http/protobuf` for Python services. If you +> use an older version of the Operator you **MUST** set this env variable to +> `http/protobuf`, or Python auto-instrumentation will not work. #### Auto-instrumenting Python logs By default, Python logs auto-instrumentation is disabled. If you would like to -enable this feature, you must to set the `OTEL_LOGS_EXPORTER` and -`OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED` environment variables as +enable this feature, you must to set +`OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED` environment variable as follows: ```yaml @@ -389,14 +388,12 @@ spec: - baggage python: env: - - name: OTEL_LOGS_EXPORTER - value: otlp_proto_http - name: OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED value: 'true' ``` -> Note that `OTEL_LOGS_EXPORTER` must be explicitly set to `otlp_proto_http`, -> otherwise it defaults to gRPC. +> As of operator v0.111.0 setting `OTEL_LOGS_EXPORTER` to `otlp` is not required +> anymore. #### Excluding auto-instrumentation {#python-excluding-auto-instrumentation} @@ -541,6 +538,18 @@ securityContext: runAsUser: 0 ``` +### Auto-instrumenting a Python musl based container {#annotations-python-musl} + +Since operator v0.113.0 Python auto-instrumentation also honors an annotation +that will permit it to run it on images with a different C library than glibc. + +```sh +# for Linux glibc based images, this is the default value and can be omitted +instrumentation.opentelemetry.io/otel-python-platform: "glibc" +# for Linux musl based images +instrumentation.opentelemetry.io/otel-python-platform: "musl" +``` + ## Troubleshooting If you run into problems trying to auto-instrument your code, here are a few diff --git a/content/en/docs/languages/java/_index.md b/content/en/docs/languages/java/_index.md index e2351e81c0b1..50d2da30240b 100644 --- a/content/en/docs/languages/java/_index.md +++ b/content/en/docs/languages/java/_index.md @@ -6,7 +6,7 @@ description: >- aliases: [/java, /java/metrics, /java/tracing] cascade: vers: - instrumentation: 2.9.0 + instrumentation: 2.10.0 otel: 1.44.1 contrib: 1.38.0 semconv: 1.28.0 diff --git a/content/en/docs/languages/java/configuration.md b/content/en/docs/languages/java/configuration.md index 5668297caa6d..86cdd3586895 100644 --- a/content/en/docs/languages/java/configuration.md +++ b/content/en/docs/languages/java/configuration.md @@ -141,13 +141,13 @@ returns a minimally configured instance (for example, Properties for configuring [resource](../sdk/#resource): -| System property | Description | Default | -| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | -| `otel.service.name` | Specify logical service name. Takes precedence over `service.name` defined with `otel.resource.attributes`. | `unknown_service:java` | -| `otel.resource.attributes` | Specify resource attributes in the following format: `key1=val1,key2=val2,key3=val3`. | | -| `otel.experimental.resource.disabled-keys` | Specify resource attribute keys to filter. This option is experimental and subject to change or removal. | | -| `otel.java.enabled.resource.providers` | Comma-separated list of `ResourceProvider` fully qualified class names to enable. **[1]** If unset, all resource providers are enabled. | | -| `otel.java.disabled.resource.providers` | Comma-separated list of `ResourceProvider` fully qualified class names to disable. **[1]** | | +| System property | Description | Default | +| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | +| `otel.service.name` | Specify logical service name. Takes precedence over `service.name` defined with `otel.resource.attributes`. | `unknown_service:java` | +| `otel.resource.attributes` | Specify resource attributes in the following format: `key1=val1,key2=val2,key3=val3`. | | +| `otel.resource.disabled-keys` | Specify resource attribute keys to filter. | | +| `otel.java.enabled.resource.providers` | Comma-separated list of `ResourceProvider` fully qualified class names to enable. **[1]** If unset, all resource providers are enabled. | | +| `otel.java.disabled.resource.providers` | Comma-separated list of `ResourceProvider` fully qualified class names to disable. **[1]** | | **[1]**: For example, to disable the [OS resource provider](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/resources/library/src/main/java/io/opentelemetry/instrumentation/resources/OsResourceProvider.java), @@ -260,12 +260,12 @@ exporters via `otel.logs.exporter`: Properties for setting exporters: -| System property | Purpose | Default | -| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- | -| `otel.traces.exporter` | Comma-separated list of span exporters. Known values include `otlp`, `zipkin`, `console`, `logging-otlp`, `none`. **[1]** | `otlp` | -| `otel.metrics.exporter` | Comma-separated list of metric exporters. Known values include `otlp`, `prometheus`, `none`. **[1]** | `otlp` | -| `otel.logs.exporter` | Comma-separated list of log record exporters. Known values include `otlp`, `console`, `logging-otlp`, `none`. **[1]** | `otlp` | -| `otel.java.experimental.exporter.memory_mode` | If `reusable_data`, enable reusable memory mode (on exporters which support it) to reduce allocations. Known values include `reusable_data`, `immutable_data`. This option is experimental and subject to change or removal. **[2]** | `immutable_data` | +| System property | Purpose | Default | +| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | +| `otel.traces.exporter` | Comma-separated list of span exporters. Known values include `otlp`, `zipkin`, `console`, `logging-otlp`, `none`. **[1]** | `otlp` | +| `otel.metrics.exporter` | Comma-separated list of metric exporters. Known values include `otlp`, `prometheus`, `none`. **[1]** | `otlp` | +| `otel.logs.exporter` | Comma-separated list of log record exporters. Known values include `otlp`, `console`, `logging-otlp`, `none`. **[1]** | `otlp` | +| `otel.java.exporter.memory_mode` | If `reusable_data`, enable reusable memory mode (on exporters which support it) to reduce allocations. Known values include `reusable_data`, `immutable_data`. **[2]** | `reusable_data` | **[1]**: Known exporters and artifacts (see [span exporter](../sdk/#spanexporter), @@ -277,10 +277,12 @@ Properties for setting exporters: - `console` configures `LoggingSpanExporter`, `LoggingMetricExporter`, `SystemOutLogRecordExporter`. - `logging-otlp` configures `OtlpJsonLogging{Signal}Exporter`. +- `experimental-otlp/stdout` configures `OtlpStdout{Signal}Exporter` (this + option is experimental and subject to change or removal). **[2]**: Exporters which adhere to -`otel.java.experimental.exporter.memory_mode=reusable_data` are -`OtlpGrpc{Signal}Exporter`, `OtlpHttp{Signal}Exporter`, and +`otel.java.exporter.memory_mode=reusable_data` are `OtlpGrpc{Signal}Exporter`, +`OtlpHttp{Signal}Exporter`, `OtlpStdout{Signal}Exporter`, and `PrometheusHttpServer`. Properties for `otlp` span, metric, and log exporters: @@ -306,7 +308,7 @@ Properties for `otlp` span, metric, and log exporters: | `otel.exporter.otlp.{signal}.timeout` | The maximum waiting time, in milliseconds, allowed to send each OTLP {signal} batch. | `10000` | | `otel.exporter.otlp.metrics.temporality.preference` | The preferred output aggregation temporality. Options include `DELTA`, `LOWMEMORY`, and `CUMULATIVE`. If `CUMULATIVE`, all instruments will have cumulative temporality. If `DELTA`, counter (sync and async) and histograms will be delta, up down counters (sync and async) will be cumulative. If `LOWMEMORY`, sync counter and histograms will be delta, async counter and up down counters (sync and async) will be cumulative. | `CUMULATIVE` | | `otel.exporter.otlp.metrics.default.histogram.aggregation` | The preferred default histogram aggregation. Options include `BASE2_EXPONENTIAL_BUCKET_HISTOGRAM` and `EXPLICIT_BUCKET_HISTOGRAM`. | `EXPLICIT_BUCKET_HISTOGRAM` | -| `otel.experimental.exporter.otlp.retry.enabled` | If `true`, retry on when transient errors occur. **[2]** | `false` | +| `otel.java.exporter.otlp.retry.enabled` | If `true`, retry on when transient errors occur. **[2]** | `true` | **NOTE:** The text placeholder `{signal}` refers to the supported [OpenTelemetry Signal](/docs/concepts/signals/). Valid values include `traces`, diff --git a/content/en/docs/languages/java/sdk.md b/content/en/docs/languages/java/sdk.md index f2c58896dbce..63235139dc14 100644 --- a/content/en/docs/languages/java/sdk.md +++ b/content/en/docs/languages/java/sdk.md @@ -425,15 +425,16 @@ for exporting spans out of process. Rather than directly registering with Span exporters built-in to the SDK and maintained by the community in `opentelemetry-java-contrib`: -| Class | Artifact | Description | -| ------------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------------------------------- | -| `OtlpHttpSpanExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports spans via OTLP `http/protobuf`. | -| `OtlpGrpcSpanExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports spans via OTLP `grpc`. | -| `LoggingSpanExporter` | `io.opentelemetry:opentelemetry-exporter-logging:{{% param vers.otel %}}` | Logs spans to JUL in a debugging format. | -| `OtlpJsonLoggingSpanExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs spans to JUL in the OTLP JSON encoding. | -| `ZipkinSpanExporter` | `io.opentelemetry:opentelemetry-exporter-zipkin:{{% param vers.otel %}}` | Export spans to Zipkin. | -| `InterceptableSpanExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes spans to a flexible interceptor before exporting. | -| `KafkaSpanExporter` | `io.opentelemetry.contrib:opentelemetry-kafka-exporter:{{% param vers.contrib %}}-alpha` | Exports spans by writing to a Kafka topic. | +| Class | Artifact | Description | +| ------------------------------ | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | +| `OtlpHttpSpanExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports spans via OTLP `http/protobuf`. | +| `OtlpGrpcSpanExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports spans via OTLP `grpc`. | +| `LoggingSpanExporter` | `io.opentelemetry:opentelemetry-exporter-logging:{{% param vers.otel %}}` | Logs spans to JUL in a debugging format. | +| `OtlpJsonLoggingSpanExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs spans to JUL in an OTLP JSON encoding. | +| `OtlpStdoutSpanExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs spans to `System.out` in the OTLP [JSON file encoding][] (experimental). | +| `ZipkinSpanExporter` | `io.opentelemetry:opentelemetry-exporter-zipkin:{{% param vers.otel %}}` | Export spans to Zipkin. | +| `InterceptableSpanExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes spans to a flexible interceptor before exporting. | +| `KafkaSpanExporter` | `io.opentelemetry.contrib:opentelemetry-kafka-exporter:{{% param vers.contrib %}}-alpha` | Exports spans by writing to a Kafka topic. | **[1]**: See [OTLP exporter sender](#otlp-exporter-senders) for implementation details. @@ -743,13 +744,14 @@ for exporting metrics out of process. Rather than directly registering with Metric exporters built-in to the SDK and maintained by the community in `opentelemetry-java-contrib`: -| Class | Artifact | Description | -| -------------------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------- | -| `OtlpHttpMetricExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports metrics via OTLP `http/protobuf`. | -| `OtlpGrpcMetricExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports metrics via OTLP `grpc`. | -| `LoggingMetricExporter` | `io.opentelemetry:opentelemetry-exporter-logging:{{% param vers.otel %}}` | Logs metrics to JUL in a debugging format. | -| `OtlpJsonLoggingMetricExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs metrics to JUL in the OTLP JSON encoding. | -| `InterceptableMetricExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes metrics to a flexible interceptor before exporting. | +| Class | Artifact | Description | +| -------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | +| `OtlpHttpMetricExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports metrics via OTLP `http/protobuf`. | +| `OtlpGrpcMetricExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports metrics via OTLP `grpc`. | +| `LoggingMetricExporter` | `io.opentelemetry:opentelemetry-exporter-logging:{{% param vers.otel %}}` | Logs metrics to JUL in a debugging format. | +| `OtlpJsonLoggingMetricExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs metrics to JUL in the OTLP JSON encoding. | +| `OtlpStdoutMetricExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs metrics to `System.out` in the OTLP [JSON file encoding][] (experimental). | +| `InterceptableMetricExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes metrics to a flexible interceptor before exporting. | **[1]**: See [OTLP exporter sender](#otlp-exporter-senders) for implementation details. @@ -1063,13 +1065,14 @@ for exporting log records out of process. Rather than directly registering with Span exporters built-in to the SDK and maintained by the community in `opentelemetry-java-contrib`: -| Class | Artifact | Description | -| ------------------------------------------ | ------------------------------------------------------------------------------------ | -------------------------------------------------------------- | -| `OtlpHttpLogRecordExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports log records via OTLP `http/protobuf`. | -| `OtlpGrpcLogRecordExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports log records via OTLP `grpc`. | -| `SystemOutLogRecordExporter` | `io.opentelemetry:opentelemetry-exporter-logging:{{% param vers.otel %}}` | Logs log records to system out in a debugging format. | -| `OtlpJsonLoggingLogRecordExporter` **[2]** | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs log records to JUL in the OTLP JSON encoding. | -| `InterceptableLogRecordExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes log records to a flexible interceptor before exporting. | +| Class | Artifact | Description | +| ------------------------------------------ | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | +| `OtlpHttpLogRecordExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports log records via OTLP `http/protobuf`. | +| `OtlpGrpcLogRecordExporter` **[1]** | `io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}` | Exports log records via OTLP `grpc`. | +| `SystemOutLogRecordExporter` | `io.opentelemetry:opentelemetry-exporter-logging:{{% param vers.otel %}}` | Logs log records to system out in a debugging format. | +| `OtlpJsonLoggingLogRecordExporter` **[2]** | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs log records to JUL in the OTLP JSON encoding. | +| `OtlpStdoutLogRecordExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs log records to `System.out` in the OTLP [JSON file encoding][] (experimental). | +| `InterceptableLogRecordExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes log records to a flexible interceptor before exporting. | **[1]**: See [OTLP exporter sender](#otlp-exporter-senders) for implementation details. @@ -1382,3 +1385,6 @@ you must also add a dependency on a ### Testing TODO: document tools available for testing the SDK + +[JSON file encoding]: + /docs/specs/otel/protocol/file-exporter/#json-file-serialization diff --git a/content/en/docs/languages/python/exporters.md b/content/en/docs/languages/python/exporters.md index c7bee4160084..c299c4465b88 100644 --- a/content/en/docs/languages/python/exporters.md +++ b/content/en/docs/languages/python/exporters.md @@ -213,7 +213,6 @@ from prometheus_client import start_http_server from opentelemetry import metrics from opentelemetry.exporter.prometheus import PrometheusMetricReader from opentelemetry.sdk.metrics import MeterProvider -from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader from opentelemetry.sdk.resources import SERVICE_NAME, Resource # Service name is required for most backends diff --git a/content/en/docs/zero-code/python/operator.md b/content/en/docs/zero-code/python/operator.md index 9f5e6761b6dd..de64a15ff232 100644 --- a/content/en/docs/zero-code/python/operator.md +++ b/content/en/docs/zero-code/python/operator.md @@ -28,6 +28,10 @@ provides images for a single Python version based on the glibc C library. If you want to use it you might need to build your own image operator Docker image for Python auto-instrumentation. +Since operator v0.113.0 it is possible to build an image with both glibc and +musl based auto-instrumentation and +[configure it at runtime](/docs/kubernetes/operator/automatic/#annotations-python-musl). + #### Django applications Applications that run from their own executable like Django requires to set in diff --git a/content/es/docs/_index.md b/content/es/docs/_index.md index 37bce30e49c5..15b4318af334 100644 --- a/content/es/docs/_index.md +++ b/content/es/docs/_index.md @@ -2,13 +2,6 @@ title: Documentación linkTitle: Docs menu: { main: { weight: 10 } } -htmltest: - IgnoreDirs: - # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - - ^es/docs/concepts/glossary/ - - ^es/docs/concepts/instrumentation/zero-code/ - - ^es/docs/concepts/signals/baggage/ - - ^es/docs/zero-code/php/ default_lang_commit: f7cb8b65a478450d80d703b34c8473c579702108 --- diff --git a/content/es/docs/concepts/components.md b/content/es/docs/concepts/components.md index be665264af10..9a548119bfb6 100644 --- a/content/es/docs/concepts/components.md +++ b/content/es/docs/concepts/components.md @@ -8,11 +8,11 @@ default_lang_commit: 9b7da35fd7abd77d867177902b36d95e5f322182 OpenTelemetry está compuesto por varios componentes principales: -- [Especificación](#especificación) +- [Especificación](#specification) - [Collector](#collector) - [Implementaciones de API y SDK específicas del lenguaje](#implementaciones-de-api-y-sdk-específicas-del-lenguaje) - [Librerías de Instrumentación](#librerías-de-instrumentación) - - [Exportadores](#exportadores) + - [Exportadores](#exporters) - [Instrumentación sin código](#instrumentación-sin-código) - [Detectores de Recursos](#detectores-de-recursos) - [Propagadores entre servicios](#propagadores-entre-servicios) @@ -23,7 +23,7 @@ OpenTelemetry está compuesto por varios componentes principales: OpenTelemetry te permite reemplazar la necesidad de SDKs y herramientas específicas de proveedores para generar y exportar datos de telemetría. -## Especificación +## Especificación {#specification} Describe los requisitos y expectativas multilenguaje para todas las implementaciones. Más allá de la definición de términos, la especificación @@ -75,7 +75,7 @@ dependencias separadas. Para más información, consulta [Instrumentación de librerías](/docs/concepts/instrumentation/libraries/). -### Exportadores +### Exportadores {#exporters} {{% docs/languages/exporters/intro %}} diff --git a/content/es/docs/concepts/context-propagation.md b/content/es/docs/concepts/context-propagation.md index 57eca6c8f149..adcae7f5fdbc 100644 --- a/content/es/docs/concepts/context-propagation.md +++ b/content/es/docs/concepts/context-propagation.md @@ -15,7 +15,7 @@ límites de procesos y redes. Para entender la propagación de contexto, necesitas comprender dos conceptos separados: contexto y propagación. -## Contexto +## Contexto {#context} El contexto es un objeto que contiene la información para que el servicio emisor y receptor, o la @@ -28,7 +28,7 @@ creado en el servicio B. El ID de traza que está en el contexto también se usa 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 +## Propagación {#propagation} 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 diff --git a/content/es/docs/kubernetes/getting-started.md b/content/es/docs/kubernetes/getting-started.md index 7f3aa0dbfec3..a8d15d83e3ba 100644 --- a/content/es/docs/kubernetes/getting-started.md +++ b/content/es/docs/kubernetes/getting-started.md @@ -90,7 +90,11 @@ Esta instancia del collector utilizará los siguientes componentes: - [Filelog Receiver](../collector/components/#filelog-receiver): para recopilar Registros de Kubernetes y registros de aplicaciones escritos en stdout/stderr. +<<<<<<< HEAD Veamos sus partes. +======= +Vamos a ver sus partes. +>>>>>>> 13e2b443a16f06d25a1f8500ec1b536d6261a78c ### Receptor OTLP diff --git a/content/es/docs/what-is-opentelemetry.md b/content/es/docs/what-is-opentelemetry.md index 7db506e0048a..ddc329ff450d 100644 --- a/content/es/docs/what-is-opentelemetry.md +++ b/content/es/docs/what-is-opentelemetry.md @@ -110,7 +110,7 @@ puede extender incluyen: Aunque la mayoría de los usuarios tal vez no necesiten extender OpenTelemetry, el proyecto está diseñado para hacerlo posible en casi todos los niveles. -## Historia +## Historia {#history} OpenTelemetry es un proyecto de [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io) que es el diff --git a/content/ja/docs/_index.md b/content/ja/docs/_index.md index fb009395aeb8..76f868b6e3c5 100644 --- a/content/ja/docs/_index.md +++ b/content/ja/docs/_index.md @@ -1,16 +1,6 @@ --- title: ドキュメント menu: { main: { weight: 10 } } -htmltest: - IgnoreDirs: - # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - - ^ja/docs/concepts/components/ - - ^ja/docs/concepts/glossary/ - - ^ja/docs/concepts/signals/baggage/ - - ^ja/docs/languages/erlang/sampling/ - - ^ja/docs/languages/js/sampling/ - - ^ja/docs/languages/ruby/sampling/ - - ^ja/docs/zero-code/php/ default_lang_commit: c2cd5b14 --- diff --git a/content/ja/docs/concepts/context-propagation.md b/content/ja/docs/concepts/context-propagation.md index 520a96e7526a..533112ba5e0f 100644 --- a/content/ja/docs/concepts/context-propagation.md +++ b/content/ja/docs/concepts/context-propagation.md @@ -10,14 +10,14 @@ default_lang_commit: 313e391 コンテキストの伝播を理解するには、コンテキストと伝搬（プロパゲーション）という、2つの別々の概念を理解する必要があります。 -## コンテキスト +## コンテキスト {#context} コンテキストは、送受信サービスまたは[実行ユニット](/docs/specs/otel/glossary/#execution-unit)が、あるシグナルと別のシグナルを関連付けるための情報を含むオブジェクトです。 たとえば、サービスAがサービスBを呼び出した場合、IDがコンテキスト内にあるサービスAのスパンは、サービスBで次に作成されるスパンの親スパンとして使用されます。 コンテキスト内にあるトレースIDは、サービスBで次に作成されるスパンにも使用されるため、そのスパンはサービスAのスパンと同じトレースの一部であることを意味します。 -## 伝搬（プロパゲーション） +## 伝搬（プロパゲーション） {#propagation} 伝搬は、サービスとプロセス間でコンテキストを移動させる仕組みです。 コンテキストオブジェクトをシリアライズまたはデシリアライズし、あるサービスから別のサービスに伝搬される関連情報を提供します。 diff --git a/content/ja/docs/concepts/sampling/index.md b/content/ja/docs/concepts/sampling/index.md index c66b3dd79a0d..b55c54361c7d 100644 --- a/content/ja/docs/concepts/sampling/index.md +++ b/content/ja/docs/concepts/sampling/index.md @@ -35,7 +35,7 @@ _適切なデータのサンプリングが必要なだけです。_ 誰かが「データをサンプリングアウトしている」と言ったり、処理またはエクスポートされていないデータは「サンプリングされた」と見なされると言ったりするのを見かけるかもしれません。 これらは間違った表現です。 -## ヘッドサンプリング +## ヘッドサンプリング {#head-sampling} ヘッドサンプリングは、サンプリングの決定をできるだけ早期に行うために用いられるサンプリング技術です。 スパンやトレースのサンプリングまたはドロップの決定は、トレース全体を検査することによって行われるわけではありません。 diff --git a/content/ja/docs/what-is-opentelemetry.md b/content/ja/docs/what-is-opentelemetry.md index 141a8a215f97..c226e1345429 100644 --- a/content/ja/docs/what-is-opentelemetry.md +++ b/content/ja/docs/what-is-opentelemetry.md @@ -66,7 +66,7 @@ OpenTelemetryは拡張できるように設計されています。どのよう ほとんどのユーザーはOpenTelemetryを拡張する必要はないかもしれませんが、このプロジェクトはほぼすべてのレベルで拡張できるように設計されています。 -## 歴史 +## 歴史 {#history} OpenTelemetryは、[Cloud Native Computing Foundation (CNCF)](https://www.cncf.io)プロジェクトであり、[OpenTracing](https://opentracing.io)と[OpenCensus](https://opencensus.io)の2つのプロジェクトが統合された成果物です。 これらのプロジェクトはどちらも、コードを計装し、オブザーバビリティバックエンドにテレメトリーデータを送信する方法の標準がないという問題を解決するために作られました。 diff --git a/content/pt/docs/_index.md b/content/pt/docs/_index.md index eb6bd6fcf8c7..0eb159f5fe93 100644 --- a/content/pt/docs/_index.md +++ b/content/pt/docs/_index.md @@ -3,23 +3,7 @@ title: Documentação linkTitle: Docs menu: { main: { weight: 10 } } htmltest: - IgnoreDirs: - # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - - ^pt/docs/concepts/components/ - - ^pt/docs/concepts/glossary/ - - ^pt/docs/concepts/signals/baggage/ - - ^pt/docs/languages/erlang/instrumentation/ - - ^pt/docs/languages/erlang/sampling/ - - ^pt/docs/languages/js/instrumentation/ - - ^pt/docs/languages/js/sampling/ - - ^pt/docs/languages/net/instrumentation/ - - ^pt/docs/languages/net/libraries/ - - ^pt/docs/languages/net/shim/ - - ^pt/docs/languages/php/instrumentation/ - - ^pt/docs/languages/python/instrumentation/ - - ^pt/docs/languages/ruby/instrumentation/ - - ^pt/docs/languages/ruby/sampling/ - - ^pt/docs/zero-code/php/ + IgnoreDirs: {} default_lang_commit: 2d88c10e1a14220a88a6e4859acb4047f49b6519 --- diff --git a/content/pt/docs/concepts/components.md b/content/pt/docs/concepts/components.md index b7a74b6823b0..4d7e8ef256ee 100644 --- a/content/pt/docs/concepts/components.md +++ b/content/pt/docs/concepts/components.md @@ -73,7 +73,7 @@ necessárias. Para mais informações, consulte [Bibliotecas de instrumentação](/docs/concepts/instrumentation/libraries/). -### Exporters +### Exporters {#exporters} {{% docs/languages/exporters/intro %}} diff --git a/content/pt/docs/concepts/context-propagation.md b/content/pt/docs/concepts/context-propagation.md index ce75b853cd86..a3ce5eeeb224 100644 --- a/content/pt/docs/concepts/context-propagation.md +++ b/content/pt/docs/concepts/context-propagation.md @@ -15,7 +15,7 @@ sistema que é distribuído arbitrariamente entre processos e limites de rede. Para compreender a propagação de contexto, você precisa entender dois conceitos distintos: contexto e propagação. -## Contexto +## Contexto {#context} O contexto é um objeto que contém as informações necessárias para que o serviço emissor e receptor, ou @@ -28,7 +28,7 @@ serviço B. O ID do rasto que está no contexto também será usado para o próx trecho criado no serviço B, o que significa que o trecho faz parte do mesmo rastro que o trecho do serviço A. -## Propagação +## Propagação {#propagation} Propagação é o mecanismo que move o contexto entre serviços e processos. Ele serializa ou desserializa o objeto de contexto e fornece as informações diff --git a/content/pt/docs/concepts/instrumentation/libraries.md b/content/pt/docs/concepts/instrumentation/libraries.md index f9dd1e39938d..b33f1af65a18 100644 --- a/content/pt/docs/concepts/instrumentation/libraries.md +++ b/content/pt/docs/concepts/instrumentation/libraries.md @@ -2,11 +2,7 @@ title: Bibliotecas description: Aprenda como adicionar instrumentação nativa à sua biblioteca. weight: 40 -default_lang_commit: a570a00c7a238ffe26528d7bfb20efdbaf939c39 -htmltest: - IgnoreDirs: - # TODO drop next line after https://github.com/open-telemetry/opentelemetry.io/issues/5423 is fixed for pt pages: - - ^pt/docs/concepts/instrumentation/libraries/ +default_lang_commit: a570a00c7a238ffe26528d7bfb20efdbaf939c39 # + link-fix patch --- O OpenTelemetry fornece [bibliotecas de instrumentação][] para várias @@ -314,9 +310,8 @@ Aqui estão os consulte a documentação do OpenTelemetry no seu idioma. No caso de um sistema de mensagens, você pode receber mais de uma mensagem de -uma vez. As mensagens recebidas se tornam -[_links_](/docs/languages/java/instrumentation/#create-spans-with-links) no -trecho que você cria. Consulte as +uma vez. As mensagens recebidas se tornam _links_ no trecho que você cria. +Consulte as [convenções de mensagens](/docs/specs/semconv/messaging/messaging-spans/) para mais detalhes (AVISO: as convenções de mensagens estão [em construção](https://github.com/open-telemetry/oteps/pull/173) 🚧). diff --git a/content/pt/docs/concepts/sampling/index.md b/content/pt/docs/concepts/sampling/index.md index 27caec960d79..3288147887ca 100644 --- a/content/pt/docs/concepts/sampling/index.md +++ b/content/pt/docs/concepts/sampling/index.md @@ -103,7 +103,7 @@ fornecedor ou com recursos computacionais em hospedagem própria, dependendo do seu _backend_ de observabilidade, da natureza dos seus dados e das suas tentativas de realizar amostragem de forma eficaz. -## Amostragem pela Cabeça +## Amostragem pela Cabeça {#head-sampling} A amostragem pela cabeça (_head sampling_) é uma técnica de amostragem usada para tomar uma decisão de amostragem o mais cedo possível. A decisão de amostrar diff --git a/content/pt/docs/concepts/signals/traces.md b/content/pt/docs/concepts/signals/traces.md index d8d3271b6b44..f96ad916dd5e 100644 --- a/content/pt/docs/concepts/signals/traces.md +++ b/content/pt/docs/concepts/signals/traces.md @@ -136,7 +136,7 @@ Para compreender como o rastreamento no OpenTelemetry funciona, vamos analisar uma lista de componentes que terão um papel fundamental na instrumentação do nosso código. -## Trace Provider +## Trace Provider {#tracer-provider} Um Trace Provider (às vezes chamado de `TracerProvider`) é uma fábrica de `rastros`. Na maioria das aplicações, um Trace Provider é inicializado uma vez e diff --git a/content/pt/docs/languages/go/exporters.md b/content/pt/docs/languages/go/exporters.md new file mode 100644 index 000000000000..5393d851d0a6 --- /dev/null +++ b/content/pt/docs/languages/go/exporters.md @@ -0,0 +1,263 @@ +--- +title: Exporters +aliases: [exporting_data] +weight: 50 +default_lang_commit: 5e2a0b43c1f9f42824a024206e797cf7041ed9db +# prettier-ignore +cSpell:ignore: otlplog otlploggrpc otlploghttp otlpmetric otlpmetricgrpc otlpmetrichttp otlptrace otlptracegrpc otlptracehttp promhttp stdoutlog stdouttrace +--- + +{{% docs/languages/exporters/intro go %}} + +## Console + +O exportador do console é útil para tarefas de desenvolvimento e depuração, e é +o mais simples de configurar. + +### Rastros no Console {#console-traces} + +O pacote +[`go.opentelemetry.io/otel/exporters/stdout/stdouttrace`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/stdout/stdouttrace) +possui uma implementação do Exporter de Rastros para o console. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "go.opentelemetry.io/otel/exporters/stdout/stdouttrace" + "go.opentelemetry.io/otel/sdk/trace" +) + +func newExporter() (trace.SpanExporter, error) { + return stdouttrace.New() +} +``` + +### Métricas no Console {#console-metrics} + +O pacote +[`go.opentelemetry.io/otel/exporters/stdout/stdoutmetric`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/stdout/stdoutmetric) +possui uma implementação do Exporter de Métricas para o console. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "go.opentelemetry.io/otel/exporters/stdout/stdoutmetric" + "go.opentelemetry.io/otel/sdk/metric" +) + +func newExporter() (metric.Exporter, error) { + return stdoutmetric.New() +} +``` + +### Logs no Console (Experimental) {#console-logs} + +O pacote +[`go.opentelemetry.io/otel/exporters/stdout/stdoutlog`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/stdout/stdoutlog) +possui uma implementação do Exporter de Logs para o console. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "go.opentelemetry.io/otel/exporters/stdout/stdoutlog" + "go.opentelemetry.io/otel/sdk/log" +) + +func newExporter() (log.Exporter, error) { + return stdoutlog.New() +} +``` + +## OTLP + +Para enviar dados de rastreamento para um endpoint OTLP (como o +[collector](/docs/collector) ou Jaeger >= v1.35.0), você precisará configurar um +Exporter OTLP que envie os dados para o seu endpoint. + +### Rastros OTLP via HTTP {#otlp-traces-over-http} + +O pacote +[`go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp) +possui uma implementação do Exporter de Rastros OTLP utilizando o protocolo HTTP +com payloads binários protobuf. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "context" + + "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp" + "go.opentelemetry.io/otel/sdk/trace" +) + +func newExporter(ctx context.Context) (trace.SpanExporter, error) { + return otlptracehttp.New(ctx) +} +``` + +### Rastros OTLP via gRPC {#otlp-traces-over-grpc} + +O pacote +[`go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc) +possui uma implementação do Exporter de Rastros OTLP utilizando o protocolo +gRPC. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "context" + + "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc" + "go.opentelemetry.io/otel/sdk/trace" +) + +func newExporter(ctx context.Context) (trace.SpanExporter, error) { + return otlptracegrpc.New(ctx) +} +``` + +### Jaeger + +Para testar o exportador OTLP, a partir da versão v1.35.0 você pode executar o +[Jaeger](https://www.jaegertracing.io/) como um endpoint OTLP e visualizar os +rastros em um contêiner Docker: + +```shell +docker run -d --name jaeger \ + -e COLLECTOR_OTLP_ENABLED=true \ + -p 16686:16686 \ + -p 4317:4317 \ + -p 4318:4318 \ + jaegertracing/all-in-one:latest +``` + +### Métricas OTLP via HTTP {#otlp-metrics-over-http} + +O pacote +[`go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp) +possui uma implementação do Exporter de Métricas OTLP utilizando o protocolo +HTTP com payloads binários protobuf. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "context" + + "go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp" + "go.opentelemetry.io/otel/sdk/metric" +) + +func newExporter(ctx context.Context) (metric.Exporter, error) { + return otlpmetrichttp.New(ctx) +} +``` + +### Métricas OTLP via gRPC {#otlp-metrics-over-grpc} + +O pacote +[`go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc) +possui uma implementação do Exporter de Métricas OTLP utilizando o protocolo +gRPC. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "context" + + "go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc" + "go.opentelemetry.io/otel/sdk/metric" +) + +func newExporter(ctx context.Context) (metric.Exporter, error) { + return otlpmetricgrpc.New(ctx) +} +``` + +## Prometheus (Experimental) + +O Exporter do Prometheus é utilizado para reportar métricas através do +_scraping_ realizado pelo Prometheus em um endpoint HTTP. + +O pacote +[`go.opentelemetry.io/otel/exporters/prometheus`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/prometheus) +possui uma implementação do Exporter de Métricas do Prometheus. + +Por exemplo, aqui está como é possível criar um Exporter (que também é um leitor +de métricas) com as configurações padrão: + +```go +import ( + "context" + + "go.opentelemetry.io/otel/exporters/prometheus" + "go.opentelemetry.io/otel/sdk/metric" +) + +func newExporter(ctx context.Context) (metric.Reader, error) { + // prometheus.DefaultRegisterer é utilizado por padrão, de modo que + // as métricas fiquem disponíveis via promhttp.Handler. + return prometheus.New() +} +``` + +Para saber mais sobre como usar o Exporter do Prometheus, veja o +[exemplo do prometheus](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/examples/prometheus) + +### Logs OTLP via HTTP (Experimental) {#otlp-logs-over-http-experimental} + +O pacote +[`go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp) +possui uma implementação do Exporter de Logs OTLP utilizando o protocolo HTTP +com payloads binários protobuf. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "context" + + "go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp" + "go.opentelemetry.io/otel/sdk/log" +) + +func newExporter(ctx context.Context) (log.Exporter, error) { + return otlploghttp.New(ctx) +} +``` + +### Logs OTLP via gRPC (Experimental) {#otlp-logs-over-grpc-experimental} + +O pacote +[`go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc`](https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc) +possui uma implementação do Exporter de Logs OTLP utilizando o protocolo gRPC. + +Por exemplo, aqui está como é possível criar um Exporter com as configurações +padrão: + +```go +import ( + "context" + + "go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc" + "go.opentelemetry.io/otel/sdk/log" +) + +func newExporter(ctx context.Context) (log.Exporter, error) { + return otlploggrpc.New(ctx) +} +``` diff --git a/content/pt/docs/languages/go/libraries.md b/content/pt/docs/languages/go/libraries.md new file mode 100644 index 000000000000..c1e9f9ab0618 --- /dev/null +++ b/content/pt/docs/languages/go/libraries.md @@ -0,0 +1,57 @@ +--- +title: Utilizando bibliotecas de instrumentação +linkTitle: Bibliotecas +aliases: + - /docs/languages/go/using_instrumentation_libraries + - /docs/languages/go/automatic_instrumentation +weight: 40 +default_lang_commit: 825010e3cfece195ae4dfd019eff080ef8eb6365 +--- + +{{% docs/languages/libraries-intro "go" %}} + +## Utilizando bibliotecas de instrumentação {#use-instrumentation-libraries} + +Caso uma biblioteca não venha com o OpenTelemetry, você pode utilizar uma +[biblioteca de instrumentação](/docs/specs/otel/glossary/#instrumentation-library) +para gerar dados de telemetria para uma biblioteca ou framework. + +Por exemplo, a +[biblioteca de instrumentação para `net/http`](https://pkg.go.dev/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp) +cria automaticamente [trechos](/docs/concepts/signals/traces/#spans) e +[métricas](/docs/concepts/signals/metrics/) com base nas requisições HTTP. + +## Configuração {#setup} + +Cada biblioteca de instrumentação é um pacote. Em geral, isso significa que você +precisa usar `go get` para obter o pacote apropriado. Por exemplo, para obter as +bibliotecas de instrumentação mantidas no +[repositório Contrib](https://github.com/open-telemetry/opentelemetry-go-contrib), +execute o seguinte comando: + +```sh +go get go.opentelemetry.io/contrib/instrumentation/{caminho-de-importacao}/otel{nome-do-pacote} +``` + +Em seguida, configure o seu código com base no que a biblioteca requer para ser +ativada. + +Em [Primeiros Passos](../getting-started/) fornecemos um exemplo mostrando como +configurar a instrumentação para um servidor `net/http`. + +## Pacotes disponíveis {#available-packages} + +Uma lista completa de bibliotecas de instrumentação disponíveis pode ser +encontrada no +[registro do OpenTelemetry](/ecosystem/registry/?language=go&component=instrumentation). + +## Próximos passos {#next-steps} + +As bibliotecas de instrumentação podem gerar dados de telemetria para +requisições HTTP de entrada e saída, mas não instrumentam sua aplicação +completamente. + +Enriqueça seus dados de telemetria realizando uma +[instrumentação personalizada](../instrumentation/) em seu código. Isso +complementa a telemetria da biblioteca padrão e pode oferecer dados mais +profundos sobre sua aplicação em execução. diff --git a/content/pt/docs/languages/go/registry.md b/content/pt/docs/languages/go/registry.md new file mode 100644 index 000000000000..0f29dab6a4a8 --- /dev/null +++ b/content/pt/docs/languages/go/registry.md @@ -0,0 +1,10 @@ +--- +title: Registro +description: + Bibliotecas de instrumentação, Exporters e outros componentes úteis para o + OpenTelemetry Go +redirect: /ecosystem/registry/?language=go +_build: { render: link } +weight: 300 +default_lang_commit: 1e0c316e3bdac625edc51f0a5037bff6e4611b65 +--- diff --git a/content/pt/docs/languages/go/resources.md b/content/pt/docs/languages/go/resources.md new file mode 100644 index 000000000000..b11b5479e759 --- /dev/null +++ b/content/pt/docs/languages/go/resources.md @@ -0,0 +1,57 @@ +--- +title: Recursos +weight: 70 +cSpell:ignore: sdktrace thirdparty +default_lang_commit: 12f31f62fcc466532513f6ebccb060c9ea5b9fe4 +--- + +{{% docs/languages/resources-intro %}} + +Recursos devem ser adicionados a um `TracerProvider`, `MeterProvider` e +`LoggerProvider` durante a sua inicialização, e são criados de maneira +semelhante aos atributos: + +```go +res := resource.NewWithAttributes( + semconv.SchemaURL, + semconv.ServiceNameKey.String("meuServico"), + semconv.ServiceVersionKey.String("1.0.0"), + semconv.ServiceInstanceIDKey.String("abcdef12345"), +) + +provider := sdktrace.NewTracerProvider( + ... + sdktrace.WithResource(res), +) +``` + +Observe o uso do pacote `semconv` para fornecer +[nomes convencionais](/docs/concepts/semantic-conventions/) para os atributos do +recurso. Isso ajuda a garantir que os consumidores da telemetria produzida +utilizando as convenções semânticas possam identificar facilmente os atributos +relevantes e entender seu significado. + +Os recursos também podem ser detectados automaticamente por meio das +implementações de `resource.Detector`. Esses `Detector`s podem descobrir +informações sobre o processo em execução, o sistema operacional em que ele está +sendo executado, o provedor de nuvem que hospeda a instância do sistema +operacional ou qualquer número de outros atributos de recurso. + +```go +res, err := resource.New( + context.Background(), + resource.WithFromEnv(), // Descobre e fornece atributos das variáveis de ambiente OTEL_RESOURCE_ATTRIBUTES e OTEL_SERVICE_NAME. + resource.WithTelemetrySDK(), // Descobre e fornece informações sobre o SDK do OpenTelemetry que está sendo utilizado. + resource.WithProcess(), // Descobre e fornece informações do processo. + resource.WithOS(), // Descobre e fornece informações do Sistema Operacional. + resource.WithContainer(), // Descobre e fornece informações do contêiner. + resource.WithHost(), // Descobre e fornece informações da hospedagem. + resource.WithAttributes(attribute.String("foo", "bar")), // Adicionar atributos de recurso personalizados. + // resource.WithDetectors(thirdparty.Detector{}), // Inclua a sua própria implementação externa do Detector. +) +if errors.Is(err, resource.ErrPartialResource) || errors.Is(err, resource.ErrSchemaURLConflict) { + log.Println(err) // Registre problemas não-fatais. +} else if err != nil { + log.Fatalln(err) // O erro pode ser fatal. +} +``` diff --git a/content/pt/docs/languages/go/sampling.md b/content/pt/docs/languages/go/sampling.md new file mode 100644 index 000000000000..08c861274862 --- /dev/null +++ b/content/pt/docs/languages/go/sampling.md @@ -0,0 +1,48 @@ +--- +title: Amostragem +weight: 80 +default_lang_commit: 06837fe15457a584f6a9e09579be0f0400593d57 +--- + +A [Amostragem](/docs/concepts/sampling/) é um processo que restringe a +quantidade de trechos gerados por um sistema. A configuração de amostragem exata +que você deve usar depende das suas necessidades específicas, mas, em geral, +você deve tomar uma decisão no início de um rastro e permitir que a decisão de +amostragem se propague para outros serviços. + +Um [`Sampler`](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/trace#Sampler) +pode ser definido no `TracerProvider` utilizando o método +[`WithSampler`](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/trace#WithSampler), +conforme o exemplo a seguir: + +```go +provider := trace.NewTracerProvider( + trace.WithSampler(trace.AlwaysSample()), +) +``` + +[`AlwaysSample`](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/trace#AlwaysSample) +e +[`NeverSample`](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/trace#NeverSample) +são valores autoexplicativos. `AlwaysSample` significa que cada trecho será +amostrado, enquanto `NeverSample` significa que nenhum trecho será amostrado. Ao +iniciar um projeto, ou em ambiente de desenvolvimento, utilize `AlwaysSample`. + +Outros amostradores disponíveis são: + +- [`TraceIDRatioBased`](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/trace#TraceIDRatioBased), + que amostra uma fração dos trechos, com base na fração fornecida ao + amostrador. Caso esta fração seja .5, metade de todos os trechos serão + amostrados. +- [`ParentBased`](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/trace#ParentBased), + é um decorador de amostrador que se comporta de maneira diferente, com base no + parente do trecho. Caso o trecho não possua um parente, o amostrador decorado + é usado para tomar a decisão de amostragem com base no parente do trecho. Por + padrão, `ParentBased` amostra trechos que possuem parentes que foram + amostrados e não amostra trechos cujos parentes não foram amostrados. + +Por padrão, o Tracer Provider utiliza o amostrador `ParentBased` com o +amostrador `AlwaysSample` + +Caso esteja em um ambiente de produção, considere utilizar o amostrador +`ParentBased` com o amostrador `TraceIDRatioBased`. diff --git a/content/pt/docs/what-is-opentelemetry.md b/content/pt/docs/what-is-opentelemetry.md index dbc5ca01c050..c70ca4ef35db 100644 --- a/content/pt/docs/what-is-opentelemetry.md +++ b/content/pt/docs/what-is-opentelemetry.md @@ -108,7 +108,7 @@ pode ser estendido incluem: Embora a maioria dos usuários possa não precisar estender o OpenTelemetry, o projeto é projetado para tornar isso possível em quase todos os níveis. -## História +## História {#history} O OpenTelemetry é um projeto da [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io) que é resultado diff --git a/data/registry-schema.json b/data/registry-schema.json index edbedd799c81..c605d190742c 100644 --- a/data/registry-schema.json +++ b/data/registry-schema.json @@ -109,9 +109,9 @@ }, "url": { "type": "string", - "description": "The URL of the author", - "pattern": "^https:\\/\\/github\\.com\\/([a-zA-Z0-9](?:-?[a-zA-Z0-9]){0,38})$", - "errorMessage": "The URL of the author must be a valid GitHub user URL" + "description": "The URL of the author. This can be a website or a GitHub handle URL.", + "format": "uri", + "pattern": "^https://.*$" } }, "if": { diff --git a/data/registry/application-integration-go-traefik-hub-api-management.yml b/data/registry/application-integration-go-traefik-hub-api-management.yml index 8eec96632b80..4ffe278c3f46 100644 --- a/data/registry/application-integration-go-traefik-hub-api-management.yml +++ b/data/registry/application-integration-go-traefik-hub-api-management.yml @@ -13,8 +13,9 @@ description: behavior. authors: - name: Traefik Labs + url: https://github.com/immanuelfodor urls: website: https://traefik.io/traefik-hub/ docs: https://doc.traefik.io/traefik-hub/operations/metrics -createdAt: '2024-08-06' +createdAt: 2024-08-06 isNative: true diff --git a/data/registry/exporter-dotnet-inmemory.yml b/data/registry/exporter-dotnet-inmemory.yml index 07cf5e6fc115..91eb8e6e5575 100644 --- a/data/registry/exporter-dotnet-inmemory.yml +++ b/data/registry/exporter-dotnet-inmemory.yml @@ -17,4 +17,4 @@ createdAt: 2022-11-07 package: registry: nuget name: OpenTelemetry.Exporter.InMemory - version: 1.10.0-rc.1 + version: 1.10.0 diff --git a/data/registry/exporter-dotnet-prometheus-aspnetcore.yml b/data/registry/exporter-dotnet-prometheus-aspnetcore.yml index ff19ad374680..5c3978f479e1 100644 --- a/data/registry/exporter-dotnet-prometheus-aspnetcore.yml +++ b/data/registry/exporter-dotnet-prometheus-aspnetcore.yml @@ -20,4 +20,4 @@ createdAt: 2022-11-07 package: registry: nuget name: OpenTelemetry.Exporter.Prometheus.AspNetCore - version: 1.9.0-beta.2 + version: 1.10.0-beta.1 diff --git a/data/registry/exporter-dotnet-prometheus-httplistener.yml b/data/registry/exporter-dotnet-prometheus-httplistener.yml index b53f88e6e3d4..3e0316a0479f 100644 --- a/data/registry/exporter-dotnet-prometheus-httplistener.yml +++ b/data/registry/exporter-dotnet-prometheus-httplistener.yml @@ -18,4 +18,4 @@ createdAt: 2022-11-07 package: registry: nuget name: OpenTelemetry.Exporter.Prometheus.HttpListener - version: 1.9.0-beta.2 + version: 1.10.0-beta.1 diff --git a/data/registry/exporter-js-sap-cloud-logging.yml b/data/registry/exporter-js-sap-cloud-logging.yml index aca044a763b5..bfaf2ca56339 100644 --- a/data/registry/exporter-js-sap-cloud-logging.yml +++ b/data/registry/exporter-js-sap-cloud-logging.yml @@ -23,4 +23,4 @@ isFirstParty: false package: registry: npm name: '@sap/opentelemetry-exporter-for-sap-cloud-logging' - version: 0.1.1 + version: 0.2.0 diff --git a/data/registry/instrumentation-java-okhttp.yml b/data/registry/instrumentation-java-okhttp.yml index dae54020d6cc..789dc0973ca7 100644 --- a/data/registry/instrumentation-java-okhttp.yml +++ b/data/registry/instrumentation-java-okhttp.yml @@ -1,3 +1,4 @@ +# cspell:ignore okhttp title: okHTTP Instrumentation registryType: instrumentation language: java @@ -13,4 +14,8 @@ authors: urls: repo: https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/okhttp createdAt: 2020-11-05 +package: + registry: maven + name: io.opentelemetry.instrumentation/opentelemetry-okhttp-3.0 + version: 2.9.0-alpha isFirstParty: false diff --git a/data/registry/instrumentation-ruby-elasticsearch.yml b/data/registry/instrumentation-ruby-elasticsearch.yml index 0c6f37f2d837..fa866d0c4b85 100644 --- a/data/registry/instrumentation-ruby-elasticsearch.yml +++ b/data/registry/instrumentation-ruby-elasticsearch.yml @@ -20,4 +20,4 @@ isNative: true package: registry: gems name: elasticsearch - version: 8.15.0 + version: 8.16.0 diff --git a/layouts/partials/ecosystem/registry/entry.html b/layouts/partials/ecosystem/registry/entry.html index 9a282c4db0b9..27b17cc83014 100644 --- a/layouts/partials/ecosystem/registry/entry.html +++ b/layouts/partials/ecosystem/registry/entry.html @@ -46,6 +46,10 @@ "installLine" "cargo add %s" "installTemplate" "ecosystem/registry/quickinstall/default.md" "icon" "fab fa-rust") + "maven" (dict + "urlPattern" "https://maven.org/artifact/%s" + "installTemplate" "ecosystem/registry/quickinstall/maven.md" + "icon" "fa-solid fa-feather") -}} {{ $isNative := and (or (eq .registryType "instrumentation") (eq .registryType "application integration")) (.isNative) }} @@ -85,7 +89,23 @@ {{ errorf "The %q registry entry requires a repo or website URL." .title }} {{ end -}} {{ $primaryHref := printf "href=%q" $primaryUrl | safeHTMLAttr -}} -
  • + {{ $flags := slice -}} + {{ if $isNew -}} + {{ $flags = $flags | append "new" -}} + {{ end -}} + {{ if $isNative -}} + {{ $flags = $flags | append "native" -}} + {{ end -}} + {{ if $isFirstParty -}} + {{ $flags = $flags | append "first_party" -}} + {{ end -}} + {{ if $usedInDemo -}} + {{ $flags = $flags | append "used_in_demo" -}} + {{ end -}} + {{ if $deprecated -}} + {{ $flags = $flags | append "deprecated" -}} + {{ end -}} +

  • @@ -141,6 +161,19 @@

    Deprecated

    {{ end -}} {{- .description | markdownify -}}

    + + +
    + {{ if .tags }} + + {{ end }} +
    + {{ with $package -}} {{ if not (eq .quickInstall false) }}
    Quick Install
    diff --git a/layouts/partials/ecosystem/registry/quickinstall/maven.md b/layouts/partials/ecosystem/registry/quickinstall/maven.md new file mode 100644 index 000000000000..b7dfc26f20b7 --- /dev/null +++ b/layouts/partials/ecosystem/registry/quickinstall/maven.md @@ -0,0 +1,21 @@ +##### Maven + +Add the following dependency in your `pom.xml` file to install this package. + +```xml + + {{ index (split .name "/") 0 }} + {{ index (split .name "/") 1 }} + {{ .version }} + +``` + +##### Gradle + +Add the following dependency in your `build.gradle` file to install this package: + +```groovy +dependencies { + implementation '{{ index (split .name "/") 0 }}:{{ index (split .name "/") 1 }}:{{ .version }}' +} +``` \ No newline at end of file diff --git a/layouts/shortcodes/ecosystem/registry/search-form.html b/layouts/shortcodes/ecosystem/registry/search-form.html index 4e2fc00028c1..4ed992793e72 100644 --- a/layouts/shortcodes/ecosystem/registry/search-form.html +++ b/layouts/shortcodes/ecosystem/registry/search-form.html @@ -34,6 +34,38 @@ {{ end -}} {{ $types = $types | uniq | sort -}} +{{ $counter := 0 -}} +{{ $entries := slice -}} +{{ range $key, $entry := .Site.Data.registry -}} + {{ $flags := slice -}} + {{ if .isNative -}} + {{ $flags = $flags | append "native" -}} + {{ end -}} + {{ if .isFirstParty -}} + {{ $flags = $flags | append "first_party" -}} + {{ end -}} + {{ if .isNew -}} + {{ $flags = $flags | append "new" -}} + {{ end -}} + {{ if .usedInDemo -}} + {{ $flags = $flags | append "used_in_demo" -}} + {{ end -}} + {{ if .deprecated -}} + {{ $flags = $flags | append "deprecated" -}} + {{ end -}} + {{ $entry = merge $entry (dict "_key" $key "id" $counter "flags" $flags) -}} + {{ $entries = $entries | append $entry -}} + {{ $counter = add $counter 1 }} +{{ end -}} + +{{ $allFlags := slice -}} +{{ range $entry := $entries -}} + {{ range $flag := $entry.flags -}} + {{ $allFlags = $allFlags | append $flag }} + {{ end -}} +{{ end -}} +{{ $uniqueFlags := $allFlags | uniq | sort }} +
    The OpenTelemetry Registry allows you to search for instrumentation libraries, collector components, utilities, and other useful projects in the OpenTelemetry @@ -51,6 +83,8 @@ + + @@ -88,6 +122,16 @@ {{ end -}}
    + + + + diff --git a/scripts/check-i18n.sh b/scripts/check-i18n.sh index df729741a05b..00cbe4fddda6 100755 --- a/scripts/check-i18n.sh +++ b/scripts/check-i18n.sh @@ -250,7 +250,7 @@ function main() { for f in $TARGETS; do ((FILE_COUNT++)) - LASTCOMMIT_FF=$(perl -ne "print \"\$1\" if /^$I18N_DLC_KEY:\\s*(.*)/" "$f") + LASTCOMMIT_FF=$(perl -ne "print \"\$1\" if /^$I18N_DLC_KEY:\\s*([a-f0-9]+)/i" "$f") LASTCOMMIT="$LASTCOMMIT_FF" if [[ $LIST_KIND == "ALL" && -n $COMMIT_HASH_ARG ]]; then diff --git a/scripts/content-modules/adjust-pages.pl b/scripts/content-modules/adjust-pages.pl index edc02477ec56..7c554dce2b0a 100755 --- a/scripts/content-modules/adjust-pages.pl +++ b/scripts/content-modules/adjust-pages.pl @@ -25,7 +25,7 @@ my $otelSpecVers = $versions{'spec:'}; my $otlpSpecVers = $versions{'otlp:'}; my $semconvVers = $versions{'semconv:'}; -my $warn2 = 0; # TODO remove along with warning 002 +my $patchMsg2 = 0; # TODO remove along with patch-message 002 sub printTitleAndFrontMatter() { print "---\n"; @@ -46,7 +46,7 @@ () } elsif ($ARGV =~ /otel\/specification\/logs\/api.md$/) { if ($otelSpecVers ne "1.39.0") { # TODO: delete the enclosing elsif body - print STDOUT "WARNING [001]: $0: remove obsolete code now that OTel spec has been updated.\n" + print STDOUT "INFO [001]: $0: remove obsolete code now that OTel spec has been updated.\n" } $frontMatterFromFile .= "linkTitle: API\naliases: [bridge-api]\n"; } @@ -116,13 +116,13 @@ () # SPECIFICATION custom processing - # TODO: drop the entire if-then-else statement patch code when OTel spec vers contains + # TODO: drop the entire if statement patch code when OTel spec vers contains # https://github.com/open-telemetry/opentelemetry-specification/pull/4287, # which should be vers > 1.39.0. - if ($otelSpecVers eq "1.39.0") { + if ($ARGV =~ /otel\/spec/) { s|(/api\.md)#logs-api\b|$1|g; - } elsif ($ARGV =~ /otel\/spec/) { - print STDOUT "WARNING [002]: $0: remove obsolete code now that OTel spec has been updated.\n" unless $warn2++ + print STDOUT "INFO [002]: $0: remove obsolete patch code now that OTel spec has been updated.\n" + if $otelSpecVers ne "1.39.0" && !$patchMsg2++ } s|\(https://github.com/open-telemetry/opentelemetry-specification\)|($specBasePath/otel/)|; diff --git a/static/refcache.json b/static/refcache.json index 30cb7c919941..765546941467 100644 --- a/static/refcache.json +++ b/static/refcache.json @@ -5255,6 +5255,10 @@ "StatusCode": 200, "LastSeen": "2024-01-18T19:13:40.755331-05:00" }, + "https://github.com/immanuelfodor": { + "StatusCode": 200, + "LastSeen": "2024-11-13T13:16:21.346606655Z" + }, "https://github.com/instana/go-otel-exporter": { "StatusCode": 200, "LastSeen": "2024-01-18T19:10:14.475135-05:00" @@ -11739,6 +11743,10 @@ "StatusCode": 200, "LastSeen": "2024-01-30T05:18:35.161372-05:00" }, + "https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom-alpha/2.10.0-alpha/opentelemetry-instrumentation-bom-alpha-2.10.0-alpha.pom": { + "StatusCode": 206, + "LastSeen": "2024-11-13T10:47:55.011955709Z" + }, "https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom-alpha/2.7.0-alpha/opentelemetry-instrumentation-bom-alpha-2.7.0-alpha.pom": { "StatusCode": 206, "LastSeen": "2024-10-23T20:20:08.34491-05:00" @@ -11747,6 +11755,10 @@ "StatusCode": 206, "LastSeen": "2024-10-23T20:19:21.596018-05:00" }, + "https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom/2.10.0/opentelemetry-instrumentation-bom-2.10.0.pom": { + "StatusCode": 206, + "LastSeen": "2024-11-13T10:47:53.144495226Z" + }, "https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom/2.7.0/opentelemetry-instrumentation-bom-2.7.0.pom": { "StatusCode": 206, "LastSeen": "2024-10-23T20:20:07.402964-05:00" From 1199061575943e82f2c2d0f0aea58abf48dfa8e3 Mon Sep 17 00:00:00 2001 From: Victor Date: Wed, 20 Nov 2024 15:52:29 +0100 Subject: [PATCH 5/5] Translate en-es Ref [es] Spanish folder localization docs/kubernetes #5227 --- .../operator/troubleshooting/automatic.md | 290 ++++++++++++++++++ 1 file changed, 290 insertions(+) create mode 100644 content/es/docs/kubernetes/operator/troubleshooting/automatic.md diff --git a/content/es/docs/kubernetes/operator/troubleshooting/automatic.md b/content/es/docs/kubernetes/operator/troubleshooting/automatic.md new file mode 100644 index 000000000000..e10865e96518 --- /dev/null +++ b/content/es/docs/kubernetes/operator/troubleshooting/automatic.md @@ -0,0 +1,290 @@ +--- +title: Auto-instrumentación +cSpell:ignore: PYTHONPATH +default_lang_commit: f9893e13ba9ea10f1b5bcecb52cdd3d907bf0fd9 +--- + +Si estás utilizando la capacidad del [OpenTelemetry Operator](/docs/kubernetes/operator) para inyectar [auto-instrumentación](/docs/kubernetes/operator/automatic) y no ves ningún rastro o métrica, sigue estos pasos de solución de problemas para entender qué está pasando. + +## Pasos de solución de problemas + +### Verificar el estado de la instalación + +Después de instalar el recurso `Instrumentation`, asegúrate de que esté instalado correctamente ejecutando este comando: + +```shell +kubectl describe otelinst -n +``` + +Donde `` es el espacio de nombres en el que se despliega el recurso `Instrumentation`. + +Tu salida debería verse así: + +Your output should look like this: + +```yaml +Name: python-instrumentation +Namespace: application +Labels: app.kubernetes.io/managed-by=opentelemetry-operator +Annotations: instrumentation.opentelemetry.io/default-auto-instrumentation-apache-httpd-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd:1.0.3 + instrumentation.opentelemetry.io/default-auto-instrumentation-dotnet-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-dotnet:0.7.0 + instrumentation.opentelemetry.io/default-auto-instrumentation-go-image: + ghcr.io/open-telemetry/opentelemetry-go-instrumentation/autoinstrumentation-go:v0.2.1-alpha + instrumentation.opentelemetry.io/default-auto-instrumentation-java-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:1.26.0 + instrumentation.opentelemetry.io/default-auto-instrumentation-nodejs-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-nodejs:0.40.0 + instrumentation.opentelemetry.io/default-auto-instrumentation-python-image: + ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.39b0 +API Version: opentelemetry.io/v1alpha1 +Kind: Instrumentation +Metadata: + Creation Timestamp: 2023-07-28T03:42:12Z + Generation: 1 + Resource Version: 3385 + UID: 646661d5-a8fc-4b64-80b7-8587c9865f53 +Spec: +... + Exporter: + Endpoint: http://otel-collector-collector.opentelemetry.svc.cluster.local:4318 +... + Propagators: + tracecontext + baggage + Python: + Image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.39b0 + Resource Requirements: + Limits: + Cpu: 500m + Memory: 32Mi + Requests: + Cpu: 50m + Memory: 32Mi + Resource: + Sampler: +Events: +``` + +### Verificar los registros del OpenTelemetry Operator + +Verifica los registros del OpenTelemetry Operator en busca de errores ejecutando este comando: + +```shell +kubectl logs -l app.kubernetes.io/name=opentelemetry-operator --container manager -n opentelemetry-operator-system --follow +``` + +Los registros no deben mostrar errores relacionados con errores de auto-instrumentación. + +### Verificar el orden de despliegue + + Asegúrate de que el orden de despliegue sea correcto.El recurso `Instrumentation` debe ser desplegado antes de desplegar los recursos `Deployment` correspondientes que son auto-instrumentados. Considera el siguiente fragmento de anotación de auto-instrumentación: + +```yaml +annotations: + instrumentation.opentelemetry.io/inject-python: 'true' +``` + +Cuando el pod se inicia, la anotación le dice al Operator que busque un recurso `Instrumentation` en el espacio de nombres del pod y que inyecte la auto-instrumentación de Python en el pod. Añade un [init-container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) llamado `opentelemetry-auto-instrumentation` al pod de la aplicación, que es luego usado para inyectar la auto-instrumentación en el contenedor de la aplicación. + +Lo cual puedes ver cuando ejecutas: + +```shell +kubectl describe pod -n +``` + +Donde `` es el espacio de nombres en el que se despliega tu pod. El resultado debería verse como el siguiente ejemplo, que muestra cómo podría verse la especificación del pod después de la inyección de auto-instrumentación: + +```text +Name: py-otel-server-f89fdbc4f-mtsps +Namespace: opentelemetry +Priority: 0 +Service Account: default +Node: otel-target-allocator-talk-control-plane/172.24.0.2 +Start Time: Mon, 15 Jul 2024 17:23:45 -0400 +Labels: app=my-app + app.kubernetes.io/name=py-otel-server + pod-template-hash=f89fdbc4f +Annotations: instrumentation.opentelemetry.io/inject-python: true +Status: Running +IP: 10.244.0.10 +IPs: + IP: 10.244.0.10 +Controlled By: ReplicaSet/py-otel-server-f89fdbc4f +Init Containers: + opentelemetry-auto-instrumentation-python: + Container ID: containerd://20ecf8766247e6043fcad46544dba08c3ef534ee29783ca552d2cf758a5e3868 + Image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.45b0 + Image ID: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python@sha256:3ed1122e10375d527d84c826728f75322d614dfeed7c3a8d2edd0d391d0e7973 + Port: + Host Port: + Command: + cp + -r + /autoinstrumentation/. + /otel-auto-instrumentation-python + State: Terminated + Reason: Completed + Exit Code: 0 + Started: Mon, 15 Jul 2024 17:23:51 -0400 + Finished: Mon, 15 Jul 2024 17:23:51 -0400 + Ready: True + Restart Count: 0 + Limits: + cpu: 500m + memory: 32Mi + Requests: + cpu: 50m + memory: 32Mi + Environment: + Mounts: + /otel-auto-instrumentation-python from opentelemetry-auto-instrumentation-python (rw) + /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-x2nmj (ro) +Containers: + py-otel-server: + Container ID: containerd://95fb6d06b08ead768f380be2539a93955251be6191fa74fa2e6e5616036a8f25 + Image: otel-target-allocator-talk:0.1.0-py-otel-server + Image ID: docker.io/library/import-2024-07-15@sha256:a2ed39e9a39ca090fedbcbd474c43bac4f8c854336a8500e874bd5b577e37c25 + Port: 8082/TCP + Host Port: 0/TCP + State: Running + Started: Mon, 15 Jul 2024 17:23:52 -0400 + Ready: True + Restart Count: 0 + Environment: + OTEL_NODE_IP: (v1:status.hostIP) + OTEL_POD_IP: (v1:status.podIP) + OTEL_METRICS_EXPORTER: console,otlp_proto_http + OTEL_LOGS_EXPORTER: otlp_proto_http + OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED: true + PYTHONPATH: /otel-auto-instrumentation-python/opentelemetry/instrumentation/auto_instrumentation:/otel-auto-instrumentation-python + OTEL_TRACES_EXPORTER: otlp + OTEL_EXPORTER_OTLP_TRACES_PROTOCOL: http/protobuf + OTEL_EXPORTER_OTLP_METRICS_PROTOCOL: http/protobuf + OTEL_SERVICE_NAME: py-otel-server + OTEL_EXPORTER_OTLP_ENDPOINT: http://otelcol-collector.opentelemetry.svc.cluster.local:4318 + OTEL_RESOURCE_ATTRIBUTES_POD_NAME: py-otel-server-f89fdbc4f-mtsps (v1:metadata.name) + OTEL_RESOURCE_ATTRIBUTES_NODE_NAME: (v1:spec.nodeName) + OTEL_PROPAGATORS: tracecontext,baggage + OTEL_RESOURCE_ATTRIBUTES: service.name=py-otel-server,service.version=0.1.0,k8s.container.name=py-otel-server,k8s.deployment.name=py-otel-server,k8s.namespace.name=opentelemetry,k8s.node.name=$(OTEL_RESOURCE_ATTRIBUTES_NODE_NAME),k8s.pod.name=$(OTEL_RESOURCE_ATTRIBUTES_POD_NAME),k8s.replicaset.name=py-otel-server-f89fdbc4f,service.instance.id=opentelemetry.$(OTEL_RESOURCE_ATTRIBUTES_POD_NAME).py-otel-server + Mounts: + /otel-auto-instrumentation-python from opentelemetry-auto-instrumentation-python (rw) + /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-x2nmj (ro) +Conditions: + Type Status + Initialized True + Ready True + ContainersReady True + PodScheduled True +Volumes: + kube-api-access-x2nmj: + Type: Projected (a volume that contains injected data from multiple sources) + TokenExpirationSeconds: 3607 + ConfigMapName: kube-root-ca.crt + ConfigMapOptional: + DownwardAPI: true + opentelemetry-auto-instrumentation-python: + Type: EmptyDir (a temporary directory that shares a pod's lifetime) + Medium: + SizeLimit: 200Mi +QoS Class: Burstable +Node-Selectors: +Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s + node.kubernetes.io/unreachable:NoExecute op=Exists for 300s +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 99s default-scheduler Successfully assigned opentelemetry/py-otel-server-f89fdbc4f-mtsps to otel-target-allocator-talk-control-plane + Normal Pulling 99s kubelet Pulling image "ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.45b0" + Normal Pulled 93s kubelet Successfully pulled image "ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.45b0" in 288.756166ms (5.603779501s including waiting) + Normal Created 93s kubelet Created container opentelemetry-auto-instrumentation-python + Normal Started 93s kubelet Started container opentelemetry-auto-instrumentation-python + Normal Pulled 92s kubelet Container image "otel-target-allocator-talk:0.1.0-py-otel-server" already present on machine + Normal Created 92s kubelet Created container py-otel-server + Normal Started 92s kubelet Started container py-otel-server +``` + +Si el recurso `Instrumentation` no está presente en el momento en que se despliega el `Deployment`, no se puede crear el `init-container`. Esto significa que si el recurso `Deployment` se despliega antes de que despliegues el recurso `Instrumentation`, la auto-instrumentación no se inicializa. + +Verifica que el `init-container` `opentelemetry-auto-instrumentation` se haya iniciado correctamente (o si siquiera se ha iniciado) ejecutando el siguiente comando: + +```shell +kubectl get events -n +``` + +Donde `` es el espacio de nombres en el que se despliega tu pod. El resultado debería parecerse al siguiente ejemplo: + +```text +53s Normal Created pod/py-otel-server-7f54bf4cbc-p8wmj Created container opentelemetry-auto-instrumentation +53s Normal Started pod/py-otel-server-7f54bf4cbc-p8wmj Started container opentelemetry-auto-instrumentation +``` + +Si la salida no incluye las entradas `Created` o `Started` para `opentelemetry-auto-instrumentation`, puede haber un problema con tu configuración de auto-instrumentación. Esto puede ser el resultado de cualquiera de las siguientes razones: + +- El recurso `Instrumentation` no fue instalado o no fue instalado correctamente. + +- El recurso `Instrumentation` se instaló después de que se desplegó la aplicación. + +- Hay un error en la anotación de auto-instrumentación o la anotación está en el lugar incorrecto. Consulta la siguiente sección. + +También es posible que desees verificar la salida del comando de eventos en busca de errores, ya que estos podrían ayudarte a identificar el problema. + +### Verificar la anotación de auto-instrumentación + +Considera el siguiente fragmento de anotación de auto-instrumentación: + +```yaml +annotations: + instrumentation.opentelemetry.io/inject-python: 'true' +``` + +Si tu recurso `Deployment` se despliega en un espacio de nombres llamado `application` y tienes un recurso `Instrumentation` llamado `my-instrumentation` que se despliega en un espacio de nombres llamado `opentelemetry`, entonces la anotación anterior no funcionará. + +En su lugar, la anotación debería ser: + +```yaml +annotations: + instrumentation.opentelemetry.io/inject-python: 'opentelemetry/my-instrumentation' +``` + +Donde `opentelemetry` es el espacio de nombres del recurso `Instrumentation`, y `my-instrumentation` es el nombre del recurso `Instrumentation`. + +[Los valores posibles para la anotación pueden ser](https://github.com/open-telemetry/opentelemetry-operator/blob/main/README.md?plain=1#L151-L156):: + +"true" - inyectar el recurso `OpenTelemetryCollector` desde el espacio de nombres. + +"sidecar-for-my-app" - nombre de la instancia CR de `OpenTelemetryCollector` en el espacio de nombres actual. + +"my-other-namespace/my-instrumentation" - nombre y espacio de nombres de la instancia CR de `OpenTelemetryCollector` en otro espacio de nombres. + +"false" - no inyectar + +### Verificar la configuración de auto-instrumentación + +Es posible que la anotación de auto-instrumentación no se haya añadido correctamente. Verifica lo siguiente: + +- ¿Estás auto-instrumentando para el lenguaje correcto? Por ejemplo, ¿intentaste auto-instrumentar una aplicación de Python añadiendo una anotación de auto-instrumentación de JavaScript en su lugar? + +- ¿Pusiste la anotación de auto-instrumentación en el lugar correcto? Cuando defines un recurso `Deployment`, hay dos ubicaciones donde podrías añadir anotaciones: `spec.metadata.annotations` y `spec.template.metadata.annotations`. La anotación de auto-instrumentación necesita ser añadida a `spec.template.metadata.annotations`, de lo contrario no + +### Verificar la configuración del endpoint de auto-instrumentación + +La configuración `spec.exporter.endpoint` en el recurso `Instrumentation` te permite definir el destino para tus datos de telemetría. Si la omites, por defecto es `http://localhost:4317`, lo que hace que los datos se pierdan. + +Si estás enviando tu telemetría a un [Collector](/docs/collector/), el valor de `spec.exporter.endpoint` debe hacer referencia al nombre de tu [`Service`](https://kubernetes.io/docs/concepts/services-networking/service/) del Collector. + +Por ejemplo: `http://otel-collector.opentelemetry.svc.cluster.local:4318`. + +Donde `otel-collector` es el nombre del [`Service`](https://kubernetes.io/docs/concepts/services-networking/service/) del Collector de OTel en Kubernetes. + +Además, si el Collector está funcionando en un espacio de nombres diferente, debes añadir `opentelemetry.svc.cluster.local` al nombre del servicio del Collector, donde `opentelemetry` es el espacio de nombres en el que reside el Collector. Puede ser cualquier espacio de nombres que elijas. + +Finalmente, asegúrate de que estás utilizando el puerto correcto del Collector. Normalmente, puedes elegir entre `4317` (gRPC) o `4318` (HTTP); sin embargo, para [auto-instrumentación de Python, solo puedes usar `4318`](/docs/kubernetes/operator/automatic/#python). + +### Verificar las fuentes de configuración + +La auto-instrumentación actualmente sobrescribe `JAVA_TOOL_OPTIONS` de Java, `PYTHONPATH` de Python y `NODE_OPTIONS` de Node.js cuando se configuran en una imagen de Docker o cuando se definen en un `ConfigMap`. Este es un problema conocido y, como resultado, estos métodos para configurar estas variables de entorno deben evitarse hasta que se resuelva el problema. + +Consulta los problemas de referencia para [Java](https://github.com/open-telemetry/opentelemetry-operator/issues/1814), [Python](https://github.com/open-telemetry/opentelemetry-operator/issues/1884) y [Node.js](https://github.com/open-telemetry/opentelemetry-operator/issues/1393). +