runlog

Managable detaied per-run logs for recurring jobs.


License
MIT
Install
pip install runlog==0.1.1

Documentation

Runlog

Managable detaied per-run logs for recurring jobs.

"Why did X happen the last time the Foo job ran for user Bar?"

"Job Y blew up when it ran yesterday. Where and why did it fail?"

Runlog provides a Python standard library logging-based, Redis-backed way to store and access logs for the last N interesting runs of a job. It's very simple to add detailed logging to code that runs inside your recurring jobs without cluttering up your normal log files with noisy, interleaving output.

It is very easy to add this logging to your code. An unambitious, CLI allows you to list jobs, list previous and ongoing runs and to output their logs. (Pipe them to your favorite unix utilities and enjoy.)

Logging a Job

Job logging is done with normal log calls and a job-logging context manager.

import logging
from runlog import RunLogger

rl = RunLogger(redis_config={'host': 'localhost'},
               max_logs=10)

rl.debug("You will never see this.")

with rl.runlog('recurring-job-32') as logger:
    logger.setLevel(logging.DEBUG)
    rl.debug("You will see this in the log of a run of this job.")

rl.error("You don't see this either.")

Caveat: you will actually see all log messages if you add handlers to the root logger. But if that is the case you are drinking from the firehose and it's probably what you want to happen anyway.

Finding The Output

Assuming you have a .runlog.conf that looks like this

[runlog]
max-logs: 10

[runlog-redis]
host: localhost

... you can find the logs for your job like this:

$ runlog list-jobs
recurring-job-32

$ runlog list-runs recurring-job-32
recurring-job-32 2014-04-16-04:35:23.562999
recurring-job-32 2014-04-15-04:33:11.463847
...

$ runlog logs recurring-job-32 2014-04-15-04:33:11.463847 2014-04-16-04:35:23.562999 
[ ... LOGS OF THE TWO RUNS SPECIFIED ... ]

Coming soon: range queries over log messages.

Handling Errors

If something blows up inside the job-loggging context manager, the traceback will be added to the log for the current run and the exception will be re-raise. Errors will not be swallowed.

Throwing Away Boring Logs

If your job turns out of be a no-op or is in some other way boring to you, you can raise a CancelLog and just forget the whole thing.

with rl.runlog('job-127') as logger:
     things_processed = run_job(127)
     if things_processed == []:
         raise CancelLog()  # This run is forgotten.

CancelLog will be swallowed, but only inside the context manager.

Managing Data

Set up a dedicated Redis instance. Cap the memory. Throw away logs that are not interesting. Look at data growth and adjust max_logs or be more picky about which jobs you log. Archive really interesting things and/or some random samples into some kind of cold storage.