{"id":77068,"date":"2025-12-19T10:25:18","date_gmt":"2025-12-19T04:55:18","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=77068"},"modified":"2026-01-06T15:50:12","modified_gmt":"2026-01-06T10:20:12","slug":"extending-and-improving-drupals-logging-system-with-monolog","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/extending-and-improving-drupals-logging-system-with-monolog\/","title":{"rendered":"Extending and Improving Drupal\u2019s Logging System with Monolog"},"content":{"rendered":"

Effective logging sits at the heart of building and operating dependable web applications. It gives engineering teams the visibility they need to understand runtime behavior, investigate errors, maintain audit trails, and act decisively when issues arise in live environments. Drupal ships with two native logging options: Database Logging (dblog)<\/strong> and Syslog<\/strong>. In the dblog approach, messages are written directly into database tables, whereas Syslog redirects those messages to the underlying operating system\u2019s logging facility, avoiding database persistence altogether.<\/p>\n

Although dblog is convenient during development and performs adequately on smaller or low-usage sites, its reliance on constant database writes can create performance strain as traffic and complexity increase. Syslog<\/strong> mitigates this concern by shifting logging responsibilities to the system level, making it a more practical choice for cloud-hosted or server-based deployments where centralized log access and quicker diagnostics are essential.<\/p>\n

For Drupal applications operating at scale, especially in high-traffic or enterprise environments, Monolog<\/strong> stands out as the preferred logging solution. It introduces a highly configurable and extensible logging layer that supports multiple channels, handlers, and output formats. Monolog<\/strong> enables logs to be streamed to files, external services, or modern observability platforms, while also supporting structured formats like JSON, severity-based filtering, and environment-specific setups. This approach not only reduces runtime overhead but also delivers deeper operational insight and long-term scalability for production systems.<\/p>\n

Difference Between dblog, Syslog, and Monolog in Drupal<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\u00a0Feature \/ Aspect<\/strong><\/td>\n\u00a0dblog (Database Logging)<\/strong><\/td>\n\u00a0Syslog<\/strong><\/td>\n\u00a0Monolog<\/strong><\/td>\n<\/tr>\n
\u00a0Type<\/strong><\/td>\n\u00a0Core Module<\/td>\n\u00a0Core Module<\/td>\n\u00a0Contributed Module<\/td>\n<\/tr>\n
\u00a0Storage Location<\/strong><\/td>\n\u00a0Database tables (watchdog)<\/td>\n\u00a0System log (Linux syslog)<\/td>\n\u00a0Files, stdout, syslog, cloud services<\/td>\n<\/tr>\n
\u00a0Installation
\n<\/strong><\/td>\n		\u00a0Enabled by default<\/td>\n\u00a0Enable manually<\/td>\n\u00a0Install via Composer<\/td>\n<\/tr>\n
\u00a0Performance<\/strong><\/td>\n\u00a0Slower (DB writes)<\/td>\n\u00a0Better than dblog<\/td>\n\u00a0High performance<\/td>\n<\/tr>\n
\u00a0Database Load<\/strong><\/td>\n\u00a0High<\/td>\n\u00a0None<\/td>\n\u00a0None<\/td>\n<\/tr>\n
\u00a0Log Rotation<\/strong><\/td>\n\u00a0No<\/td>\n\u00a0OS-level<\/td>\n\u00a0Built-in (RotatingFileHandler)<\/td>\n<\/tr>\n
\u00a0Scalability<\/strong><\/td>\n\u00a0Poor for large sites<\/td>\n\u00a0Limited<\/td>\n\u00a0Excellent<\/td>\n<\/tr>\n
\u00a0Log Levels<\/strong><\/td>\n\u00a0Basic (Notice, Warning, Error)<\/td>\n\u00a0Basic<\/td>\n\u00a0Full (DEBUG, INFO, WARNING, ERROR, CRITICAL)<\/td>\n<\/tr>\n
\u00a0Multiple Outputs<\/strong><\/td>\n\u00a0Not allowed<\/td>\n\u00a0Not allowed<\/td>\n\u00a0Yes (file + stdout + cloud)<\/td>\n<\/tr>\n
\u00a0Container Support<\/strong><\/td>\n\u00a0Not suitable<\/td>\n\u00a0Limited<\/td>\n\u00a0Perfect for Docker\/K8s<\/td>\n<\/tr>\n
\u00a0Centralized Logging<\/strong><\/td>\n\u00a0Not supported<\/td>\n\u00a0OS-dependent<\/td>\n\u00a0ELK, Graylog, New Relic<\/td>\n<\/tr>\n
\u00a0Alerting (Slack\/Email)<\/strong><\/td>\n\u00a0Not allowed<\/td>\n\u00a0Not allowed<\/td>\n\u00a0Yes allowed<\/td>\n<\/tr>\n
\u00a0Ease of Debugging<\/strong><\/td>\n\u00a0Basic UI<\/td>\n\u00a0OS access needed<\/td>\n\u00a0Advanced & flexible<\/td>\n<\/tr>\n
\u00a0Best Use Case<\/strong><\/td>\n\u00a0Small \/ local sites<\/td>\n\u00a0Traditional Linux servers<\/td>\n\u00a0Modern, cloud, enterprise apps<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

What is Monolog?<\/h2>\n

Monolog<\/strong> is a popular and powerful PHP logging library used by many frameworks, including Symfony (which Drupal is built on). It provides advanced logging capabilities and supports multiple output destinations, known as handlers<\/strong>.<\/p>\n

With Monolog, logs can be sent to:<\/p>\n

    \n
  • Files (with rotation)<\/li>\n
  • Stdout \/ stderr (ideal for Docker & Lando)<\/li>\n
  • Syslog<\/li>\n
  • Cloud logging services<\/li>\n
  • Centralized systems like:\n
      \n
    • Graylog<\/li>\n
    • Logstash \/ ELK Stack<\/li>\n
    • Papertrail<\/li>\n
    • New Relic<\/li>\n<\/ul>\n<\/li>\n
    • Notifications (Slack, Email, Webhooks)<\/li>\n<\/ul>\n

      Drupal integrates Monolog through the contributed Monolog module<\/strong>, allowing you to completely extend and replace the default logging system.<\/p>\n

      Why Use Monolog in Drupal?<\/h2>\n

      Using Monolog in Drupal provides several benefits:<\/p>\n

        \n
      • Better performance<\/strong> than database logging<\/li>\n
      • Centralized log management<\/strong> for distributed systems<\/li>\n
      • Multiple handlers<\/strong> (log to file + terminal + external service)<\/li>\n
      • Log rotation<\/strong> to prevent disk overuse<\/li>\n
      • Severity\u2011based logging<\/strong> (DEBUG, INFO, WARNING, ERROR, CRITICAL)<\/li>\n
      • Perfect for Docker \/ Lando \/ Kubernetes environments<\/strong><\/li>\n<\/ul>\n

        In production environments, logging to stdout or external services is considered a best practice.<\/p>\n

        Installing Monolog in Drupal<\/h2>\n

        Step 1: Install via Composer<\/h3>\n
        composer require drupal\/monolog<\/strong><\/pre>\n
        Step 2: Enable the Module<\/h3>\n
        drush en monolog -y<\/strong><\/pre>\n
        Step 3: Disable Database Logging (Optional but Recommended)<\/h3>\n
        drush pmu dblog -y<\/strong><\/pre>\n
        This step is optional, but highly recommended for production to reduce database overhead.<\/p>\n
        Basic Monolog Configuration in Drupal<\/h2>\n
        Drupal allows you to define Monolog handlers using Symfony service definitions.<\/p>\n
        Step 4: Create a Site\u2011Specific Service File<\/h3>\n
        Create a file named:<\/p>\n
        sites\/default\/monolog.services.yml<\/strong><\/pre>\n
        This file will define where and how logs are written.<\/p>\n
        Example 1: Output Logs to Terminal (Stdout)<\/h3>\n
        This setup is ideal for Docker, Lando, and Kubernetes<\/strong>, where logs are collected from stdout.<\/p>\n
        parameters:\r\n monolog.channel_handlers:\r\n  default: ['stdout']\r\n\r\nservices:\r\n monolog.handler.stdout:\r\n  class: Monolog\\Handler\\StreamHandler\r\n  arguments: ['php:\/\/stdout', 'DEBUG']\r\n  tags:\r\n   - { name: monolog.handler, channel: default }\r\n<\/strong><\/pre>\n
        Example 2: Output Logs to a Rotating File<\/h3>\n
        Logs will be stored in:
        \npublic:\/\/logs\/debug.log<\/strong>
        \n\u2192 sites\/default\/files\/logs\/debug.log<\/strong><\/p>\n
        parameters:\r\n monolog.channel_handlers:\r\n  default: ['rotating_file']\r\n\r\nservices:\r\n monolog.handler.rotating_file:\r\n  class: Monolog\\Handler\\RotatingFileHandler\r\n  arguments: ['public:\/\/logs\/debug.log', 10, 'DEBUG']\r\n  tags:\r\n   - { name: monolog.handler, channel: default }\r\n<\/strong><\/pre>\n
        Explanation:<\/strong><\/p>\n
          \n
        • 10<\/strong> \u2192 Keeps the last 10 rotated log files<\/li>\n
        • DEBUG<\/strong> \u2192 Minimum log level<\/li>\n
        • Make sure the logs<\/strong> directory exists and is writable.<\/li>\n<\/ul>\n
          Example 3: Output Logs to Both Terminal and File<\/h3>\n
          parameters:\r\n monolog.channel_handlers:\r\n  default: ['stdout', 'rotating_file']\r\n\r\nservices:\r\n monolog.handler.stdout:\r\n class: Monolog\\Handler\\StreamHandler\r\n arguments: ['php:\/\/stdout', 'DEBUG']\r\n tags:\r\n  - { name: monolog.handler, channel: default }\r\n\r\n monolog.handler.rotating_file:\r\n class: Monolog\\Handler\\RotatingFileHandler\r\n arguments: ['public:\/\/logs\/debug.log', 10, 'DEBUG']\r\n tags:\r\n  - { name: monolog.handler, channel: default }\r\n<\/strong><\/pre>\n
          This is a very common setup for local and staging environments.<\/p>\n
          Writing Drupal Monolog Logs to S3 \/ Azure Blob<\/h3>\n
          Recommended Approach:\u00a0<\/strong>Monolog logs in Drupal can be stored in Amazon S3 or Azure Blob Storage, but they should not be written there directly from the application layer. Instead, follow this two-step, production-ready approach:<\/p>\n
            \n
          • Write logs locally or to STDOUT:<\/strong> Configure Monolog to log into local files or STDOUT. This keeps logging fast, reliable, and independent of network latency.<\/li>\n
          • Forward logs to S3 \/ Azure Blob asynchronously: <\/strong>Use infrastructure-level tools such as:\n
              \n
            • AWS CloudWatch \u2192 S3<\/li>\n
            • Azure Monitor \/ Log Analytics \u2192 Azure Blob<\/li>\n
            • Cron-based batch uploads or log shippers (Fluent Bit, Filebeat)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
              This approach ensures better performance, lower cost, and higher reliability<\/strong>, while still centralizing logs in S3 or Azure Blob for long-term storage and analysis.<\/p>\n
              Step 5: Tell Drupal to Load the Monolog Services File<\/h3>\n
              Add the following line to your settings.php<\/strong> file:<\/p>\n
              $settings['container_yamls'][] = 'sites\/default\/monolog.services.yml';<\/strong><\/pre>\n
              Clear caches after making this change:<\/p>\n
              drush cr<\/strong><\/pre>\n
              Step 6: Test Logging<\/h2>\n
              Use Drupal\u2019s logger service anywhere in custom code:<\/p>\n
              \\Drupal::logger('custom_channel')->debug('This is a debug message.');\r\n\\Drupal::logger('custom_channel')->error('This is an error message.');\r\n<\/strong><\/pre>\n
              You can also create different channels for different modules or features.<\/p>\n
              Viewing Logs in Containers<\/h2>\n
              Lando<\/strong><\/p>\n
              lando logs -f<\/strong><\/pre>\n
              Docker<\/strong><\/p>\n
              docker logs -f <container_name>\r\ndocker logs -f\r\n<\/strong><\/pre>\n
              This makes Monolog ideal for modern DevOps workflows.<\/p>\n
              Best Practices for Using Monolog in Drupal<\/h2>\n
                \n
              • Use stdout logging in containers<\/li>\n
              • Disable dblog in production<\/li>\n
              • Separate log levels (ERROR vs DEBUG)<\/li>\n
              • Rotate file logs to prevent disk issues<\/li>\n
              • Send critical logs to alerting systems (Slack, Email)<\/li>\n
              • Avoid excessive DEBUG logging in production<\/li>\n<\/ul>\n
                Conclusion<\/h2>\n
                By integrating Monolog<\/strong> into Drupal, you move from basic database logging to a scalable, high\u2011performance, and enterprise\u2011ready logging system<\/strong>. Whether you are running a small site, a headless Drupal backend, or a large\u2011scale cloud deployment, Monolog gives you the flexibility and control needed to make your logs meaningful and actionable.<\/p>\n
                Monolog is not just a logging replacement\u2014it is a foundation for better monitoring, debugging, and observability in modern Drupal applications.<\/p>\n","protected":false},"excerpt":{"rendered":"
                Effective logging sits at the heart of building and operating dependable web applications. It gives engineering teams the visibility they need to understand runtime behavior, investigate errors, maintain audit trails, and act decisively when issues arise in live environments. Drupal ships with two native logging options: Database Logging (dblog) and Syslog. In the dblog approach, […]<\/p>\n","protected":false},"author":1700,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":121},"categories":[3602],"tags":[8257],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77068"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1700"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=77068"}],"version-history":[{"count":14,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77068\/revisions"}],"predecessor-version":[{"id":77353,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77068\/revisions\/77353"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=77068"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=77068"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=77068"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}