What Is OpenTelemetry? A Deep Dive into Its Architecture, History, and Go Demo

OpenTelemetry is a CNCF project that provides a standardized set of APIs, SDKs, tools, and integrations for generating, collecting, processing, and exporting telemetry data such as traces, metrics, and logs. It decouples instrumentation from any specific observability backend.

Problem Domain

Observability aims to infer internal system states from external outputs. In software this is achieved with logs, metrics, and traces. OpenTelemetry standardizes the data model, collection, processing, and export for these signal types.

Solution Overview

The OpenTelemetry specification defines a unified data model and standard methods for handling traces, metrics, and logs. Language‑specific SDKs (e.g., opentelemetry-go, opentelemetry-java, opentelemetry-js) simplify instrumentation, while the opentelemetry-collector and its contrib plugins provide configurable pipelines for receiving, processing, and exporting telemetry.

Architecture

History

OpenTelemetry originated from the merger of OpenCensus (traces and metrics) and OpenTracing (traces) in May 2019. The tracing specification reached 1.0 in February 2021 (stable), metrics are at beta, and logs are at alpha.

Future Outlook

Vendor interest is growing, especially around exporters that integrate telemetry into proprietary services. The collector’s receiver and processor stages are expected to receive further investment, and the standardized data model helps avoid vendor lock‑in in multi‑cloud environments.

Go Demo

Repository: https://github.com/flyer103/otel-demo

The demo illustrates four scenarios:

Generating trace and metric data inside an application.

Using a stdout controller to collect, process, and print telemetry.

Using an OTLP controller to push data to an external collector.

Running a local collector that receives OTLP data and exports it to a file and Alibaba Cloud SLS.

Key files: cmd/app/server.go – initializes a global controller, generates business‑specific metrics and traces, and configures receivers, processors, and exporters via YAML. pkg/ – implementation of the controller and signal handling. yaml/ – example configuration that defines a receiver, processors, exporters (including an SLS exporter), and services.

Core Concepts

Signal – a telemetry type such as trace, metric, or log.

Instrument – an instance of a signal (e.g., a specific metric or span).

API – formal specification of OpenTelemetry, often expressed in protobuf.

SDK – language‑specific implementation of the API (e.g., opentelemetry-go).

Collector – a process that combines receivers, processors, exporters, and extensions.

Receiver – component that ingests telemetry data (e.g., OTLP receiver).

Processor – component that transforms or enriches telemetry before export.

Exporter – component that sends telemetry to a backend such as Prometheus, Jaeger, or cloud services.

Extension – auxiliary component (e.g., health check, service discovery) that does not process telemetry.

Service – configuration block that defines which receivers, processors, exporters, and extensions run together.

Using the Collector

A typical collector configuration (YAML) includes:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
processors:
  batch:
exporters:
  logging:
    loglevel: debug
  otlp:
    endpoint: your-backend:4317
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [logging, otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [logging, otlp]

This pipeline receives OTLP data over gRPC, batches it, logs it locally, and forwards it to the configured backend.

Conclusion

OpenTelemetry provides a vendor‑neutral, standardized approach for generating, collecting, processing, and exporting observability data. Its SDKs, collector, and ecosystem enable developers and SREs to instrument applications once and export to multiple backends such as Prometheus, Jaeger, or cloud services, reducing integration effort and avoiding lock‑in.