This page permanently redirects to gemini://shit.cx/tech/meta/2020-12-15-another-go-at-the-monitoring-tool/.

shit.cx

Another Go at the Monitoring Tool

2020-12-15T19:12

I have good ideas and bad ideas and for each I may execute them well, or not. Usually, my early executions fall in the latter category.

The execution of the monitoring service is no exception. It was poorly executed. The jury is still out on whether it's a good idea, but that's a post for another day. Technically the monitor works but it was too complex. To fulfil the goal of spreading the monitoring burden across many hosts, it must be simple to set up and have few dependencies. This was not the case and was rightly pointed out by a few people.

So yesterday I took another go. The differences in this solution are:

• It expects to be scheduled by cron, rather than a persistent daemon running in a sleepy loop.
• Its input is provided as arguments rather than reading them from a json config file.
• State is stored in flat files rather than Redis.
• Sending email is out of scope; you're expected to pipe the output to a mailer.
• The status code is fetched using openssl instead of gmni.

These changes have removed all the weird dependencies — no more redis, jq or gmni. There is is half as much code and all boilerplate like systemd services or config files is gone.

=> You can get the code here. It's currently on the cronify branch, but it will be merged to master soon.

It isn't tested on the BSDs nor with ksh. If you feel strongly enough to fix it I will happily accept patches.

=> More Posts Like This | Return to Homepage

The content for this site is CC-BY-SA-4.0.