Drupal Monitoring & Observability

We start from user-impacting behaviors rather than host utilization. For Drupal, common SLIs include request success rate (HTTP 5xx and application-level failures), latency for key endpoints (homepage, search, checkout, authenticated flows), and saturation indicators (PHP-FPM worker exhaustion, database connection pressure, cache hit ratio degradation). We then translate those SLIs into SLOs that match business tolerance and operational reality. For example, an availability SLO might be paired with a latency SLO for critical journeys, plus a background-processing SLO for queues if the platform relies on asynchronous work. We also define error budget policies: what constitutes a burn rate, when to page, and when to trigger reliability work. Finally, we ensure the measurement is stable: consistent labels, controlled cardinality, and comparable environments. SLOs only work when the underlying telemetry is trustworthy and not overly sensitive to deployment changes, traffic anomalies, or noisy metrics.

A typical architecture separates concerns across metrics, logs, and alerting. Prometheus (or a compatible metrics backend) scrapes exporters for infrastructure and services, while Grafana provides dashboards and alert evaluation. Centralized logging is handled via an ELK pipeline, with log shipping from Docker hosts/containers and parsing rules that normalize fields. For Drupal, we usually monitor at multiple layers: edge/web (Nginx/Apache), PHP-FPM, Drupal application behavior (errors, cache behavior, queue depth), and dependencies (database, cache, search, external APIs). We add correlation metadata such as environment, service, tenant/site, and deployment version so responders can pivot from an alert to the relevant logs and metrics. The architecture also includes governance: retention policies, access controls, and conventions for naming and labels. This prevents metric explosions, keeps dashboards maintainable, and ensures observability remains reliable as the platform scales and teams change.

We design alerts around symptoms and user impact, not every possible metric threshold. The first layer is SLI-based paging: alerts tied to error rate, latency, and saturation with burn-rate logic where appropriate. The second layer is diagnostic alerts that provide context but do not page, such as increasing slow queries or cache eviction spikes. We also tune evaluation windows and grouping to avoid flapping and duplicate pages. Alerts should include clear ownership, a concise description of impact, and a direct link to the relevant dashboard and runbook. If an alert cannot be acted on, it should not page. After implementation, we run an alert review cycle. We look at false positives, missed incidents, and noisy rules, then adjust thresholds, add missing signals, or refine routing. Alerting quality is treated as an operational asset that requires ongoing maintenance, not a one-time configuration task.

We recommend a small set of repeatable practices: a clear on-call rotation with escalation paths, runbooks tied to alerts, and a consistent incident process (severity classification, communication, and post-incident review). Observability should support these practices by providing a single place to answer: what is broken, what changed, and what to do next. For Drupal specifically, runbooks often cover PHP-FPM saturation, cache instability, database contention, queue backlogs, and dependency failures. Dashboards should include a top-level service health view, plus drill-down panels that map to those runbooks. We also encourage regular reliability reviews using SLO reports and incident trends. This helps teams prioritize reliability work, validate that alerts remain actionable, and ensure operational knowledge is shared across platform and application teams rather than concentrated in a few individuals.

Effective integration starts with consistent structure. We configure log shipping from Docker (or hosts) into Logstash/Elasticsearch, then normalize fields such as timestamp, environment, service, hostname/container, and request identifiers. Where possible, we parse web server access logs and PHP/Drupal logs into structured fields so Kibana queries are reliable and fast. We also address sensitive data and compliance. Drupal logs can inadvertently include user identifiers, tokens, or request payloads; we implement filtering and redaction rules and set retention policies appropriate to the organization’s requirements. Finally, we connect logs to operational workflows. Dashboards and alerts should link to pre-filtered Kibana views, and logs should include deployment metadata (version, build, git SHA) to correlate incidents with releases. The goal is to reduce time spent searching and increase time spent diagnosing with relevant context.

We collect a layered set of metrics. At the infrastructure level: CPU, memory, disk, network, and container runtime signals. At the web/runtime level: request rates, response codes, upstream latency, and PHP-FPM pool metrics such as active/idle workers, queue length, and slow request indicators. For dependencies, we collect database metrics (connections, query latency proxies, locks, buffer/cache behavior where available), cache metrics (hit ratio, evictions, memory pressure), and queue metrics (depth, processing rate, age of oldest message). If search is involved, we monitor indexing and query latency and error rates. We then map these metrics to dashboards and alerts that answer operational questions: is the service healthy, which dependency is driving degradation, and is the platform approaching saturation. We also control label cardinality to keep Prometheus stable and cost-effective at enterprise scale.

