Fork me on GitHub
Ben Sless18:03:25

On health checks, registries and components: Assuming I'm using something like Component, and build a service which exposes its health status via a registry, what should be the correct order of dependencies? If each component which exposes a health check registers itself on start up, I might find plenty of components get passed the registry. Is it normal, or does it point towards me doing something wrong? How would you design it?


I'm toying around with exactly this problem - so I inverted it, parts of the system depend on a metrics collector component, as well as the http handler for health check - but the health check handler only reads the collected metrics data rather than submit it. So health-check is not a component per-se, but an aspect of the system - if that makes sense

John Conti17:05:06

I like the health reporting info to be reported via tap. Then the code can run with or without a health-check component.

Ben Sless18:05:19

Or any sort of general purpose bus in in the program all components can report to. Interesting


I've only ever had the "service" itself have a health check, not the components that make up the service

Ben Sless18:03:20

Different parts of it can define their health criteria differently. So they each need to register a check that runs periodically, and if it fails, changes the status of the entire service

Toby Clemson21:03:45

I built salutem ( to help with managing health checks like these. It’s not directly integrated to component but the way we use it alongside component is to have each health checkable component implement a HealthCheckable protocol which exposes a check function. Then a Health component is injected with all HealthCheckables and wires up the check functions into the registry.

clojure-spin 3