At the beginning of 2025, the OpenTelemetry Developer Experience SIG published the results of its first community survey. One of the strongest themes was clear: teams want more real-world examples of how the OpenTelemetry SDKs and the OpenTelemetry Collector are actually used in production.
To help close that gap, the SIG began collecting stories directly from end users—across industries, architectures, and company sizes. This post kicks off a new series focused specifically on organizations’ real world stories, starting with a small but uniquely challenging case.

OpenTelemetry's platform is an observability framework, offering insights into distributed tracing, metrics collection, and log management for cloud-native applications. Through documentation, tutorials, and community contributions, OpenTelemetry provides insights into instrumenting applications to monitor performance and troubleshoot issues. Developers and DevOps teams can learn about distributed tracing standards, telemetry data formats, and integration with observability tools to gain visibility into complex distributed systems.

OpenTelemetry

Mastodon, a non-profit decentralized social platform with ~20 staff, shares how a single engineer runs OpenTelemetry Collectors in production across two large Kubernetes deployments handling up to 10 million requests per minute. The setup uses one Collector per Kubernetes namespace, managed via the OpenTelemetry Operator and Argo CD, with no complex gateway tiers. Traffic is controlled through tail-based sampling (0.1% for successful traces, 100% for errors). The full production config is shared, including OTLP ingestion, Kubernetes metadata enrichment, resource detection, and Datadog export. Key lessons: keep architecture simple, use Kubernetes operators for lifecycle management, rely on semantic conventions, and upgrade frequently.

How Mastodon Runs OpenTelemetry Collectors in Production

Collector architecture: One per namespace, no more