|
| 1 | +--- |
| 2 | +title: Componentes |
| 3 | +description: Componentes que forman OpenTelemetry |
| 4 | +aliases: [data-collection] |
| 5 | +weight: 20 |
| 6 | +default_lang_commit: 9b7da35fd7abd77d867177902b36d95e5f322182 |
| 7 | +--- |
| 8 | + |
| 9 | +OpenTelemetry está compuesto por varios componentes principales: |
| 10 | + |
| 11 | +- [Especificación](#especificación) |
| 12 | +- [Collector](#collector) |
| 13 | +- [Implementaciones de API y SDK específicas del lenguaje](#implementaciones-de-api-y-sdk-específicas-del-lenguaje) |
| 14 | + - [Librerías de Instrumentación](#librerías-de-instrumentación) |
| 15 | + - [Exportadores](#exportadores) |
| 16 | + - [Instrumentación sin código](#instrumentación-sin-código) |
| 17 | + - [Detectores de Recursos](#detectores-de-recursos) |
| 18 | + - [Propagadores entre servicios](#propagadores-entre-servicios) |
| 19 | + - [Muestreadores](#muestreadores) |
| 20 | +- [Operador de Kubernetes](#operador-de-kubernetes) |
| 21 | +- [Elementos de Función como Servicio](#elementos-de-función-como-servicio) |
| 22 | + |
| 23 | +OpenTelemetry te permite reemplazar la necesidad de SDKs y herramientas |
| 24 | +específicas de proveedores para generar y exportar datos de telemetría. |
| 25 | + |
| 26 | +## Especificación |
| 27 | + |
| 28 | +Describe los requisitos y expectativas multilenguaje para todas las |
| 29 | +implementaciones. Más allá de la definición de términos, la especificación |
| 30 | +define lo siguiente: |
| 31 | + |
| 32 | +- **API:** Define tipos de datos y operaciones para generar y correlacionar |
| 33 | + datos de trazas, métricas y logs. |
| 34 | +- **SDK:** Define requisitos para una implementación específica del lenguaje de |
| 35 | + la API. La configuración, procesamiento de datos y conceptos de exportación |
| 36 | + también se definen aquí. |
| 37 | +- **Datos:** Define el Protocolo de OpenTelemetry (OTLP) y convenciones |
| 38 | + semánticas neutrales que un backend de telemetría puede soportar. |
| 39 | + |
| 40 | +Para más información, consulta las [especificaciones](/docs/specs/). |
| 41 | + |
| 42 | +## Collector |
| 43 | + |
| 44 | +El Collector de OpenTelemetry es un proxy neutral que puede recibir, procesar y |
| 45 | +exportar datos de telemetría. Soporta recibir datos de telemetría en múltiples |
| 46 | +formatos (por ejemplo, OTLP, Jaeger, Prometheus, así como muchas herramientas |
| 47 | +comerciales/proprietarias) y enviar datos a uno o más backends. También permite |
| 48 | +procesar y filtrar datos de telemetría antes de exportarlos. |
| 49 | + |
| 50 | +Para más información, consulta el [Collector](/docs/collector/). |
| 51 | + |
| 52 | +## Implementaciones de API y SDK específicas del lenguaje |
| 53 | + |
| 54 | +OpenTelemetry también cuenta con SDKs específicos para cada lenguaje que te |
| 55 | +permiten usar la API de OpenTelemetry para generar datos de telemetría en el |
| 56 | +lenguaje de tu elección y exportarlos a un backend preferido. Estos SDKs también |
| 57 | +permiten incorporar librerías de instrumentación para librerías y frameworks |
| 58 | +comunes, que puedes utilizar para conectar la instrumentación manual en tu |
| 59 | +aplicación. |
| 60 | + |
| 61 | +Para más información, consulta |
| 62 | +[Instrumentación](/docs/concepts/instrumentation/). |
| 63 | + |
| 64 | +### Librerías de instrumentación |
| 65 | + |
| 66 | +OpenTelemetry soporta una amplia gama de componentes que generan datos de |
| 67 | +telemetría relevantes desde librerías y frameworks populares para los lenguajes |
| 68 | +soportados. Por ejemplo, las solicitudes HTTP entrantes y salientes desde una |
| 69 | +librería HTTP generan datos sobre esas solicitudes. |
| 70 | + |
| 71 | +Un objetivo aspiracional de OpenTelemetry es que todas las librerías populares |
| 72 | +estén diseñadas para ser observables por defecto, para que no se requieran |
| 73 | +dependencias separadas. |
| 74 | + |
| 75 | +Para más información, consulta |
| 76 | +[Instrumentación de librerías](/docs/concepts/instrumentation/libraries/). |
| 77 | + |
| 78 | +### Exportadores |
| 79 | + |
| 80 | +{{% docs/languages/exporters/intro %}} |
| 81 | + |
| 82 | +### Instrumentación sin código |
| 83 | + |
| 84 | +Si aplica, una implementación específica de OpenTelemetry en un lenguaje |
| 85 | +proporciona una forma de instrumentar tu aplicación sin tocar el código fuente. |
| 86 | +Aunque el mecanismo subyacente depende del lenguaje, la instrumentación sin |
| 87 | +código añade las capacidades de API y SDK de OpenTelemetry a tu aplicación. |
| 88 | +Adicionalmente, puede añadir un conjunto de librerías de instrumentación y |
| 89 | +dependencias de exportador. |
| 90 | + |
| 91 | +Para más información, consulta |
| 92 | +[Instrumentación sin código](/docs/concepts/instrumentation/zero-code/). |
| 93 | + |
| 94 | +### Detectores de recursos |
| 95 | + |
| 96 | +Un [recurso](/docs/concepts/resources/) representa la entidad que produce |
| 97 | +telemetría como atributos de tipo recurso. Por ejemplo, un proceso que produce |
| 98 | +telemetría y que se está ejecutando en un contenedor en Kubernetes tiene el |
| 99 | +nombre del Pod, un nombre del namespace y posiblemente un nombre del Deployment. |
| 100 | +Puedes incluir todos estos atributos como tipo recurso. |
| 101 | + |
| 102 | +Las implementaciones específicas de OpenTelemetry para cada lenguaje |
| 103 | +proporcionan detección de recursos desde la variable de entorno |
| 104 | +`OTEL_RESOURCE_ATTRIBUTES` y para muchas entidades comunes, como el runtime del |
| 105 | +proceso, servicio, host o sistema operativo. |
| 106 | + |
| 107 | +Para más información, consulta [Recursos](/docs/concepts/resources/). |
| 108 | + |
| 109 | +### Propagadores entre servicios |
| 110 | + |
| 111 | +La propagación es el mecanismo que transfiere datos entre servicios y procesos. |
| 112 | +Aunque no está limitado a las trazas, la propagación permite que las trazas |
| 113 | +construyan información causal sobre un sistema a través de servicios |
| 114 | +distribuidos arbitrariamente entre fronteras de procesos y redes. |
| 115 | + |
| 116 | +Para la gran mayoría de los casos, la propagación de contexto ocurre a través de |
| 117 | +librerías de instrumentación. Si es necesario, puedes utilizar propagadores tú |
| 118 | +mismo para serializar y deserializar intereses compartidos, como el contexto de |
| 119 | +un span y el [equipaje](/docs/concepts/signals/baggage/). |
| 120 | + |
| 121 | +### Muestreadores |
| 122 | + |
| 123 | +El muestreo es un proceso que restringe la cantidad de trazas generadas por un |
| 124 | +sistema. Cada implementación específica de OpenTelemetry para un lenguaje ofrece |
| 125 | +varios [muestreadores de cabecera](/docs/concepts/sampling/#head-sampling). |
| 126 | + |
| 127 | +Para más información, consulta [Muestreo](/docs/concepts/sampling). |
| 128 | + |
| 129 | +## Operador de Kubernetes |
| 130 | + |
| 131 | +El Operador de OpenTelemetry es una implementación de un Operador de Kubernetes. |
| 132 | +El operador gestiona el Collector de OpenTelemetry y la auto-instrumentación de |
| 133 | +las aplicaciones usando OpenTelemetry. |
| 134 | + |
| 135 | +Para más información, consulta el [Operador K8s](/docs/kubernetes/operator/). |
| 136 | + |
| 137 | +## Elementos de Función como Servicio |
| 138 | + |
| 139 | +OpenTelemetry soporta varios métodos de monitoreo para Function-as-a-Service |
| 140 | +proporcionados por diferentes proveedores de servicios en la nube. La comunidad |
| 141 | +de OpenTelemetry proporciona capas Lambda prefabricadas capaces de |
| 142 | +auto-instrumentar tu aplicación, así como la opción de una capa Lambda de |
| 143 | +Collector independiente que puede usarse al instrumentar aplicaciones manual o |
| 144 | +automáticamente. |
| 145 | + |
| 146 | +Para más información, consulta [Funciones como Servicio](/docs/faas/). |
0 commit comments