Skip to content
Sluiciodocs
Search guides /
Join the waitlist
Overview · Concept Beginner

What you get from your telemetry

Once a service emits OTLP to Sluicio, what becomes possible — automatic discovery, end-to-end traces, message-flow and completion tracking, errors, metrics, logs, dashboards and alerts.

SLSluicio team 5 min read Updated Jun 2026

You point a service (or an OpenTelemetry Collector) at Sluicio and start sending OTLP — traces, metrics, logs. From that moment Sluicio organises and acts on the stream for you. No schema to define up front, no dashboards to build before you see anything. Here’s what that telemetry turns into.

Your services and systems appear — automatically

Section titled “Your services and systems appear — automatically”

Every service that sends data shows up on its own, identified by its OTLP resource attributes (its service name). Sluicio groups related services into service types and into systems, and draws a topology of how they call each other — so a brand-new service is on the map within seconds of its first span, with nothing to register.

Follow any message end to end

Section titled “Follow any message end to end”

Each request becomes one connected trace. Open it as a waterfall to see every hop — inbound call, database queries, outbound requests, your own custom spans — nested where they actually ran, with timings. Global search lets you find the exact trace by service, span name, status, or any attribute you set, so “the order that failed at 14:02” is a query, not a log dig.

Integrations and their message flow

Section titled “Integrations and their message flow”

Beyond raw services, Sluicio models integrations — the flows messages travel through. For each integration you get its messages, logs, errors, attribute keys/values to filter on, and a view of the flow itself. This is what makes it useful for system-to-system integration, not just app performance.

Catch what breaks — or quietly stalls

Section titled “Catch what breaks — or quietly stalls”
  • Errors are surfaced per service and per integration, so failures aren’t buried in trace volume.
  • Success rate and health are tracked continuously — you can see when a service or integration starts degrading.
  • Flow-completion rules detect messages that started but never finished — the silent failures a plain error count misses. Messages that don’t complete their expected stages within a window show up as stuck messages.

Metrics and logs, not only traces

Section titled “Metrics and logs, not only traces”

Sluicio ingests all three OTLP signals. Metrics land in a browsable metric catalog you can chart; logs are searchable alongside the traces and messages they belong to, so a log line and its trace are one click apart.

Organise it your way

Section titled “Organise it your way”
  • Tags and facets on services and integrations for the groupings your team thinks in.
  • Metadata fields to attach the business context that matters to you.
  • Systems and service types to roll many services up into the things you actually operate.
  • Monitoring templates to apply a consistent set of rules across similar integrations.

Watch it and get told

Section titled “Watch it and get told”
  • Dashboards compose the metrics and views your team keeps an eye on.
  • A digest summarises what’s happening so you don’t have to go looking.
  • Alert rules fire on the conditions you care about — error rates, backlog, a stuck flow — and deliver to your notification channels (email and webhook), so you’re paged the moment something slips.

Where to go next

Section titled “Where to go next”