[linux-elitists] A better cron: large production environments

Karsten M. Self karsten at linuxmafia.com
Fri May 7 17:09:22 PDT 2010


I'm kicking ideas around for a better cron system (or framework for the
existing system) which might help address some of the shortcomings of
cron as are being experienced now, particularly in notification and
messaging.

General environment is a largish production server installation.  We
happen to be in the web space, but any large multi-host infrastructure
with copious old, poorly-understood, and fragile cron jobs might
benefit.


General goals:

  - Reduce chatter.  Excessive messages, whether null, extraordinarily
    long, just plain confusing, or that don't need to exist at all.

  - Simplify and standardize cron job mail output to allow for more
    efficient mail filtering, assessment, evaluation, parsing, etc.

  - Instrumentability for existing monitoring systems.  The ability to
    plug in alerts for Nagios or other monitoring tools for failed jobs,
    etc., would be useful.

  - Other than informational cron messages (e.g.:  "this is the state of
    your system today), keeping status, warning, and error messages
    *out* of mail (other than a very brief synopsis), instead logging
    this through other facilities (e.g.: syslog, application or
    job-level logging, particularly enabling log rotation through toosl
    such as logrotate).

  - Variable levels of email notification:  standard operational
    messages to Those Who Should Know, status or informational messages
    to target client users (or email addresses), problem alerts to
    staff/management who should know, etc.  Send mail to those who
    should receive it, not to those who shouldn't.  Don't clobber legacy
    (<coff>Exchange</coff>) mail systems with absurdly low per-user
    mailbox size restrictions.

  - Concise job execution status:
    - OK
    - Failed to start
    - Failed to complete
    - Output/context based error, warning, or info level
    - Other ... ??

      (I'm basing some of this on a QA framework tool I used a few years
      back based mostly on some pretty simple POSIX / shell tool
      conventions, I think originally devleped at CMU, though I'm
      pulling a complete blank at the moment).

  - Logging of job output (stdout, stderr, possibly other), preferably
    via syslog (e.g.: logger(1)), to separate notification frm debug.

  - Tailoring of output verbosity (for both logging and emails).

  - Web / Intranet access to job log(s) for info, ouput, error,
    debugging, etc, preferably with a URL posted to mail for further
    information.

None of this is rocket science, all of it's pretty trivial stuff, I'm
mostly curious as to whether or not there's something that exists which
fits this bill, and/or if there's interest in seeing a general tool
built.



Peace.

-- 
Karsten M. Self <karsten at linuxmafia.com>        http://linuxmafia.com/~karsten
 What part of "gestalt" don't you understand?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://zgp.org/pipermail/linux-elitists/attachments/20100507/b1fb6d08/attachment.pgp>


More information about the linux-elitists mailing list