AWS Builder Center

Builder Center

¿Qué tan profundas son tus raíces en OpenTelemetry? Un repaso técnico a través del OTel Quiz de OllyGarden

Diez preguntas, diez dominios: de semantic conventions a compilación zero-code en Go.

Series: opentelemetry (4 articles)

  1. 1
    ¿Qué tan profundas son tus raíces en OpenTelemetry? Un repaso técnico a través del OTel Quiz de OllyGarden This article
  2. 2
    Más allá del Texto en Disco: Cómo los Logs Estructurados y la Observabilidad Transforman tu Arquitectura Cloud
  3. 3
    Demistificando las Métricas: La Primera Línea de Defensa en la Observabilidad de Sistemas Distribuidos

Jhonnatan GIl

Introducción

OpenTelemetry (OTel) es hoy el estándar de facto para generar, transformar y exportar telemetría de forma vendor-neutral. Su superficie ha crecido mucho: especificación, SDKs por lenguaje, Collector, lenguajes de transformación, tooling para convenciones semánticas y más. Es fácil dominar una capa y tener puntos ciegos en otra.
OllyGarden  publicó el OTel Quiz , una evaluación de 10 preguntas, una por cada dominio clave del ecosistema. Cada pregunta muestra una explicación inmediata y al final entrega un score compartible. No requiere registro. Según la página, las preguntas están pensadas para desafiar a SREs, ingenieros de software y maintainers de OpenTelemetry.
En este artículo reviso los diez dominios que cubre el quiz, qué conviene dominar de cada uno y cómo se relacionan en una arquitectura de observabilidad real.
Nota: OllyGarden no está respaldada por la Linux Foundation, la CNCF ni el proyecto OpenTelemetry. Este artículo es una reseña independiente de la herramienta.

Cómo funciona el quiz

  • 10 preguntas, una por tópico, tomadas de cada área en cada ejecución.
  • Explicación inmediata tras cada respuesta.
  • Score compartible al final.
  • Sin sign-up.
👉 Hacer el quiz 

El mapa de conocimiento: dónde vive cada dominio

Antes de ir tópico por tópico, conviene ubicar cada área dentro del pipeline de telemetría:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
┌──────────────────────────────────────────────────────────────────────────┐
│ DESARROLLO / BUILD TIME │
│ │
│ ┌───────────────┐ genera código ┌────────────────────────────┐ │
│ │ Weaver │ ────────────────► │ Instrumentación tipada │ │
│ │ (registry de │ │ (constantes, helpers) │ │
│ │ semconv) │ └────────────────────────────┘ │
│ └───────────────┘ ┌────────────────────────────┐ │
│ │ otelc (Go, compile-time │ │
│ │ zero-code instrumentation)│ │
│ └────────────────────────────┘ │
└──────────────────────────────────────┬───────────────────────────────────┘
│
┌──────────────────────────────────────▼───────────────────────────────────┐
│ APLICACIÓN (RUNTIME) │
│ │
│ ┌────────┐ ┌─────────┐ ┌──────┐ ┌───────────────────────┐ │
│ │ Traces │ │ Metrics │ │ Logs │ ──────► │ SDK │ │
│ │ +ctx │ │ +views │ │+bridge│ │ Providers │ │
│ └────────┘ └─────────┘ └──────┘ │ Processors │ │
│ ▲ Semantic Conventions │ Exporters │ │
│ │ (nombres y atributos) │ Head Sampling │ │
│ └───────────┬───────────┘ │
└───────────────────────────────────────────────────────┼──────────────────┘
│ OTLP
┌───────────────────────────────────────────────────────▼──────────────────┐
│ OPENTELEMETRY COLLECTOR │
│ │
│ Receivers ──► Processors (OTTL, tail sampling, batch...) ──► Exporters │
│ │
└───────────────────────────────────────────────────────┬──────────────────┘
│
▼
Backend(s) de observabilidad
Este diagrama es una vista conceptual. Los componentes concretos varían según tu stack.

Los 10 dominios del quiz

1. Semantic Conventions

Definen los nombres de atributos y spans y las reglas de estabilidad que hacen comparable la telemetría entre servicios, equipos y vendors. Sin convenciones consistentes, un dashboard o una alerta que funciona para un servicio no sirve para el siguiente.
Puntos clave a dominar:
  • Nomenclatura de atributos (namespaces, ej. http.*, db.*).
  • Niveles de estabilidad y qué implica una migración entre versiones.
  • Impacto en la cardinalidad y en la consultabilidad.
📚 Semantic Conventions (docs oficiales) 

2. SDKs y zero-code instrumentation

Cubre la configuración de providers, processors y exporters, y qué aportan los agentes y la instrumentación automática frente a la manual.
Puntos clave:
  • Ciclo de vida del TracerProvider, MeterProvider y LoggerProvider.
  • SimpleProcessor vs BatchProcessor y sus implicaciones de rendimiento.
  • Qué cubre la instrumentación automática y dónde sigue siendo necesaria la manual.
📚 Zero-code instrumentation  · Language APIs & SDKs 

3. Traces y contexto

Spans, span kinds (CLIENT, SERVER, PRODUCER, CONSUMER, INTERNAL) y propagación de contexto entre procesos.
Puntos clave:
  • Elegir correctamente el SpanKind, que afecta cómo los backends construyen service maps.
  • Propagadores (W3C Trace Context, baggage) y su inyección/extracción en fronteras de proceso.
  • Relaciones padre-hijo y links.
📚 Context propagation  · Traces 

4. Metrics

Instrumentos, temporalidad, agregación y views.
Puntos clave:
  • Counter, UpDownCounter, Histogram, Gauge y sus variantes asíncronas.
  • Temporalidad delta vs cumulative y su impacto en el backend.
  • Uso de Views para controlar agregaciones y atributos, y así gestionar la cardinalidad.
📚 Metrics  · Metrics SDK spec 

5. Logs

El log data model, los bridges desde librerías de logging existentes y la correlación con trazas.
Puntos clave:
  • OTel no reemplaza tu logger, lo integra mediante appenders/bridges.
  • Correlación vía trace_id y span_id en el log record.
  • Severidad y campos del data model.
📚 Logs  · Logs Data Model 

6. El Collector

Receivers, processors, exporters y pipelines. Es el componente central para desacoplar la instrumentación del backend.
Puntos clave:
  • Estructura de la configuración (receivers, processors, exporters, service.pipelines).
  • Orden de los processors, que importa.
  • Patrones de despliegue: agent, gateway, o ambos.
yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
receivers:
otlp:
protocols:
grpc:
http:

processors:
batch:

exporters:
otlp:
endpoint: backend:4317

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
📚 OpenTelemetry Collector 

7. OTTL

El OpenTelemetry Transformation Language permite filtrar y remodelar telemetría dentro del Collector (por ejemplo, con los processors transform y filter).
Puntos clave:
  • Contextos (resource, scope, span, log, etc.) y el path de acceso a campos.
  • Editors y converters.
  • Redacción de datos sensibles, normalización de atributos y descarte de ruido.
📚 OTTL en opentelemetry-collector-contrib 

8. Sampling

Head vs tail sampling y qué sacrifica cada uno.
EstrategiaDecisiónVentajaCosto
HeadAl inicio de la trazaBarato, simple, sin bufferingNo sabe si la traza será interesante (errores, latencia)
TailCon la traza completaMuestreo basado en resultadoRequiere buffering y que todos los spans de una traza lleguen al mismo Collector
Punto clave: el tail sampling impone restricciones de arquitectura (por ejemplo, enrutamiento por trace_id en despliegues con múltiples instancias).
1
2
3
4
5
6
7
App ──► Collector (agent) ──► Collector (gateway: load-balancing por trace_id)
│
▼
Collector (tail sampling)
│
▼
Backend
📚 Sampling 

9. Weaver

Herramienta para definir, validar y generar código a partir de registries de semantic conventions. Permite tratar las convenciones como código: versionadas, validadas en CI y con generación de artefactos tipados.
Casos de uso:
  • Definir un registry propio que extienda las convenciones oficiales.
  • Validar en CI que la telemetría emitida cumple el registry.
  • Generar documentación y constantes de código.
📚 OpenTelemetry Weaver (GitHub) 

10. otelc

Instrumentación zero-code en tiempo de compilación para Go. Go no tiene un agente de runtime equivalente al de Java, por lo que esta categoría explora enfoques de compile-time para instrumentar sin modificar manualmente el código de la aplicación.
La página del quiz solo describe el dominio en una línea, así que para detalles técnicos consulta la documentación del proyecto y los recursos de OllyGarden.
📚 OllyGarden  · Documentación OllyGarden 

¿Por qué importa medirse?

Un quiz así sirve como diagnóstico de brechas. Algunos patrones típicos:
  • Quien domina SDKs pero no el Collector termina haciendo en la aplicación lo que debería resolverse en el pipeline (filtrado, redacción, enrutamiento).
  • Quien conoce el Collector pero no semconv produce telemetría inconsistente que ningún processor puede arreglar de forma sostenible.
  • Quien no entiende sampling toma decisiones de costo que degradan la capacidad de depuración.
La calidad de la telemetría es la suma de todas estas capas. OllyGarden posiciona su propuesta justamente en torno a ese problema: "transformar telemetría deficiente en insights accionables" (ver su Instrumentation Score  y Telemetry Quality ).

Cierre

El OTel Quiz es una forma rápida de contrastar tu conocimiento en las áreas que sostienen una estrategia de observabilidad con OpenTelemetry. Si alguna pregunta te hace dudar, esa es tu lista de lectura.
👉 Haz el quiz aquí: https://ollygarden.com/otel-quiz 
¿Cuánto sacaste? Cuéntalo en los comentarios y dime qué dominio te costó más.

Recursos oficiales

Tags sugeridos para Medium

OpenTelemetry · Observability · DevOps · SRE · Distributed Tracing · Cloud Native
(Medium permite hasta 5 tags; te recomiendo: OpenTelemetry, Observability, SRE, DevOps, Cloud Native.)
Nota de transparencia: OpenTelemetry, CNCF y Prometheus son marcas registradas de The Linux Foundation. Este artículo no está afiliado ni patrocinado por OllyGarden.
# observability# monitoring-observability# devops# sre

Series: opentelemetry (4 articles)

  1. 1
    ¿Qué tan profundas son tus raíces en OpenTelemetry? Un repaso técnico a través del OTel Quiz de OllyGarden This article
  2. 2
    Más allá del Texto en Disco: Cómo los Logs Estructurados y la Observabilidad Transforman tu Arquitectura Cloud
  3. 3
    Demistificando las Métricas: La Primera Línea de Defensa en la Observabilidad de Sistemas Distribuidos
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article