System types

A system type teaches Sluicio what kind of system is behind a stream of telemetry. From nothing but metric-name prefixes, Sluicio recognises that a service is, say, a RabbitMQ broker — gives it that identity in the Systems view — and offers a set of starter health checks written by people who know how that system fails. Accept the offer and the checks apply to the service as normal alert rules, ready to fire and ready to tune.

Sluicio ships eighteen built-in types. Each has its own reference page with the detection prefixes, the Collector configuration that gets the telemetry flowing, the full starter-check table, and tuning notes:

System type	Key	What it watches
RabbitMQ	rabbitmq	Broker alarms (memory, disk, file descriptors), queue backlog, stalled consumers, disk headroom
ActiveMQ Artemis	artemis	Queue backlog, stalled consumers, address memory pressure
Azure Service Bus	azure-servicebus	Dead-lettered messages and backlog, per queue and per subscription
KrakenD API Gateway	krakend	Gateway 5xx responses, p95 latency, silent gateway, backend failures and timeouts
WSO2 API Manager	wso2-apim	Failed API invocations, p95 latency, silent gateway, error-log spikes, JVM heap
Apache Kafka	kafka	Consumer-group lag, empty consumer groups, in-sync replicas, visible brokers
Confluent Kafka	confluent-kafka	Consumer lag, cluster load, hot partitions — via the Confluent Cloud Metrics API
NATS	nats	Slow consumers, client connections, server memory
Debezium	debezium	Connector connectivity, replication lag, internal queue capacity
Paperless-ngx	paperless-ngx	Document ingest failures and latency, queue backlog, unfiled documents, component health, storage headroom
OpenTelemetry Collector	otel-collector	Export failures, queue backlog, dropped and refused telemetry, memory
.NET service	dotnet-service	Thread-pool queuing, Kestrel connection queue, exceptions, error-log spikes
Kubernetes	kubernetes	Node readiness, deployment availability, container restart loops, failed pods and Jobs, node disk headroom
Apache Camel	camel	Per-route failures, dead-lettering, in-flight backlog, stopped routes, broker redeliveries, failed and slow exchanges
Node-RED	node-red	Failed and incomplete flow executions, slow flows, a runtime gone quiet
Apache Airflow	airflow	Per-DAG task and operator failures, a stopped scheduler, pool starvation, executor saturation
Airflow DAG processor	airflow-dag-processor	DAG import errors, a stopped processor, an empty DAG bag, stale or slow parsing
Airflow triggerer	airflow-triggerer	A stopped triggerer, a trigger blocking the async loop, capacity

Most types describe message brokers and gateways - infrastructure that can’t instrument itself. Seven (otel-collector, dotnet-service, camel, node-red and the three Airflow processes) are service types: they recognise a workload you run, not a system you scrape. One of those, node-red, is recognised from its span attributes rather than from metric names, because it has no metrics of its own to be recognised by. One (paperless-ngx) describes an application whose pipeline is the thing worth watching, not its uptime. One (kubernetes) describes the platform the others increasingly run on, and covers every conformant distribution - k0s, k3s, RKE2, MicroK8s, kubeadm, EKS, AKS, GKE and OpenShift - with a single type.

How detection, starter checks and overrides fit together

Detection is deliberately simple: each type declares one or more metric-name prefixes, and a service whose metrics match a prefix takes on that type. There’s nothing to tag or configure at the source — get the metrics flowing (each type page shows the Collector receiver that produces them) and recognition follows. Once a service is recognised, Sluicio offers to apply the type’s starter checks. Applying them creates ordinary alert rules on that service — the type is a template, not a policy engine, so nothing is locked: every threshold, severity and duration is yours to change afterwards, per service, in the service’s alert rules.

Built-in types themselves are read-only. To adapt one for your organisation — different thresholds, extra checks, fewer checks — create your own type reusing the built-in’s key: your version overrides the built-in everywhere the key is referenced, and removing it brings the built-in back.

Sharing types

A system type is a portable YAML file (format sluicio/system-type/v1). Export any type from the UI, import it on another cell, commit it to git alongside the rest of your configuration — it’s a plain file. There’s also a public community collection at github.com/SLUICIO/sluicio-system-types (Apache-2.0): types for systems beyond the built-ins, maintained in the open. If you’ve written a type for something others run, PRs are welcome.

Tuning happens on the service, not the type

The starter thresholds are sane defaults, not promises — a backlog of 5,000 messages is an incident on one queue and a Tuesday on another. After applying a type, tune each check on the service it was applied to, in that service’s alert rules. The type page’s tuning notes tell you which thresholds most often need adjusting.