DOCSEARCHbyAlgolia
Submit Docs

OpenTelemetry Website Documentation

repository·main·Indexed 21 days ago

https://github.com/open-telemetry/opentelemetry.io

Source code and documentation for the official OpenTelemetry website. Includes guides for contributing content, managing the OpenTelemetry Registry, and technical details on Netlify Edge Functions for asset tracking and markdown negotiation. Also covers the documentation-sync tool for automating OpenTelemetry Collector component documentation from the ecosystem registry.

Tokens
425.6K
Snippets
944
Records
1.5K
Agent score
73%

What's inside opentelemetry.io

  1. What is OpenTelemetry?

    main

    OpenTelemetry is an open-source observability framework and toolkit designed to facilitate the generation, export, and collection of telemetry data, specifically traces, metrics, and logs.

    It is important to note that OpenTelemetry is not an observability backend (storage or visualization tool). Instead, it is vendor- and tool-agnostic, allowing you to send data to various backends such as Jaeger, Prometheus, or commercial offerings. Its primary goal is to enable easy instrumentation of applications and systems across different programming languages, infrastructures, and runtime environments without vendor lock-in.

  2. Overview of OpenTelemetry Operator capabilities

    main

    The OpenTelemetry Operator is a Kubernetes Operator designed to automate observability management within a cluster. It manages two primary functions:

    1. OpenTelemetry Collector Management: Automates the deployment and lifecycle of Collector instances.
    2. Auto-instrumentation: Automatically injects OpenTelemetry instrumentation libraries into your running workloads.

  3. Overview of the OpenTelemetry Operator

    main

    The OpenTelemetry (OTel) Operator is a Kubernetes Operator designed to manage OpenTelemetry components within a Kubernetes cluster. Its primary functions include:

    • Collector Management: Deploys and manages the OpenTelemetry Collector using the OpenTelemetryCollector custom resource (CR).
    • Fleet Configuration: Manages configurations for multiple Collectors via OpAMP integration, using the OpAMPBridge custom resource.
    • Prometheus Integration: Integrates with the Prometheus Operator's PodMonitor and ServiceMonitor custom resources.
    • Autoinstrumentation: Injects and configures autoinstrumentation into pods using the Instrumentation custom resource.

  4. Overview of the Site Observability project

    main

    The Site Observability project implements a public OpenTelemetry Collector to receive telemetry from opentelemetry.io and explorer.opentelemetry.io. This data is exported to backends for public, read-only inspection, providing community transparency into the performance and health of the project's own websites.

    Architecture Overview

    • Sources: Browser (OTel JS), Netlify Edge Functions, and Netlify log drains.
    • Ingestion: A public, write-only OTLP endpoint protected by rate limiting, CORS (restricted to site domains), and payload size limits.
    • Processing: The Collector performs sampling and scrubs sensitive fields (IP addresses, raw user agents, full referrer URLs, and query strings) to ensure privacy.
    • Backends: Data is exported to Jaeger (traces), Prometheus (metrics), and OpenSearch (logs). Backends are never directly reachable for ingestion; they are only accessible via public read-only query UIs.

  5. Overview of OpenTelemetry Java API Components

    main

    The OpenTelemetry Java API provides a set of classes and interfaces for recording telemetry signals (traces, metrics, and logs). It is designed to be a direct dependency for libraries and frameworks, offering strong backwards compatibility and zero transitive dependencies.

    Key components include:

    • Context API: For propagating context (like trace context and baggage) within and across application boundaries.
    • TracerProvider: The entry point for recording traces.
    • MeterProvider: The entry point for recording metrics.
    • LoggerProvider: The entry point for recording logs.
    • OpenTelemetry: A container that holds the TracerProvider, MeterProvider, LoggerProvider, and ContextPropagators, making it easy to pass all top-level components to instrumentation.

    There are two primary implementations:

    1. SDK: The reference implementation used by most users to process and export telemetry.
    2. No-op: A minimalist, zero-dependency implementation used by instrumentations when no SDK is installed.

  6. What is OpenTelemetry eBPF Instrumentation (OBI)?

    main

    OpenTelemetry eBPF Instrumentation (OBI) is an auto-instrumentation tool designed to provide application observability without requiring modifications to application code or configuration. It uses eBPF to inspect application executables and the OS networking layer to capture:

    • Trace spans: Related to web transactions.
    • RED metrics: Rate, Errors, and Duration metrics for Linux HTTP/S and gRPC services.
    • Network observability: Flows between services including byte/packet counters, TCP RTT, retransmit, and connection metrics.
    • Database & GenAI telemetry: Support for various databases (PostgreSQL, MySQL, etc.) and GenAI providers (OpenAI, Anthropic, etc.).

    OBI is lightweight, requires no code changes or library installations, and provides distributed tracing and log enrichment (correlating JSON logs with trace context).

  7. What is OTel Weaver?

    main

    OTel Weaver is an open-source CLI and automation platform designed to help teams manage, validate, and evolve semantic conventions. It enables an "observability by design" approach by treating telemetry like a public API, ensuring consistency and type-safety throughout the software development life cycle (SDLC).

    Key capabilities include:

    • Defining and versioning semantic conventions: Create, version, and share custom or extended telemetry schemas.
    • Policy-based validation: Enforce naming standards, stability, and immutability, and detect breaking changes.
    • Live instrumentation checks: Validate that application telemetry matches defined schemas and measure instrumentation coverage (similar to code coverage).
    • Code and documentation generation: Automatically generate Markdown documentation and programming language constants. Future support includes type-safe instrumentation helpers for languages like Go and Rust.
    • Schema evolution: Safely evolve schemas using automatic diffs and upgrade/downgrade support.

  9. Capabilities of the OpenTelemetry Demo 3.0

    main

    The OpenTelemetry Demo 3.0 has evolved from a simple shopping cart reference application into a multi-signal reference application. It is designed to demonstrate the following capabilities:

    • Agentic AI systems: Instrumentation patterns for AI agents.
    • Continuous profiling: Demonstrating profiling alongside traces, metrics, and logs.
    • Mixed instrumentation: Showcasing both zero-code (automatic) and manual instrumentation.
    • OpenFeature: Demonstrating feature flag evaluation with associated telemetry.
    • SQLCommenter: Demonstrating database query correlation via SQL comments.
    • Production-like scenarios: Using different standards to replicate real-world production environments.

  10. Understand OpenTelemetry's stability and release evolution

    main

    OpenTelemetry is evolving its stabilization and release practices to address complexity and improve production reliability. The project is moving towards a model where distributions are 'stable by default', meaning only components meeting a high, consistent bar for stability (including documentation, performance benchmarks, and example code) are enabled by default. Users will be able to opt-in to experimental or unstable features via standardized, documented configuration options.

    Key pillars of this evolution include:

    • Stable By Default: Standardized mechanisms to opt-in to unstable features.
    • Consistent Stability Criteria: Unified requirements for documentation, performance testing, and benchmarks.
    • Instrumentation Stability: Easier paths for instrumentation libraries to reach stability and federated semantic conventions.
    • Epoch Releases: New release types designed to be easier for large organizations to consume.

  11. Benefits of OpenTelemetry Protocol with Apache Arrow

    main

    The OpenTelemetry Protocol with Apache Arrow (OTel-Arrow) provides significant performance and cost benefits for telemetry transport compared to standard OTLP encoding.

    Key advantages include:

    • Compression: Achieves compression reductions of 15 to 30 times smaller than uncompressed data.
    • Bandwidth Efficiency: Generally offers 30% to 50% less network bandwidth usage than the standard OTLP protocol.
    • Scalability: Maintains reliability and scalability while reducing overall telemetry costs.

    This protocol is designed to eventually allow OpenTelemetry SDKs to produce this format directly and enable telemetry processors to be written using Apache Arrow libraries.

  12. Key capabilities of Go Compile-Time Instrumentation v1

    main

    The otelc tool provides several core benefits for Go developers and platform engineers:

    • Zero-code instrumentation: Automatically instruments applications and dependencies without manual code edits.
    • No runtime overhead: Instrumentation is built into the binary at compile time rather than attached at runtime.
    • Broad coverage: Instruments the standard library and third-party packages (e.g., net/http, database/sql, gRPC, Redis).
    • Extensible: Supports adding new library coverage via an instrumentation-rule format.
    • Compliance: Emitted telemetry follows standard OpenTelemetry semantic conventions.
    • CI/CD Integration: Designed to be dropped easily into build pipelines or development environments.