The green-dashboard outage
Picture the on-call story every integration team knows. Every service reports healthy. CPU is fine, memory is fine, the HTTP endpoints all return 200. And yet a partner’s purchase order that entered the pipeline at 02:00 never reached the ERP. No alert fired, because nothing that the monitoring watched actually failed.
This is the blind spot of classic application performance monitoring (APM): it is built to answer “is this service healthy?” Integration failures rarely look like an unhealthy service. They look like a message that stalled in a queue, a mapping that silently dropped a field, a retry that exhausted, a third party that started returning empty 200s, a dead-letter that nobody is watching.
Services vs. integrations
App monitoring treats each component as the unit of observation. That works when your system is the component. It breaks down when the thing you care about — a business process — is spread across many components from different vendors:
- An Azure Function (or an iPaaS flow) hands off to
- an Apache Camel route, which drops a message onto
- an ActiveMQ queue, consumed by
- a couple of native .NET worker services, which finally call a partner API.
Monitor each of those in isolation and every one can be “up” while the flow between them is dead. The outage lives in the seams — and the seams are exactly what per-service health checks don’t cover.
What OpenTelemetry changes
OpenTelemetry (OTel) is an open, vendor-neutral standard for traces, metrics, and logs. The important shift for integration teams is conceptual, not just technical: OTel lets you make the message the unit of observation instead of the host.
With distributed tracing, every hop a message takes becomes a span, and the whole journey becomes a trace. Trace context propagates across process, protocol, and vendor boundaries — so the dead-letter at 02:14 and the timeout three steps upstream show up as one connected story rather than two unrelated alerts. You can finally ask the questions that matter: Where did this order stop? Which leg was slow? Is this partner degrading, or are we?
Why OTel fits integration estates specifically
1. Vendor-neutral by design. Integration estates are heterogeneous on purpose — that’s the job. One instrumentation standard spanning Azure Functions, an iPaaS, Apache Camel, native .NET services, and your queues beats maintaining a different proprietary agent for each technology.
2. It follows the message, not the machine. Context propagation is built to cross the exact boundaries where integrations fail: between processes, between protocols, between organizations.
3. You keep your telemetry. OTel exports over OTLP, so the data is yours. You decide where it lives and how long you retain it — which matters when an audit asks you to reconstruct a transaction from six months ago, and matters again when a metered-retention SaaS bill makes “keep everything” unaffordable.
The takeaway
Monitoring each service in isolation will keep missing the outages that matter most to an integration team, because those outages happen in the flow between services. OpenTelemetry gives you a vendor-neutral way to trace that flow end to end — which is why we chose it as the foundation for Sluicio, an OTel-native, self-hosted monitoring tool built specifically for integration estates.
Sluicio is in private beta. If you run integrations and want to compare notes — or get on the waitlist — get in touch.