We design access around roles and operational needs. Platform and SRE teams typically require full access to dashboards, alert configuration, and log queries. Application teams may need read access to service dashboards and scoped log views. Stakeholders often need high-level SLO reporting without access to raw logs. We implement separation using the capabilities of the chosen stack (Grafana organizations/folders and permissions, Elasticsearch/Kibana roles and index permissions, and network-level controls). We also define what data is allowed to be collected and stored, including redaction rules and retention policies. Governance includes change control for alert rules and dashboards. We recommend versioning configuration as code where feasible, using review workflows to prevent accidental changes that create noise or blind spots. This keeps observability reliable and auditable over time.

Maintainability comes from standards and reuse. We define naming conventions, label schemas, and dashboard templates that can be applied across sites, environments, and clusters. For multi-site Drupal, we avoid per-site bespoke dashboards where possible and instead use variables and consistent labels to slice by tenant or site. We also control metric cardinality and log volume. Unbounded labels (like full URLs or user IDs) can destabilize metrics backends; we design aggregation strategies and sampling where appropriate. For logs, we define retention and indexing strategies that balance diagnostic value with cost. Operationally, we recommend a review cadence: quarterly dashboard relevance checks, alert quality reviews after incidents, and SLO recalibration when platform behavior changes. Observability is treated as part of the platform architecture, evolving alongside Drupal upgrades, infrastructure changes, and new integrations.

It can if implemented without constraints, but it is manageable with careful design. We prioritize low-overhead telemetry first: infrastructure and runtime metrics, web server metrics, and structured logging with controlled verbosity. For application-level instrumentation, we avoid high-cardinality labels and excessive per-request computation. Logging is often the bigger risk than metrics. We set log levels intentionally, filter noisy categories, and ensure that production logging does not include large payloads or sensitive data. Retention and indexing policies are tuned to avoid runaway storage and query costs. If tracing is introduced, we typically start with sampling and targeted instrumentation for critical paths. We validate overhead through load testing or by comparing baseline performance before and after changes. The goal is to improve operational visibility without creating new bottlenecks or destabilizing the platform.

We treat observability data as production data. For logs, we implement controls to prevent collection of secrets, tokens, and personal data. This includes redaction rules, careful selection of logged fields, and validation of Drupal and web server logging configuration. We also define retention periods aligned with compliance requirements. For metrics, we avoid labels that could contain personal data or identifiers. Metrics should describe system behavior, not user-level details. We also secure access to dashboards and log search using role-based permissions and network controls. Where organizations have strict requirements, we document data flows and storage locations, and we can support audit needs by versioning observability configuration and maintaining change history. The objective is to provide operational visibility while reducing the risk of data exposure through telemetry systems.

Timelines depend on platform complexity and what already exists. A minimum viable baseline for a single Drupal production environment can often be established in a few weeks: core metrics, a service health dashboard, basic alerting, and centralized logging with essential parsing. For multi-site estates, multiple environments, or strict governance requirements, implementation typically becomes iterative. Additional time is needed for dependency coverage, alert tuning, SLO reporting, access control, and runbook development. Alert quality usually improves after observing real traffic and incidents, so we plan for a tuning phase rather than treating alerting as a one-off task. We recommend delivering in increments: baseline visibility first, then deeper instrumentation and governance. This approach reduces risk, provides immediate operational value, and ensures the resulting observability layer remains maintainable as the Drupal platform evolves.

Deliverables typically include configured metrics collection, dashboards, alert rules, and centralized logging pipelines, plus documentation that explains how to use and maintain them. We also provide runbooks tied to paging alerts and a clear mapping of signals to ownership (platform, application, or dependency teams). Where possible, we implement configuration as code so your teams can review changes, version them, and deploy updates through your existing workflows. We also document conventions for naming, labels, and dashboard structure to keep future additions consistent. Handover includes working sessions with on-call responders and platform engineers: how to interpret service health, how to drill down during incidents, how to tune alerts safely, and how to extend coverage when new services or dependencies are introduced. The goal is operational independence with a maintainable baseline.

Collaboration typically begins with a short discovery phase focused on your current operational reality. We review the Drupal architecture, hosting model, environments, existing monitoring/logging tools, and recent incidents. We also identify the critical user journeys and dependencies that most often drive downtime or degraded performance. From that, we agree on a scoped baseline: which SLIs to implement first, what “actionable” means for your on-call model, and how access and data retention should work. We define success criteria such as reduced time to detect, reduced time to diagnose, and a first set of dashboards and alerts that responders will actually use. We then move into implementation in small increments, validating signals with real traffic and tuning alerts with your team. Early working sessions are hands-on and operational: we build the initial dashboards and runbooks together, so ownership and maintainability are established from the start rather than deferred to the end of the project.