Introducing the Selective Watchdog Backend module
Introducing the Selective Watchdog Backend module
Language
English
Introducing the Selective Watchdog Backend module
Keep a good performance while storing logs on your Drupal database.
Fri, 2016-09-09 15:20By salva
In the world of Drupal, it's a common and best practice to disable the Dblog module (Database logging) on production sites, in favour of using the Syslog module, which will take care of logging all php errors, notices, or any custom log messages into the Unix system logs, removing the performance burden of writing them to the Drupal database.
There are scenarios in which this approach, while convenient to keep the site running smoothly, is rather problematic when troubleshooting issues that appear only in a given environment and under very specific conditions. For those, unless you can count with some custom logging system built for very specific aspects of a site, you are pretty much blind and unable to find the source of a bug.
We've recently had this problem in one of our sites, where several external systems were involved in the feature that we were trying to debug. Given that those systems couldn't be reached from a development environment, we needed a minimum amount of information to be kept on the Drupal database, so that it was easier to navigate and see the details than it is to sail through the syslog. For that, Pascal Morin wrote a new module called Selective Watchdog Backend (selectlog).
So what's it?
The concept behind the Selective Watchdog Backend is quite simple: instead of sending all logs to the syslog, give developers some flexibility to choose what can be also sent to the Drupal database. That way, you ensure that everything is sent to the syslog as usual, but for very specific sections of your site, you still have a meaningful set of logs of what you might consider more important at any given point. The great thing of the module, is that it doesn't affect any other watchdog modules you may be using. It's just an addition on top of them.
Let's see a couple examples, of what could be common use cases:
Scenario 1: You have a complex integration with a 3rd party API, and all the site users make constant use of it. However, it's not very stable, and you need to assist your client by providing them with exact details of the points at which the API is failing to return the expected results. Of course you've already added watchdog entries for these cases when you wrote the module, because you're a smart developer, but now you need these entries to be surfaced on the Drupal site. With the selectlog module enabled, all you'd have to would be editing your settings.php file and add these lines:
$conf['selectlog'] = array( 'dblog' => array(
'your_api_integration_module' => '*',
);
That would log every watchdog entry of your custom module to the database, making it available under admin/reports/dblog.
Scenario 2: Some of your views are breaking on production and you don't manage to find the problem (this is less likely to happen, but it'll do for the sake of the explaining the module usage). To troubleshoot this, you want to store the watchdog entries from the views module in the database, but just those of a certain severity. To do so:
$conf['selectlog'] = array( 'dblog' => array(
'views' => array(
WATCHDOG_CRITICAL,
WATCHDOG_ERROR,
),
);
And that's it. Pretty neat and convenient. Hopefully we'll be promoting this sandbox to a full project soon. In the meantime, take our word that it works wonderfully. If you think it's going to be an useful feature on your site, I recommend checking out the details on the project page or the comprehensive README.md file included with the module. Enjoy your logs!
BlogViewport module ready for Drupal 8
BlogSpinning up a CentOS server for Drupal
FAQHow do I find Drupal messages with the syslog module enabled?