The art of crontab jobs monitoring, part II

In part I of the discussion I've outlined some basic principals of crontab jobs monitoring. One of the biggest disadvantage of the described approach is the lack of centralized control panel (console) which can be used to see the current status of all configured periodic jobs.

The following is a description of a more advanced crontab jobs monitoring system which will provide a status of:

• successfully and timely executed jobs
• failed jobs
• delayed or missed jobs

The art of application logging

There are three frequently met problems with logging functionality in in-house software:

• Application developers don't really care about proper application logging
• Development managers cannot really define coding standards for application logging, or in the worst case - they just don't care about logging at all
• Operations guys cannot troubleshoot in-house software without simple and human-readable logs

The goal of the post is to formulate in a single document all critical points about application logging as it is seen from the Operations point of view.

The art of crontab jobs monitoring

In a regular production or development environment there are normally a lot of crontab jobs configured on running servers. The jobs can be a part of deployed applications or can perform different system administration tasks like backups, reporting, etc. This post will describe several key points which should be considered while configuring crontab jobs in a large environment.

Automatic deployment of crontab configuration
Linux distributions provide a convenient way to automatically deploy new crontab jobs while installing a new software package or using centralized configuration management systems like Puppet or Chef. You simply drop a properly formatted crontab configuration file in directory /etc/cron.d/, and the running crontab scheduler process will automatically read the new file and configure jobs specified in it.