Operations | Monitoring | ITSM | DevOps | Cloud

How to Install and Configure an OpenTelemetry Collector

Originally published June 2024. Updated May 2026. A lot has changed since the first version of this guide. In May 2026, OpenTelemetry officially graduated within the CNCF, the highest maturity level a project can achieve. All three core signals (metrics, logs, and traces) are now stable across every major language SDK. Collector adoption has never been higher, and the ecosystem around it, particularly OpAMP for remote management, has matured significantly. This update walks through three things.

You don't need to pick one: how Sentry and OpenTelemetry work together

You already instrumented the backend with OpenTelemetry. Your services emit spans. Your teams know the OTel APIs. Maybe you already run a Collector. So when you start evaluating Sentry, the obvious question is: Do you need to replace your OpenTelemetry setup with the Sentry SDK? No. The practical answer is usually: keep OpenTelemetry where it already works, add the Sentry SDK where it gives you more application context, and send OpenTelemetry Protocol (OTLP) events to Sentry.

Explore for Spans: One View with Infinite Depth

It’s 20 minutes into a P0 incident, and you have already switched between four different tools, re-authenticated twice, and translated queries across three incompatible syntax languages. The root cause you are searching for. Well, that is still out there somewhere. The reality of investigative latency is that most engineering teams face navigation problems, not data problems. During high-pressure incidents, teams lose cognitive momentum due to context switching between disconnected telemetry silos.

OpenTelemetry Monitoring with Netdata

If you've standardized on OpenTelemetry (or you're heading that way), you probably know the collector gets your data out, but where it lands and how useful it is once it gets there are separate problems. Netdata now ingests both OTLP metrics and OTLP logs natively, so your OTel pipelines feed directly into the same monitoring experience as everything else in your infrastructure: same dashboards, same alerting, same query interface. No separate backends, no context switching.

Anthropic Monitoring & Observability with OpenTelemetry and SigNoz

Learn how to implement end-to-end monitoring and observability for Anthropic (Claude) API-based applications using OpenTelemetry and SigNoz. In this video, we walk through instrumenting your Anthropic API calls, collecting traces, metrics, and logs, and visualizing everything in SigNoz to gain real-time visibility into performance, failures, and bottlenecks. You'll see how to move from basic logging to production-grade observability, so you can debug faster, optimize latency, and confidently run Claude-powered AI systems at scale.

Using AI to Instrument Applications with OpenTelemetry

OpenTelemetry is one of the best things that’s happened to observability in the last decade. It’s open. It has SDKs for every language that matters. It’s vendor neutral. The OTel community has been doing the hard work of standardizing how applications emit telemetry, so that you, the engineer, don’t have to learn five different agent formats to monitor five different services.

Building a CloudWatch metrics pipeline: parsing OpenTelemetry data

AWS delivers CloudWatch metrics in OpenTelemetry format via Firehose, but AppSignal uses its own internal format. Building the parser to bridge these two formats presented several technical challenges. The metrics arriving through this pipe power AWS automated dashboards. When AppSignal detects metrics from a supported AWS service, it creates a dashboard for it automatically, with pre-built charts grouped by category: compute, databases, networking, messaging, storage, and others.

One Collector, Two Teams: How Bindplane Bridges Security and Observability with OpenTelemetry

Observability engineers will spend weeks tuning instrumentation. Security engineers? They want a collector installed and logs flowing — yesterday. And that's actually the magic of OpenTelemetry + Bindplane: from day one you're routing firewall logs, endpoint data, server logs straight into your SIEM with zero instrumentation lift. One toolchain. Two teams. No silos. Filmed at Google Cloud Next '26 — Las Vegas bindplane.com#OpenTelemetry.

Contributing Distributed Partition Ownership to the Azure Event Hub Receiver

If you're running OpenTelemetry collectors against Azure Event Hubs, distributed partition ownership and checkpointing just got significantly better. Your fleet now self-organizes. Failover is automatic. Restarts don't lose data. Here's how we got here.

OpenTelemetry Fleet Management: Scalable Control

