This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-01
Channels
- # announcements (2)
- # architecture (8)
- # babashka (21)
- # beginners (75)
- # calva (3)
- # clj-kondo (6)
- # cljdoc (6)
- # cljs-dev (10)
- # clojars (4)
- # clojure (94)
- # clojure-europe (12)
- # clojure-nl (4)
- # clojure-norway (3)
- # clojure-spec (6)
- # clojure-uk (4)
- # clojurescript (51)
- # community-development (13)
- # core-async (3)
- # css (1)
- # cursive (8)
- # datomic (7)
- # girouette (3)
- # graphql (3)
- # improve-getting-started (4)
- # integrant (2)
- # interop (5)
- # jobs (12)
- # kaocha (1)
- # lsp (24)
- # malli (4)
- # membrane (13)
- # nextjournal (9)
- # off-topic (6)
- # re-frame (9)
- # reitit (2)
- # remote-jobs (1)
- # reveal (4)
- # ring (4)
- # scittle (3)
- # shadow-cljs (4)
- # spacemacs (1)
- # testing (2)
- # vrac (1)
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
I like the health reporting info to be reported via tap
. Then the code can run with or without a health-check component.
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
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
Using something such as https://cljdoc.org/d/metrics-clojure-health/metrics-clojure-health/2.10.0/api/metrics.health.core
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 HealthCheckable
s and wires up the check functions into the registry.
