Sluicio v0.11.54

Health checks can now govern an integration

A health check could be bound to a service or left org-wide. There was no way to say "this metric defines whether this integration is healthy" — even though the alert engine has been able to evaluate exactly that for some time. Every evaluator already honoured an integration scope; the only thing that ever restricted checks to services was the UI never offering the choice.

Two places now offer it:

• Metrics explorer — the health-check binding asks what the check governs: nothing, a service, or an integration. Picking an integration evaluates the check across that integration's member services.
• Integration → Settings — a Health checks card, the same one service pages have. Add, edit and remove metric, log and failed-trace checks where they belong, instead of creating them elsewhere and hoping they land in the right place. The Alert rules card below it now covers what it uniquely offers — which channels each rule notifies, and whether it is enabled.

The live "would fire" preview follows the same scope. Bind a check to an integration and the preview is computed over that integration's services, so the rehearsal matches the performance. Previously a preview of an integration-bound rule would have aggregated every visible service — a number the saved rule would never produce.

Two things it deliberately will not do: an integration whose service membership has not been reconciled yet reads as no data rather than silently widening to every service, and previewing an integration you have no access to returns nothing rather than aggregating services you cannot see.

Note for one-runtime-many-integrations setups (Node-RED, Camel, a shared iPaaS worker): an integration-bound check evaluates over the integration's member services. Where several integrations share one service, the check therefore covers all of them, not the one flow. The picker says so where you choose.

Dimensionless metrics no longer print a stray "1"

UCUM, which OpenTelemetry metric units follow, spells "dimensionless" as the unit 1. Sluicio rendered it literally, so a dimensionless metric read "CURRENT 99 1", "gauge · latest · 1", and "Current 99 > threshold 50 1" — a trailing digit that looks like a typo or a second number and tells you nothing either way. It is now omitted wherever a unit is shown.

Units that merely contain a 1 — m/s2, 10*3/min — are unaffected, as are annotation-form counts like {messages}, which do tell you what is being counted.

The split-by health-check preview counted the wrong thing

Breaking a check down by an attribute previewed as "Would fire for 1 http.url (of 1)", attaching the count to the attribute's name rather than to its values — and pluralising a key that is not a countable noun, so two breaching URLs read as "2 http.urls". It now reads "Would fire for 1 of 1 http.url value".