Skip to content

Commit c8295a6

Browse files
mlunadiatheletterf
andauthored
[es] adding docs/concepts/components (#5391)
Co-authored-by: Fabrizio Ferri-Benedetti <[email protected]>
1 parent f74ac93 commit c8295a6

File tree

1 file changed

+146
-0
lines changed

1 file changed

+146
-0
lines changed
+146
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
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

Comments
 (0)