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 twelve 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

Most types describe message brokers and gateways - infrastructure that can’t instrument itself. Two (otel-collector, dotnet-service) are service types: they recognise a workload you run, not a system you scrape. One (paperless-ngx) describes an application whose pipeline is the thing worth watching, not its uptime.

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.