Throughout my years working with Unix flavoured environments, one of the headaches I’ve had to deal with is cron. Don’t get me wrong, I love cron, it’s a necessity for any operation of such servers, however, there usually comes a point when the size of list reaches a critical mass that makes visualising the execution times a challenge.
Awareness of how many scheduled process becomes even more blurred when orchestration tools distance ourselves from the actual contents of crontab and it’s overall distribution of scheduled jobs. Such configurations bury the detail behind layers of abstraction, and the likes of Ansible, while being excellent at their ease of applying uniformity (and hiding detail), can also introduce an element of ignorance of what is actually happening at the server.
Most often such expansive schedules are of little concern, the servers can cope…. Until, they don’t; when large CPU blips of conflicting processes become apparent, and various jobs become stuck or delayed.
I had a recent example of this; of a back-end server that has a fairly complex set of schedules which started to exhibit a consistently obvious slow down at a specific time after the introduction of a new scheduled process. It was the proverbial last straw that broke the camel’s back.
I could have backed out of course, but this time I wanted to actually review the schedule on that machine to see if performance could be optimised. This led me to crontab and the task to understand the frequency of runtime. I needed some way to quickly display a calendar of when these tasks will fire over the next week, and from there, spread the load out.
In the past I’ve looked for such tools, and all of them tend to revolve around having some kind of framework that manages the calendar, and then feeds them into crontab. I didn’t want that excessive front-end, I needed to take what I already have and work backwards. Again, unfortunately, I couldn’t find a tool to do that which is surprising considering it should be easy enough.
That still needed to be done, and I therefore had to write my own. Which I did, and its on our github account (https://github.com/ioncube/cronview). Sure, it’s not pretty, I admit that, I had a need and in time, if I find I have the need again I will invest more effort in making it fit whatever need that may be; and it’s not in any of these new jazzy languages either. It’s in perl. Mainly because it’s one of my system scripting languages that I like (due to platform availability), but also because I used a fantastic module from the equally fantastic CPAN which does all of the heavy lifting for me.
The resulting visualisations did help in the end to resolve the CPU blip and now the myriad of processes are spread out in a more efficient way and the machine is much happier, and so am I!
