App exceptions should be logged to aid support investigations

[osg74]

Currently if an exception occurs on the live RSR server this isn't logged in the RSR log file, which makes investigating failures and configuration problems more difficult. Any unhandled exceptions should be logged, even when RSR isn't running in debug mode.

[adriancollier]

@osgl do you know what's required for this one? Is this something @carlio would need to do, or something more general to Django?

[osg74]

This is error handling and reporting that RSR developers would need to add to the codebase so that we have something to work with from an Ops perspective when something falls over. Currently we only seem to have the raw HTTP traffic logged in our nginx logs but nothing in the RSR web app log itself (other than some very minor debug info that seems to be obsolete anyway).

For example, wherever we've previously had warnings of a 'server error' during RSR execution (and we've subsequently seen a traceback when debug mode is enabled), this indicates an unhandled exception. Developers should either be coding to fix such errors or provide sufficient log file commentary so that we can diagnose and resolve any configuration or operational issues quickly enough.

[osg74]

Here's a good article about coding useful exception handling and esp. how to write meaningful exception messages to quickly diagnose and resolve support issues: http://programmers.stackexchange.com/questions/29433/how-to-write-a-good-exception-message

The point is really that 5 min of coding time to write decent error handling will save 2 hours of wasted ops time trying to find out why something is broken.

[zzgvh]

Bah, missed a #. Here's the other commit related to this: 5ec2276

[adriancollier]

@zzgvh If this is done - can we create a pull request for checking?

[KasperBrandt]

Merged in #536

[KasperBrandt]

Test plan

GIVEN RSR
WHEN an error occurs
THEN the stack trace should be logged in /var/akvo/rsr/logs/akvo.error.log.