One of the most relatable slides at the Grafana Labs OpenTelemetry event in Amsterdam wasn’t about a fancy new protocol or cutting-edge research. It was the title that got the biggest laugh of the afternoon: “Installing everything by hand sucks.”
“Installing everything by hand sucks.” — A slide that resonated with everyone who’s spent a late night wrestling with manual OTel setup.
The Pain Is Real
The slide laid out the problem in two bullet points:
- “Confusing if you’ve never done it before”
- “Which by definition you have not”
This is the fundamental problem with manual OpenTelemetry installation: it’s a skill you only learn by struggling through it once. And then you have to teach it to everyone else on your team. Each new engineer joining the project faces a learning curve that’s steep, confusing, and — let’s be honest — frustrating.
The One-Click Question
The follow-up slide asked the question every organization wrestling with OpenTelemetry rollout should consider:
“Can we bundle everything up into a one-click experience?”
The answer, increasingly, is yes. But getting there requires solving a hard design problem: how do you abstract away the complexity without losing the flexibility that advanced users need?
What “One-Click” Actually Means
A true one-click OpenTelemetry experience needs to handle:
- Instrumentation — automatic library injection across all services (Python, Go, Java, Node.js, .NET)
- Collection — the Collector deployment, configured for the right sampling and routing
- Export — where telemetry flows (your backend, a vendor, or both)
- Dashboarding — pre-built dashboards for common service types
- Alerting — default SLO-based alerting with escalation paths
The challenge is that each organization’s stack is different. A fintech company’s requirements for security, compliance, and auditability are worlds apart from a SaaS startup’s need for speed and experimentation.
The Tooling Evolution
Five years ago, deploying OpenTelemetry meant:
- Reading documentation across multiple repos
- Configuring the Collector YAML by hand
- Writing custom instrumentation for each service
- Debugging sampling and batching issues in production
Today, the first-time experience is dramatically better:
apt install opentelemetryAnd get complete instrumentation — automatic, across all languages — including the Collector, auto-instrumentation, and Helm charts for Kubernetes.
Maintaining Everything Forever
But one-click installation is only half the battle. The next challenge is what happens after the initial deploy:
“Maintaining everything forever.”
The slide listed three ongoing concerns:
- Complexity at scale
- Hard to track things
- Costs grow faster than you can control
This is where many organizations hit the wall. They’ve deployed OpenTelemetry, but now they’re responsible for running it, upgrading it, tuning it, and paying for it — forever. The operational overhead can quickly eat up the engineering time that the platform was supposed to save.
The Patchwork Problem
The “too many pieces” problem compounds the maintenance burden:
When you have different techniques for getting at different types of data, and no one team has access to everything, you end up with a patchwork of tools that each need their own maintenance cycle, their own upgrade schedule, their own cost model.
Three Strategies for Adoption at Scale
Based on the discussions at the event, here are three strategies that teams are using to avoid the manual-installation trap:
1. Start with the Defaults
Modern OpenTelemetry distributions ship with sensible defaults that work for most environments. Don’t customize on day one — get the defaults working end-to-end, then iterate.
2. Standardize the Base Layer
Before you instrument custom business logic, make sure every host, container, and cloud service is emitting telemetry. This is the “Infrastructure Visibility” layer from the Hierarchy of Observability Needs.
3. Automate Upgrades
Set up automated pipelines for Collector and SDK upgrades, with staging environments that catch breaking changes before they reach production.
The Road Ahead
The community is actively working on simplifying the deployment story. The goal is a future where rolling out OpenTelemetry across an organization is as routine as installing a package — and maintaining it is as straightforward as patching any other dependency.
Until then, the message from the event was clear: stop installing everything by hand. Bundle it, automate it, and make it repeatable.
Related Reading
- How to Roll Out OpenTelemetry at Scale: Grafana Labs Amsterdam Recap
- Ted and Ed’s Hierarchy of Observability Needs
- Observability IRL: Fire Lookout Towers and Software Monitoring
About the Author
I am Luca Berton, AI and Cloud Advisor. I work at the intersection of cloud security, platform engineering, and enterprise AI deployments. Book a consultation.
