Comparison of logging modules with custom data

Last updated on
2 March 2026

This documentation needs review. See "Help improve this page" in the sidebar.

There are many modules that provide different logging solutions for Drupal (they are listed at the end), but actually only two of them allow storing custom values together with the message: Logger and Monolog - let's compare them:

Feature Logger Monolog Core, Others
Store custom data in the log entry
Write logs with custom data to the Drupal SQL database
Web UI to configure in the Drupal Admin Panel Different
Log entry format JSON Any Various
Custom log Handlers ✅ (Drupal Plugins) ✅ (Symfony Services)
Custom log Formatters ✅ (Symfony Services)
Custom log Processors ✅ (Drupal Events) ✅ (Symfony Services)
Popularity and maturity Low High -
Log entry creation performance High Low -
Module size Small (53 files) Big (74+137 files) -

Crucial features comparison

For Drupal site builders

Actually, for Drupal site builders, crucial features are:

  • Viewing logs directly in the Drupal Admin Panel.
  • Configuration UI that allows configure in the Drupal Admin Panel without touching the code.

All other advanced features like custom formatters and processors are usually not needed.

For production, the crucial feature is performance: just log the entry as quick as possible, as simple as possible.

In this view angle, the Logger is the winner, it provides Drupal Admin Panel UI to configure, and executes the minimal amount of PHP code to store the log entry.

Formatters - the Monolog's "killer feature"

Monolog provides extensive possibilities to format log entries before sending them to logs: you can re-map, modify values, filter by values, etc.  Logger - deliberately did not implement this.

Why does Logger miss this? The modern approach is do not modify the logs on the app level but use special tools to scrape and format the logs after the application: Promtail, OpenTelemetry Collector, Fluentd, Fluent Bit, Logstash, Filebeat, Syslog-ng, Rsyslog, etc.

This is because logs from different applications usually come in different formats, and you will still be forced to format them on the scraper level to store them in the same format. And usually, this responsibility is on DevOps, not on the website developers.

Therefore, it's easier to manage all formatting rules in one place than hardcode and manage some formatters on the Drupal side. Because of this, the main "killer" feature of the Monolog nowadays is not needed in most cases.

Custom log Handlers and Processors

Both modules provide the ability to handle and process the log entries. But the Logger module provides this using the approach more friendly for Drupal developers: Drupal Plugins with UI in the admin panel for the handlers, and Symfony Events for processing.

Monolog provides this using the Symfony way: YAML-based configuration of services.

Conclusion

In conclusion, Monolog is a great, popular, and very flexible log management solution. But for Drupal Websites, usually it is too much, it is like cracking a nut with a sledgehammer. The only case when it is a good choice is when you really need to format logs on the Drupal side, which is a rare case nowadays.

Therefore, Logger is a more lightweight and convenient solution for most cases, when you do all the log formatting processing on the log scraper side, or do not need any custom formatting at all.

Analyzed custom logging modules:

Help improve this page

Page status: Needs review

You can: