Fork me on GitHub
#architecture
<
2022-03-01
>
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?

lukasz18:03:19

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

hiredman18:03:29

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 (https://github.com/logicblocks/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