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..2101343d25bc --- /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). + +## 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 +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. + +## 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. + +Suponiendo que ya tienes +[Kind instalado](https://kind.sigs.k8s.io/#installation-and-usage), crea un nuevo +clúster tipo: + +```sh +kind create cluster +``` + +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. + +```sh +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +``` + +## 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 +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 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. +- [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 +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` + +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 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. + +- [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 collector +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). 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 +--- 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). +