Sluicio v0.11.55

Includes a database migration (0077_alert_rule_system). It adds one nullable column and an index to alert_rules and runs automatically on start. No backfill, no rewrite of existing rows.

Health checks can now govern a system

A check could define the healthy state of a service or an integration. A system — a peer of both everywhere else in Sluicio — was the only one left out, and it is the one that matters most for infrastructure: "the Kafka cluster is healthy iff consumer lag < X" describes the cluster, not any one broker, and there was no way to say it.

Systems now take the same three check kinds everything else does — metric, log, and failed-trace / response-time / low-traffic:

• System → Health checks — the same card service and integration pages have. Add, edit and remove checks where they belong.
• Metrics explorer — the health-check target chooser gains A system alongside a service and an integration.

A firing system-bound check makes the system unhealthy on its own. Previously a system could only inherit health from its members, so "the cluster is unhealthy" depended on some individual broker also looking unhealthy — exactly the coupling a cluster-level check exists to avoid. Member rollup is unchanged and still applies.

The live "would fire" preview is scoped to the system's member services, so what you see while writing the check is what the saved check evaluates. A system with no members yet reads as no data rather than silently widening to every service in the cell, and previewing a system you have no access to returns nothing rather than aggregating services you cannot see.

Low-traffic checks got more accurate in the process. They could not previously tell "this scope produced no traffic" from "this scope contains nothing" — both counted as zero, and both fired. A system or integration with no member services would raise a traffic alert about an empty set. That case is now skipped. A named service with no traffic still fires: that is the dead-man's switch, and it is a different statement.

Choose a system's type instead of typing its key

Creating a system asked, in a browser prompt, for its type key — "e.g. rabbitmq, kafka, postgresql" — from memory. The key was stored exactly as typed and never checked against the catalog, so RabbitMQ, rabbit, or a stray trailing space all saved happily and then matched no type at all. The system quietly received no starter checks, no monitoring template and no documentation link, with nothing on screen to explain why.

The type is now picked from the real catalog, shown as RabbitMQ (rabbitmq) so the key is visible without having to be remembered, and searchable. The same picker replaces the free-text box when editing a system. A system whose stored key matches nothing — which existing ones may — now says so instead of presenting itself as a valid choice.

If your system is not in the catalog, you can add it without leaving the form. Give it a name and the key is derived for you (IBM MQ → ibm-mq), shown before saving. Detection prefixes and starter checks stay on the System types page, which the picker links to.

Creating a system is now a form rather than a chain of browser prompts: the name and type are visible together, it can be cancelled, and errors appear in the form instead of disappearing with the dialog.