Why Drupal logging with syslog matters for security investigations
When a Drupal site keeps its logs in the database, the log table competes with content and cache data for the same storage, is usually pruned on a schedule set by the site, and can only be searched through the Drupal admin interface. Moving logs out of the database with Drupal core's syslog module and sending them to a central log platform gives the security team a copy of the events that the site cannot quietly rewrite or lose during a database cleanup, and lets those events be searched next to firewall, identity provider and web server records. Teams need this when they run incident response, when auditors ask for evidence of login activity and configuration changes, or when they want alerts on failed logins or permission changes without someone opening the site to check.
Before you change anything, decide which events must leave the site and who will own them. Confirm which channels your sites currently write to the watchdog table, which of your contributed modules add their own log channels, and which facts an investigator will actually need, such as user identifiers, client addresses, request paths and timestamps in a consistent time zone. Confirm the retention period with your legal, compliance and security owners rather than copying a default, because the period you choose drives storage on the central platform. Drupal and all contributed projects hosted on Drupal.org are licensed under GPL-2.0-or-later, according to the Drupal.org licensing page, so there is no paid Drupal logging edition to buy. The cost of this work sits in the platform you ship logs to and in the people who design, test and operate the pipeline.
Which logging path fits which environment
This table compares four ways to record Drupal events: the database logger, core syslog alone, syslog forwarded to a Graylog Open syslog input, and GELF or Beats inputs where a host agent supports them. Read each row for what the option needs, what investigators get, and the main trade-off. The takeaway is that the database logger is fine for development, while any site that needs central search and retention should ship logs off the web node.
| Logging path | What it needs | What investigators get | Main trade-off |
|---|---|---|---|
| Database logger (dblog) | Core Database Logging module enabled, with enough database space and a retention setting in place | Events searchable in the Drupal admin Recent log messages report, tied to the site's own user and node data | Logs share the production database, so volume can slow the site and they are lost or hard to reach if the database fails |
| Core syslog only | Syslog module enabled and the host's syslog daemon configured to receive PHP messages | Events written to the host log stream, where local tools can read them and existing host retention applies | Logs stay on each server, so a multi-node site needs manual collection and correlation during an incident |
| Syslog forwarded to a Graylog Open syslog input | Syslog module enabled, a host forwarder such as rsyslog configured to send to a Graylog syslog input, and a reachable Graylog server | Central search across web, database and proxy hosts, with streams and pipelines that tag Drupal events and dashboards for investigators | You operate Graylog server nodes, MongoDB and a search backend, and must size storage and confirm the version compatibility matrix |
| GELF input | Graylog Open GELF input and a sender that emits GELF, such as a Graylog-aware logging library or agent | Structured fields per event, which make filtering by user, channel or request easier than plain text | Needs a sender that supports GELF; confirm the exact Drupal or host agent setup before choosing it |
| Beats input | Graylog Open Beats input and a Beats agent such as Filebeat installed on the Drupal hosts | Shipped log files from web and proxy servers with fields set by the agent | Only useful if an agent is already standard in your estate; confirm the Beats module or log paths for Drupal before relying on it |
| Database logger plus central forwarding | Both the database logger and a forwarder running at the same time | Admin-visible events for site staff plus a central copy for security teams | Two places to keep retention aligned, and the database copy still grows unless you prune it |
Choosing Graylog Open, Graylog Enterprise or Graylog Security
Graylog Open is the free edition. You run it on infrastructure you control, and it has no volume limits and no license fee. Support comes from the community rather than from Graylog, so the cost moves to your own staff, to a partner retainer, or to your team's time spent on troubleshooting and upgrades.
- No license fee: The edition is free with no volume limits, so your cost is hardware or cloud capacity, staff time and any support retainer.
- Community support only: Problems are handled through public channels, so plan internal ownership of incidents affecting the log pipeline.
- Self-managed operations: You own upgrades, MongoDB and OpenSearch or Data Node maintenance, index retention and backups.
- Core features included: Inputs such as syslog, streams, pipelines, search, dashboards and event-based alerts are available.
- Licensing review needed: Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved license, so have legal counsel review it before you rely on it in a regulated environment.
Confirm with your legal team how the SSPL-1.0 terms apply to your intended use, including any hosting-as-a-service or internal redistribution plans. Then confirm which support model you will use for production.
Graylog Enterprise is the paid tier for teams that need longer-term data handling and vendor-backed support. Graylog's pricing page lists a starting price of 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units. Licensing is based on processed data, with no per-user or per-device fees, so the price follows volume rather than headcount.
- Starting price: The pricing page lists 15,000 US dollars per year as the starting point, subject to the minimum volume.
- Data lake and archive restore: Older data can be kept in a lower-cost store and restored when an investigation needs it.
- Data tiering: Logs can be placed in storage tiers according to age and access needs.
- Correlation engine and 24/7 support: Multi-event correlation and vendor support hours are the main operational additions.
- Quote inputs: Ask for the price against your expected daily volume, retention period and whether the minimum applies.
Confirm the quote against your daily ingest and retention plan, and ask whether archive restore is included at the volume you need.
Graylog Security is the paid tier aimed at security operations. It starts at 18,000 US dollars per year on the same processed-data model and minimum as Enterprise. Its additions are security analytics features, so the decision depends on whether your team will use them in day-to-day investigations.
- Starting price: The pricing page lists 18,000 US dollars per year as the starting point, with the same 10 GB per day or 100 Graylog Compute Units minimum.
- SIEM features: Risk scoring, anomaly detection and investigations are the core additions for analysts.
- Compliance and threat content: Compliance packs and prebuilt threat detection content reduce the rule-writing your team would otherwise do.
- Platform requirement: Graylog Security needs OpenSearch 2.0 or later, so check your search backend version before buying.
- Overlap check: Compare these features with any SIEM or SOAR tool you already run, such as Wazuh or Shuffle, to avoid paying twice.
Confirm which security features your analysts will use within the first year, and ask the vendor which features are included at your volume tier.
How to configure Drupal syslog and a Graylog input
This sequence moves Drupal's operational messages out of the database and into a Graylog stream that the team can search, alert on and retain under its own policy. Each step ends with a check so the team knows the pipeline works before production traffic depends on it.
Confirm the Drupal version and PHP requirements
The engineer responsible for the site records the Drupal core version and the PHP version on each web node, then compares them with the PHP requirements on Drupal.org. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so a site on an older PHP runtime needs that work planned before logging changes are tested. The step is done when the team has a written version record for each environment and knows which Drupal release window is next, using the core release schedule for reference.
Choose the log platform and install Graylog
The platform owner decides how Graylog will run, either from the Debian or RPM packages on a supported Linux distribution or with Docker Compose for a single-node evaluation. The current documentation covers Graylog 7.2, and the compatibility matrix must be checked for the MongoDB and OpenSearch or Graylog Data Node versions that the chosen release supports. The step is done when the Graylog web interface loads over HTTPS on staging and the team has confirmed the search backend version against the compatibility matrix.
Enable core syslog with a clear identifier
On staging, a Drupal administrator enables the core Syslog module and sets the identifier in the site configuration so every message can be traced to one site, environment and node. Naming should follow a convention the team can filter on later, such as the site name plus environment. The step is done when a test page request produces a log line on the web node that carries the identifier, and the team has recorded the facility and severity levels in use.
Create a syslog or GELF input in Graylog
A Graylog administrator creates an input that receives the syslog or GELF messages from the Drupal web nodes, restricted to the network range or hosts that should send to it. The input listens on a port the team has agreed with the network owners and is bound to the correct interface on each Graylog node. The step is done when the input shows as running and the Graylog node reports received messages from a manual test sent from a web node.
Route Drupal messages into a dedicated stream
The Graylog administrator creates a stream with a rule that matches the Drupal identifier, and assigns it to an index set whose rotation and retention settings the team has chosen. Routing Drupal messages into their own stream keeps them separate from infrastructure logs and lets alerts and access rights be scoped to them. The step is done when test messages appear only in the Drupal stream and the index set shows the retention policy the security owner signed off on.
Verify test events and their fields on staging
The QA engineer triggers known events on staging, such as a failed login, a permission denial and a deliberate PHP warning, then searches for them in Graylog. The check confirms that each event arrives, that the timestamp matches the web node time in UTC, that the site identifier and severity are present as fields, and that no personal data appears in the message text beyond what the policy allows. The step is done when every test event is found and the results are written into a short verification record.
Reduce or disable the database logger as intended
Once the Graylog path is proven, the Drupal administrator reviews the database logging settings and either disables the dblog module or limits what it keeps, depending on the decision made earlier for troubleshooting and audit needs. The engineer then repeats a test event and confirms that the database no longer grows with each message and that the Graylog copy is still present. The step is done when the database table growth is checked against a baseline and the change is recorded in the change log.
Document the input, stream and retention settings
The platform owner writes down the input configuration, stream rules, index retention, access roles and the names of the staging and production sites, and stores this with the rest of the operations runbook. Confirming the production rollout is a separate change, approved by the team that owns the site. The step is done when a second engineer can find the configuration, reproduce the test events from the record and confirm the retention policy matches what the security owner approved.
What to keep for security investigations
Drupal logs only help an investigation if the right events were captured before the incident. The six items below are the categories we see teams decide on first, and each one needs a decision on scope, personal data handling and who can read it. Access to the central platform matters as much as the events themselves.
Authentication events and failed logins
Successful sign-ins, failed attempts, password resets and logouts show who reached the site and from where. Failed logins in bursts often point to credential stuffing, so they need to be captured with a timestamp, account name and source address. Decide whether to record the attempted username for unknown accounts, since that field can hold personal data. Check that these messages reach the central platform within the window your team expects.
Permission and role changes
Granting a role or changing a permission can widen access across the whole site without any content change being visible. Record who made the change, which role changed, which permissions were added or removed, and the account that received the role. Compare these events against your approved access list during routine reviews, because they are the most common way an account gains reach it should not have.
Configuration changes
Drupal stores settings such as text formats, input filters, mail servers and authentication providers in configuration. A change here can disable a control or redirect email without touching code. Confirm with your Drupal team which configuration changes emit events, and whether exports from version control are recorded alongside them so that a change made in the admin interface can be matched against the approved repository.
Module install and update events
Installing, enabling, uninstalling or updating a module changes the code that runs on every request. Record the module name, version, the account that acted and the time. Pair these events with your release calendar so that an unplanned change stands out. Ask whether installs can happen in production at all, because a stricter policy means that any such event is an investigation lead.
Error and access anomalies
PHP errors, denied-access responses, and unusual request volumes to admin paths can show probing or a failing integration. Decide which severity levels are shipped, since verbose debug output can contain query text, file paths and session details. Set aside time to review these entries on a schedule so they are not only read after an incident has been reported.
Admin actions and access to the platform
Actions on administrative pages, such as user blocks, content deletions and bulk operations, form the trail for who changed what. The same reasoning applies to the log platform itself. Graylog supports local and external user authentication, so confirm which accounts can search, export or delete data and restrict them to a small group. Read the Graylog user authentication docs before you assign roles.
Sizing storage, retention and alerts after launch
Size log storage before go-live, because retention decisions are hard to reverse once an investigation needs older data. The Graylog system architecture guidance gives a starting formula: daily ingest multiplied by retention days, multiplied by 120 percent. Measure daily ingest from a real week of Drupal traffic, not from estimates, since authentication failures, cron output and bot traffic can change the total sharply. Separately, size the message journal at 3 to 5 times daily ingest on SSDs, so Graylog can absorb indexing slowdowns without losing messages. Ask your team to confirm the retention period with security, legal and records owners before you set it, and confirm the figures against the version you deploy, since the current documentation covers Graylog 7.2.
Index rotation and retention control how that storage is used. In Graylog Open, you choose how each index set rotates: by message count, by size or by time. Retention then deletes the oldest indices once the configured limit is reached, so the rotation strategy determines how much history an investigator can search at any moment. Alerts come from event definitions, which run against real-time or historical searches and send notifications to PagerDuty, Slack or email. Keep the security-relevant alerts, such as repeated failed logins on the admin path or syslog silence from the web tier, separate from noisy operational alerts, and review both on a set cadence. Restore tests matter as much as alerting: confirm that archived or retained data can be recovered within a time your incident process requires.
For medium to large deployments, the Graylog multi-node guide recommends three Graylog server nodes and three MongoDB nodes running as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes, with is_leader set to false on the follower nodes. Plan that topology early, because it changes network paths, certificates and the backup scope. Confirm current licensing before you commit to a tier: Graylog Open has no volume limits, while Graylog Enterprise and Graylog Security are licensed on processed data with a stated minimum, and the quote should show how your daily ingest maps to that minimum.
Questions teams ask before outsourcing Drupal logging
What drives the cost and effort of Drupal logging work?
The main drivers are the number of Drupal sites, the volume of events they produce, whether you already run a log platform, and your retention and access rules. More sites and higher event volume mean more inputs to configure, more storage to size and more pipeline rules to test. An existing platform can shorten the work because the shipping and parsing already exist, while retention and access rules add design work for who can search which logs and for how long. Ask any partner to price these items separately in the written scope: sites in scope, log sources, target platform, retention periods and alert set. Cost is one-time for design and build and recurs for hosting, storage and review time.
How long does a Drupal logging project take?
Duration depends on the scope and the environment, so no fixed timeline applies to every site. A single Drupal site shipping logs to an existing platform is a much smaller job than a multisite estate that needs a new central platform, retention design and alert rules. The fastest way to get a reliable answer is to review your hosting access, current logging setup and target platform first, then agree a written scope with milestones. Ask for the sequence and what each milestone depends on, including approvals for retention and access.
What does our team need to provide before the work starts?
Plan to provide four things before the build begins:
- Access to the hosting environment for each Drupal site, including web server, PHP and database configuration
- Written retention requirements for each log category, set by your security or compliance owners
- A named owner for access approvals and for changes to log sources
- Staff who will review alerts and answer log investigations after launch
Without the last item, a well-built pipeline still produces logs nobody reads. Confirm these inputs in the written scope so that delays do not surface during the build.
Can our own team set up Drupal logging without a partner?
Yes, many teams can, provided they have engineers who know Drupal's logging channels, the web server and the chosen log platform. The core syslog module sends Drupal's messages to the system log, and the rest is routing, parsing and retention on the log platform side. Internal work is most at risk where nobody owns the alert rules after go-live, where retention is undefined, or where the platform's storage is not sized against daily ingest and retention. A partner is most useful when you need a documented design, a tested build and handover that your team can operate.
Do we need Graylog Open or a paid Graylog tier?
Graylog Open is free with no volume limits and community support, so many teams start there. According to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Enterprise adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support, and Security adds SIEM features such as investigations and prebuilt detection content. Choose a tier based on whether you need vendor support, archive restore or SIEM workflows. Note that Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, so have your legal team review it.
How do Drupal version upgrades affect the logging configuration?
Upgrades can change what Drupal logs and where, so logging should be re-checked after every core or major module update rather than assumed to survive. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Each core version also has its own PHP minimum. Test the syslog settings, channel names, parsing rules and alerts on staging before each upgrade, and keep the pipeline definition in version control so changes are reviewed. Check the Drupal core release schedule when planning.
What should we keep in logs for security investigations?
Keep enough detail to reconstruct who did what, when and from where, while limiting personal data in the logs themselves. Typical categories include authentication events, administrative changes, module and configuration changes, permission changes and errors from the web server and database. Set a retention period for each category based on your investigation and compliance needs, and confirm access rules so that only authorized staff can search sensitive events. Ask your security lead to approve the list before the pipeline is built, because retention choices affect storage size and cost.
Limits to confirm in your environment
A logging design depends on versions, licenses and storage rules that differ from one estate to the next. The cards below list the items to confirm with your own team, your vendors and your compliance owners before you commit to a pipeline, so the design you approve still holds after the first upgrade.
Drupal and PHP versions
Confirm which Drupal core release each site runs and the PHP version under it. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later. A site on an older PHP runtime cannot move to a current core release without a runtime upgrade first, and that changes which logging behavior and syslog options you can rely on. Record the version for every site in scope, including multisite installs and staging copies that will ship logs too.
Graylog, MongoDB and search backend pairing
Graylog needs MongoDB for configuration and a supported search backend for storage. Check that your planned Graylog release, MongoDB version and Data Node or OpenSearch version appear together in the vendor's compatibility matrix. Graylog Security also needs OpenSearch 2.0 or later. Ask your platform team to confirm the pairing in writing before procurement, since a mismatch discovered during install is expensive to unwind.
OpenSearch 1.x deprecation
Use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. If an existing Graylog estate or a reused cluster runs OpenSearch 1.x, plan the storage migration as part of this project rather than as a later task. Confirm which search backend each environment uses today, and whether Data Node is an option your team can operate, since Graylog recommends it as the search backend.
Graylog Open licensing under SSPL-1.0
Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license. Earlier releases were under GPL v3. Have your legal or procurement team review the license text against your internal open source policy, especially if you plan to offer log services to third parties or embed the product in a hosted service. Note that Drupal itself is GPL-2.0-or-later, so the two components carry different terms.
Module and logger behavior on your version
Confirm that the logging modules and syslog settings your design relies on behave as expected on the Drupal version you run. Test the chosen logger channel, severity threshold and message format on staging, then check that no contributed module in the stack writes to the database log in a way that bypasses the change. Record the exact module versions so the test result stays valid after the next security release.
Retention and data residency fit
Retention is set by your policy, but storage is set by the platform. Confirm how long each log category must be kept, where the data may physically reside, and whether the index rotation and retention settings in Graylog can meet both. Graylog's guidance sizes storage from daily ingest, retention days and a 120 percent margin, so ask your team for a daily ingest estimate per site before choosing hardware or a cloud region.
How DeployOpen scopes and delivers Drupal logging
DeployOpen plans Drupal logging as a fixed-scope engagement with written deliverables agreed before any configuration begins. The scope starts with a list of events the security and operations teams need to answer questions about: failed and successful logins, account and role changes, permission edits, module and theme installs, configuration changes, and PHP errors. Each event category is mapped to the syslog facility and severity Drupal will emit it under, and the team agrees which events stay in Drupal's database for short-term operational use and which go to the central platform. That mapping is the input for every later step, so it is the first decision to close with the client's security lead.
The build covers three parts. First, Drupal's core syslog module is configured and tested on staging so that entries reach the web server's syslog and then the forwarding path. Second, Graylog is deployed and hardened in infrastructure the client controls, with the authentication model, TLS on inputs, and the MongoDB and search backend sized according to the Graylog installation documentation. Third, the team builds the streams, dashboards and event definitions that turn raw entries into alerts, and documents the runbook: how to add a new event type, rotate or restore indices, handle an alert, and escalate an incident. Ask any delivery partner to name the Graylog version and the search backend they will use, and to confirm that version against the compatibility matrix before the design is signed off.
DeployOpen does not publish a price list. A quote follows from the written scope, and the main cost drivers are the number of event types, the number of Drupal sites feeding one platform, whether the Graylog cluster is single-node or multi-node, and how many alert paths must be integrated. Ongoing monitoring, tuning of alerts and support for the platform can be arranged as a retainer, which is usually a better fit once the initial build is live. Before requesting a quote, confirm your log retention period, the volume you expect per day, and who in your organization owns alert response.
