Every integration landscape we’ve seen is a zoo. Kafka in one corner, RabbitMQ in another, a Debezium connector quietly copying a database, an API gateway in front of everything. Each animal arrived for a good reason, each has a different keeper, and each speaks its own dialect.
The good news: most of them already emit OpenTelemetry telemetry, or something a Collector receiver can turn into it. The kafkametrics receiver, the JMX metrics from Debezium, a Prometheus exporter for NATS — the data flows.
The less good news: raw telemetry is just metric names and numbers. kafka.partition.replicas_in_sync arriving at your backend doesn’t tell you that a partition with zero in-sync replicas is a page-someone-now problem. That knowledge, what a thing is, and what healthy looks like for it, usually lives in two places: someone’s head, and a hand-built dashboard that person made three jobs ago. Neither survives contact with staff turnover.
Our take: make that knowledge an artifact
We think the “what is this and what does healthy mean” knowledge should be a first-class, declarative artifact — not tribal memory, not dashboard archaeology. In Sluicio, that artifact is called a system type.
A system type is three things bundled together:
Detection. A set of metric-name prefixes that recognize a system from the telemetry it already emits. Metrics starting with kafka. mean the kafkametrics receiver is watching an Apache Kafka broker. confluent_kafka_server_* means the Confluent Cloud Metrics API, scraped through a prometheus receiver. gnatsd_* is the NATS exporter; debezium* is Debezium’s JMX metrics. When a service’s metrics match a type’s prefixes, Sluicio suggests the matching template automatically — you confirm, not configure.
Identity. The system shows up in the Systems view as what it is — a Kafka broker, a Debezium connector — rather than as an anonymous box emitting numbers.
Starter health checks. Each type ships with checks encoding what typically goes wrong for that class of system. For Kafka: a partition with zero in-sync replicas is critical. For Debezium: more than 60 seconds behind the source is a warning. These are the failure modes people learn the hard way, written down.
The property we care about most: all of this works on telemetry you’re already emitting. There’s no agent to install, no configuration to inject, nothing that reaches into your environment. Your Collector ships the data across the wire, exactly as before; the interpretation happens entirely on Sluicio’s side of it. Your side stays untouched — which is precisely how your security team prefers it.
Starter checks, not black boxes
A word on what “applying a type” actually does, because monitoring products have burned enough trust here.
Applying a system type creates ordinary alert rules. They’re visible in the same place as every rule you write by hand. You can tune the thresholds, route them to your notification channels, or delete the ones that don’t fit. Nothing is hidden behind a “smart” toggle, and no proprietary scoring decides what matters on your behalf.
Checks aren’t limited to metrics, either — they can watch metric, log, and trace signals. And where it matters, they split by the dimension you actually page on: a consumer-lag check defined as “lag > 1000, split by group” doesn’t just tell you that lag exists somewhere — it names which consumer group fell behind.
The defaults are opinionated, and they admit to being starting points. “60 seconds behind source” is a sensible warning threshold for most CDC pipelines; yours might tolerate five minutes, or nothing at all. The point of a starter check is that you start from something written by someone who has operated the thing — and then make it yours.
Small YAML, deliberately portable
A system type is a small YAML document. Here’s the shape of one:
format: sluicio/system-type/v1
key: debezium
label: Debezium
is_system: true
detect_prefixes:
- debezium
checks:
- name: Debezium disconnected
description: A connector lost its database connection — change capture has stopped.
metric: debezium_metrics_Connected
agg: min
op: lt
threshold: 1
severity: critical
- name: Debezium replication lag
description: Change capture is running more than 60s behind the source database.
metric: debezium_metrics_MilliSecondsBehindSource
agg: max
op: gt
threshold: 60000
severity: warning
unit: ms
display: true
- name: Debezium queue nearly full
description: The connector's internal event queue is nearly out of capacity — events aren't reaching Kafka fast enough.
metric: debezium_metrics_QueueRemainingCapacity
agg: min
op: lt
threshold: 100
severity: warning
unit: eventsThat’s the whole idea in one file: how to recognize the system, what to call it, what to worry about.
Because it’s just a document, it travels. You can export any type from the UI, share the file, and import it in another Sluicio installation. Import a type using a built-in’s key and it becomes your org’s override of that built-in — your Kafka opinions, layered over ours, without forking anything.
The person who ran it should write it
This is where we’d like some help.
We’ve published the system-type collection publicly at github.com/SLUICIO/sluicio-system-types, under Apache 2.0, seeded with all of our built-ins. Pull requests are welcome — for new types, and for better checks in existing ones.
The reasoning is simple: we are not the world’s leading experts on every broker, gateway, and connector ever deployed. The person who ran ActiveMQ Artemis in production for five years knows exactly which metric goes sideways first and at what value — knowledge that today lives in that person’s head and nowhere else. A system type is a place to put it, in a form that detects, names, and watches the thing automatically for the next team.
Monitoring vendors have traditionally treated this knowledge as product surface. We’d rather treat it as a commons: the checks are more useful shared than proprietary, and frankly, yours are better than ours for the systems you’ve operated longer than we have.
What’s in the catalog today
Current built-ins: RabbitMQ, ActiveMQ Artemis, Azure Service Bus, KrakenD, OTel Collector, .NET service, Apache Kafka, Confluent Kafka, NATS, and Debezium.
If you run something we don’t cover — an ESB from the era when XML was the future, a niche gateway, a broker with a fan club of twelve — you’re exactly the person we built the format for. Write the type, try it on your own telemetry, send the PR. The zoo is large; nobody knows every animal, but somebody knows each one.
Links:
- System-type collection: github.com/SLUICIO/sluicio-system-types
- Docs: docs.sluicio.com/system-types
- Demo: demo.sluicio.com/system-types