Skip to main content

What is OpenTelemetry?

OpenTelemetry (OTel) is an open-source observability framework that has emerged as the industry standard for generating, collecting, and managing telemetry data in distributed systems. As stated in the official OpenTelemetry documentation, it provides a unified set of tools, APIs, and SDKs that enable developers to instrument their applications for collecting traces, metrics, and logs.

Key Components: API, SDK, Collector​

OpenTelemetry's architecture consists of three main components:

  1. API (Application Programming Interface):

    • Defines the standard interfaces for generating telemetry data
    • Provides language-specific implementations
    • As described in SigNoz's OpenTelemetry guide, the API ensures vendor-neutral instrumentation while maintaining consistency across your codebase
  2. SDK (Software Development Kit):

    • Implements the OpenTelemetry APIs
    • Handles data processing and export
    • Manages sampling, batching, and data enrichment
  3. Collector:

    • According to the Better Stack guide on OpenTelemetry Collector, it acts as a vendor-agnostic proxy that receives, processes, and exports telemetry data
    • Supports multiple data formats and export destinations
    • Provides built-in reliability and scaling features

Automatic vs. Manual Instrumentation​

OpenTelemetry offers two approaches to instrumentation:

Automatic Instrumentation:

  • Requires minimal code changes
  • Provides out-of-the-box monitoring for common frameworks and libraries
  • Ideal for quick implementation and standard use cases

Manual Instrumentation:

  • Offers fine-grained control over telemetry data
  • Enables custom business metrics and traces
  • Allows for detailed application-specific monitoring

The OpenTelemetry Concepts documentation recommends combining both approaches to achieve comprehensive observability while maintaining flexibility for specific use cases.

Practical Examples​

Automatic instrumentation (Node.js with Express):

// No application code changes needed; the agent handles instrumentation
const otel = require('@opentelemetry/auto-instrumentations-node');

Manual instrumentation (Node.js):

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { ConsoleSpanExporter } = require('@opentelemetry/sdk-trace-node');

const sdk = new NodeSDK({
traceExporter: new ConsoleSpanExporter(),
instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

const tracer = require('@opentelemetry/api').trace.getTracer('my-app');
const span = tracer.startSpan('custom-operation');
span.end();

Semantic Conventions​

Semantic conventions define a standardized naming and tagging scheme for telemetry data, ensuring consistency across applications and tools. For example:

  • HTTP spans: Use http.method, http.status_code, http.url for request attributes
  • Database spans: Use db.system, db.statement, db.connection_string for query details
  • Service attributes: Use service.name, service.version for metadata

This standardization enables observability platforms to correlate data reliably and apply built-in dashboards and alerts across different services.

Benefits of Standardized Telemetry​

Standardized telemetry through OpenTelemetry offers several key advantages:

  1. Vendor Independence:

    • Freedom to switch between observability backends without re-instrumentation
    • No vendor lock-in
    • Consistent instrumentation across different providers
  2. Future-Proof Investment:

    • Industry-wide adoption supported by 40+ observability vendors
    • Active community development and vendor contributions
    • Standards align with CNCF Cloud Native initiatives
  3. Unified Observability:

    • Consistent data collection across services and languages
    • Improved correlation between traces, metrics, and logs
    • Enables end-to-end visibility in distributed systems

How Beakpoint Leverages OTel​

Beakpoint integrates OpenTelemetry to provide comprehensive observability solutions:

  • Distributed Tracing: Tracks requests end-to-end across microservices to identify latency sources and service dependencies
  • Performance Metrics: Collects standardized metrics for CPU usage, memory, request latency, and application-specific KPIs
  • Automated Instrumentation: Uses automatic instrumentation for frameworks (Spring, Django, Express) while adding custom telemetry for business-critical operations
  • Scalable Collection: Deploys the OpenTelemetry Collector as a centralized gateway to process, enrich, and route telemetry data to multiple backends

This approach ensures clients gain immediate visibility into their systems without extensive code changes, while retaining the flexibility to instrument custom workflows.