3 ms·

Semi-related but it's shame default cron in most (all?) kinda fucking sucks at everything. There is no builtin spreading so */5 job on 500 nodes will get you n

by ilyt 3y ago

Semi-related but it's shame default cron in most (all?) kinda fucking sucks at everything. There is no builtin spreading so */5 job on 500 nodes will get you nasty spike in CPU load. Logging options are pretty much "parse emails and hope for best" and some syslog spam that's mostly noise if everything is working fine. And fucked up environment vars that trip many script-makers. No metrics whatsoever

spmurrayzzz 3y ago
Oh definitely. This actually bit me a few years ago. Had a distributed set of embedded systems (tens of thousands of wifi routers) that were phoning home which I didn't realize was being done through a cron. It was something we inherited with the BSP. Looking at our analytics for the relevant API zoomed out to 1-5 minute resolutions, our RTTs looked like they were monotonically increasing over time. We had to hookup real time analytics to one of the nodes in our production cluster to be able to catch the spikes at the exact second of the relevant minute boundary. The solution in our case was to build a tiny launcher for anything cron-related that delayed the script executions randomly within a range of milliseconds.