OpenTelemetry has turned observability pipelines into production infrastructure, but managing them at scale often creates a massive operational burden. In this demo, we show how Coralogix Fleet Management acts as the central control plane for your OTel ecosystem, providing the governance and orchestration required for modern DevOps. Stop the "manual marathon" of PRs and Helm upgrades. Move toward a safer, more predictable operating model where telemetry is consistent, audited, and scalable.

Turn Noisy Logs Into Structured Data with Uptrace Grouping Rules

Here are 3 YouTube title options plus a description optimized for technical/dev audiences: Same log pattern. Hundreds of useless groups. In this video, we show how to use Uptrace Grouping Rules to automatically turn noisy logs into structured, searchable data — without changing application code. You'll learn how to: Examples covered: Perfect for:#OpenTelemetry users, backend engineers, SREs, and anyone dealing with noisy logs.

Making Semantic Conventions Work for You With OpenTelemetry Weaver

Your dataset has hundreds of attributes. Some are self-explanatory: http.response.status_code, server.address. Others are not: meta.refinery.reason, dataset.slug, sli.latency_target_ms. If you don't know what an attribute means, you can't write a good query. And if an AI agent doesn't know what it means, it guesses.

Managing OpenTelemetry at Scale: Why OTel Pipelines Need a Control Plane

OpenTelemetry made telemetry possible everywhere – turning observability pipelines into distributed production infrastructure. Distributed infrastructure requires a control plane for inventory, governance, and safe change. At 500 collectors across hybrid environments, operational overhead becomes a production risk. The moment telemetry pipelines become a distributed infrastructure, they inherit the operational problems of one.

Span or Attribute in OpenTelemetry Custom Instrumentation

TL;DR: Attribute. More information on one event gives us more correlation power. It’s also cheaper. When you want to add some information to your tracing telemetry, you could emit a log, create a span, or add a piece of data to your current span. Adding a piece of data to your current span is the best! Usually.

Faster OpenTelemetry Migrations from Splunk to SecOps with Bindplane

Many security teams are looking to move off Splunk, whether to reduce licensing costs, consolidate their SIEM, or take advantage of Google SecOps' built-in threat intelligence and YARA-L detection capabilities. But migrations aren’t easy, and no one wants to run blind while they evaluate and move to a new platform. With OpenTelemetry and Bindplane, you can easily make the switch to SecOps without impacting your existing stack.

Taming Log Noise With the OpenTelemetry Collector's Drain Processor

Do you receive 50 million log lines per day and struggle to see what actually matters? Health checks, heartbeat pings, connection pool messages—they all drown out the errors and anomalies you're trying to find. Most teams deal with this by writing filter rules to drop the noisy patterns. But those rules are manual, per-pattern, and brittle. A new deployment changes a log format and the filter misses it. A new service starts logging a chatty startup sequence nobody thought to exclude.

OpenTelemetry VM Setup Guide: SigNoz Collection Agents Explained

About This Video: If you're working with OpenTelemetry, managing collector configurations across environments like VMs can quickly become difficult. In this video, we focus on VM-based setups and walk through how to configure SigNoz Collection Agents step by step. We start with an introduction to VM collection agents, then move into a practical project walkthrough using the OpenTelemetry demo. From there, we explore the documentation, set up configurations, run the collector, and finally validate everything inside SigNoz.

Stop ECS Containers From Collapsing Into One Service in OpenTelemetry

Why ECS containers collapse under service.name = aws_ecs and how to fix it for both EC2 launch type and Fargate, including the resource-vs-log-record pitfall that quietly breaks log filtering. Prathamesh works as an evangelist at Last9, runs SRE stories - where SRE and DevOps folks share their stories, and maintains o11y.wiki - a glossary of all terms related to observability.

Telemetry Talks ep 4: Retroactive sampling and OpenTelemetry

This episode of Telemetry Talks explores the evolution of an OTLP/gRPC tracing pipeline for VictoriaTraces within OpenTelemetry and VictoriaMetrics, including a shift from standard gRPC-Go to a simplified HTTP/2-based implementation to reduce complexity and improve flexibility. Together with the our guest, Jiekun, we revisited the VictoriaMetrics KubeCon talk ideas on tail-based and retroactive sampling — and their impact on the broader OpenTelemetry community.