PCI/DSS has a requirement indicating that an application's log should be reviewed AT LEAST daily for security events. Most network/infrastructure professionals can review network device logs but won't be familiar with actual applications. The same can be said for most security professionals.
So, are developers really stepping up to this requirement? If you had to write a job description for a developer whose sole job was to review logs, what would it contain?
I personally don't see developers stepping up to meet this requirement. Most developers are concerned with development work...not something that an expert on the application would deal with.
If I HAD to write a job description for a developer whose sole job was reviewing logs, it would contain something about studying the application architecture and becoming an expert in both the use and implementation of the software.
In my company, we have the requirement that an application needs to run so-and-so-long without giving serious trouble in order to get a release from QA.
Think of it as a post release beta phase.
So as long as we are in this the app is life; but not yet released by QA phase, I am reviewing the logs at least once per day. (Of course we have other ways to get notified on errors, but I learned a lot about my own bad assumptions on how the users would operate the software that way).
Security/severe events should probably be logged separately so that they are noticed quicker. Possibly send them with email or use some other technique so that the appropriate people are automatically notified. No one should have to review application logs to look for security events. As a developer I periodically review production errors. I am working to get support to have access to the errors and I will teach them how to interpret the most common errors but I will still handle the less common errors. Also when I review the prod errors I evaluate the messages of the most common errors to improve them.
So I think development should periodically review prod errors, make sure that important (i.e. security) logs are automatically sent to the appropriate people, and transmission handling of the most common errors to other groups (support infrastructure, security, etc). If someone's sole responsibility was to review logs I wouldn't call them a developer.
I would see this as a system administration task as opposed to one undertaken by a developer. Any issues from the logs would be flagged in an issue tracking system and then distributed to the development team by the development lead/product manager should changes to the codebase be required to resolve the defect/error.
I look at logs when I want to diagnose something that I already know has gone wrong (or might have gone wrong).
For other problems, I expect to be notified.
To me "a developer whose sole job was to review logs" is an oxymoron: if you're just reviewing logs, you're not developing, therefore you're not a developer.