• Skip to secondary menu
  • Skip to main content
  • Skip to primary sidebar
  • Home
  • Projects
  • Products
  • Themes
  • Tools
  • Request for Quote

Vengala Vinay

Having 9+ Years of Experience in Software Development

  • Home
  • WordPress
  • PHP
    • Codeigniter
  • Django
  • Magento
  • Selenium
  • Server
Home » Server Monitoring Best Practices: Keeping Your WooCommerce App and MongoDB Clusters Alive on Linode

Server Monitoring Best Practices: Keeping Your WooCommerce App and MongoDB Clusters Alive on Linode

Establishing a Robust Monitoring Foundation with Prometheus and Grafana on Linode

Maintaining high availability for a critical WooCommerce application, especially when backed by a distributed MongoDB cluster, demands a proactive and granular monitoring strategy. On Linode, this translates to leveraging powerful open-source tools like Prometheus for metrics collection and Grafana for visualization and alerting. This section outlines the foundational setup for these components.

Deploying Prometheus Server

A dedicated Linode instance is recommended for the Prometheus server to ensure isolation and dedicated resources. We’ll use a standard installation method, typically involving downloading the binary or using a package manager if available and stable.

First, download the latest stable Prometheus release:

wget https://github.com/prometheus/prometheus/releases/download/v2.48.0/prometheus-2.48.0.linux-amd64.tar.gz
tar xvfz prometheus-2.48.0.linux-amd64.tar.gz
cd prometheus-2.48.0.linux-amd64

It’s best practice to run Prometheus as a non-root user. Create a dedicated user and group:

sudo groupadd --system prometheus
sudo useradd --system --no-create-home --shell /bin/false -g prometheus prometheus

Move the binaries and configuration files to their appropriate locations and set ownership:

sudo mv prometheus promtool /usr/local/bin/
sudo mv consoles console_libraries /etc/prometheus/
sudo mv prometheus.yml /etc/prometheus/prometheus.yml
sudo chown -R prometheus:prometheus /etc/prometheus
sudo chown prometheus:prometheus /var/lib/prometheus

Create a systemd service file for Prometheus to manage its lifecycle:

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file /etc/prometheus/prometheus.yml \
  --storage.tsdb.path /var/lib/prometheus/ \
  --web.console.templates=/etc/prometheus/consoles \
  --web.console.libraries=/etc/prometheus/console_libraries

[Install]
WantedBy=multi-user.target

Save this content as /etc/systemd/system/prometheus.service. Then, enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometis

Verify the status and access the Prometheus UI on port 9090:

sudo systemctl status prometheus
curl http://localhost:9090/graph

Configuring Prometheus for WooCommerce and MongoDB

The core of Prometheus monitoring lies in its configuration file, /etc/prometheus/prometheus.yml. We need to define scrape targets for our WooCommerce application and MongoDB cluster. For WooCommerce, this typically involves exposing metrics via a PHP-FPM exporter or a custom endpoint. For MongoDB, the official mongodb_exporter is the standard choice.

First, let’s configure the mongodb_exporter. Install it on a node that can reach your MongoDB cluster (or on each node if you prefer distributed collection):

wget https://github.com/mongodb-developer/mongodb_exporter/releases/download/v0.36.0/mongodb_exporter-v0.36.0.linux-amd64.tar.gz
tar xvfz mongodb_exporter-v0.36.0.linux-amd64.tar.gz
sudo mv mongodb_exporter /usr/local/bin/

Create a systemd service for mongodb_exporter. Ensure you configure the MongoDB connection string appropriately, especially for authentication and replica set discovery.

[Unit]
Description=MongoDB Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/mongodb_exporter \
  --mongodb.uri="mongodb://user:[email protected]:27017,mongo2.linode.com:27017/admin?replicaSet=rs0" \
  --web.listen-address=":9204"

[Install]
WantedBy=multi-user.target

Save this as /etc/systemd/system/mongodb_exporter.service, set permissions, and start it:

sudo chown prometheus:prometheus /usr/local/bin/mongodb_exporter
sudo systemctl daemon-reload
sudo systemctl enable mongodb_exporter
sudo systemctl start mongodb_exporter
sudo systemctl status mongodb_exporter

Now, update your Prometheus configuration file (/etc/prometheus/prometheus.yml) to include scrape jobs for both MongoDB and your WooCommerce application. For WooCommerce, assuming you have a PHP-FPM exporter running on port 9250:

global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.

scrape_configs:
  # Scrape Prometheus itself
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Scrape MongoDB cluster
  - job_name: 'mongodb'
    static_configs:
      - targets: ['mongo1.linode.com:9204', 'mongo2.linode.com:9204', 'mongo3.linode.com:9204'] # Replace with your MongoDB exporter endpoints

  # Scrape WooCommerce application (e.g., PHP-FPM exporter)
  - job_name: 'woocommerce_app'
    static_configs:
      - targets: ['your_app_server_ip:9250'] # Replace with your app server IP and exporter port

  # Add more jobs for other services as needed

After modifying prometheus.yml, reload the Prometheus configuration:

sudo systemctl reload prometheus

You can verify that Prometheus is scraping your targets by navigating to “Status” -> “Targets” in the Prometheus UI.

Deploying Grafana for Visualization and Alerting

Grafana provides the user interface for exploring metrics and setting up alerts. It can be installed on the same Linode as Prometheus or on a separate instance for better resource management.

Install Grafana using their official APT repository:

sudo apt-get update
sudo apt-get install -y apt-transport-https software-properties-common wget
wget -q -O - https://apt.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://apt.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install grafana

Enable and start the Grafana service:

sudo systemctl daemon-reload
sudo systemctl enable grafana-server
sudo systemctl start grafana-server
sudo systemctl status grafana-server

Access Grafana via your browser at http://your_linode_ip:3000. The default credentials are username admin and password admin. You will be prompted to change the password on first login.

Configuring Grafana Data Sources and Dashboards

In Grafana, navigate to “Configuration” (gear icon) -> “Data Sources” and click “Add data source”. Select “Prometheus” and enter the URL of your Prometheus server (e.g., http://localhost:9090 if on the same machine, or http://prometheus_server_ip:9090 if on a different Linode).

For WooCommerce and MongoDB monitoring, it’s highly recommended to import pre-built Grafana dashboards. You can find excellent community-contributed dashboards on Grafana.com. Search for “MongoDB” and “PHP-FPM” or “WooCommerce” dashboards.

To import a dashboard:

  • Go to “Dashboards” (four squares icon) -> “Import”.
  • Enter the Grafana.com dashboard ID or upload a JSON file.
  • Select your Prometheus data source.
  • Click “Import”.

Key MongoDB metrics to monitor include:

  • Replication Lag: mongodb_replset_member_optime_lag – Crucial for ensuring data consistency across replicas.
  • Connections: mongodb_server_connections_current, mongodb_server_connections_available – Monitor for connection exhaustion.
  • Memory Usage: mongodb_mongod_wiredtiger_cache_bytes_used, mongodb_mongod_wiredtiger_cache_bytes_total – Track cache performance and potential memory pressure.
  • Disk I/O: mongodb_mongod_network_bytes_in_total, mongodb_mongod_network_bytes_out_total, and disk read/write operations.
  • Query Performance: Metrics related to query execution times and slow queries (often requires specific configuration or additional exporters).

For WooCommerce, focus on:

  • PHP-FPM Pool Metrics: Active processes, idle processes, requests per second, slow requests.
  • Application Response Times: If your WooCommerce application exposes custom metrics (e.g., via a Prometheus client library for PHP).
  • HTTP Request Metrics: Status codes (2xx, 4xx, 5xx), request latency.
  • Database Query Times: Specific to WooCommerce’s interaction with its underlying MySQL/MariaDB database (if not using MongoDB for that layer).

Setting Up Alerting with Alertmanager

Alerting is a critical component. Prometheus evaluates alerting rules, and Alertmanager handles deduplication, grouping, and routing of alerts to various receivers like email, Slack, or PagerDuty.

Install Alertmanager on the same Linode as Prometheus or a dedicated one:

wget https://github.com/prometheus/alertmanager/releases/download/v0.26.0/alertmanager-0.26.0.linux-amd64.tar.gz
tar xvfz alertmanager-0.26.0.linux-amd64.tar.gz
cd alertmanager-0.26.0.linux-amd64

Create a user, directories, and a systemd service file similar to Prometheus:

sudo groupadd --system alertmanager
sudo useradd --system --no-create-home --shell /bin/false -g alertmanager alertmanager
sudo mv alertmanager /usr/local/bin/
sudo mv alertmanager.yml /etc/alertmanager/alertmanager.yml
sudo chown -R alertmanager:alertmanager /etc/alertmanager
sudo chown alertmanager:alertmanager /var/lib/alertmanager

Systemd service file (/etc/systemd/system/alertmanager.service):

[Unit]
Description=Alertmanager
Wants=network-online.target
After=network-online.target

[Service]
User=alertmanager
Group=alertmanager
Type=simple
ExecStart=/usr/local/bin/alertmanager \
  --config.file /etc/alertmanager/alertmanager.yml \
  --storage.tsdb.path /var/lib/alertmanager/

[Install]
WantedBy=multi-user.target

Enable and start Alertmanager:

sudo systemctl daemon-reload
sudo systemctl enable alertmanager
sudo systemctl start alertmanager
sudo systemctl status alertmanager

Configure Alertmanager (/etc/alertmanager/alertmanager.yml) to define receivers (e.g., Slack) and routing rules. Then, configure Prometheus to send alerts to Alertmanager by adding the following to /etc/prometheus/prometheus.yml:

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093'] # Assuming Alertmanager is on the same Linode

Reload Prometheus again.

Example Alerting Rules for MongoDB and WooCommerce

Alerting rules are defined in separate files that Prometheus loads. Create a directory, e.g., /etc/prometheus/rules/, and add rule files. For instance, /etc/prometheus/rules/mongodb_alerts.yml:

- groups:
  - name: mongodb.rules
    rules:
    - alert: MongoReplicaLagHigh
      expr: avg by (replica_set) (mongodb_replset_member_optime_lag{state="secondary"}) > 60
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "MongoDB replica set {{ $labels.replica_set }} has high replication lag."
        description: "The secondary node in replica set {{ $labels.replica_set }} is lagging by more than 60 seconds."

    - alert: MongoHighConnectionCount
      expr: mongodb_server_connections_current > 0.9 * mongodb_server_connections_available
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "MongoDB connection pool is nearing capacity."
        description: "Replica set {{ $labels.replica_set }} is using 90% of its available connections."

    - alert: MongoDiskSpaceLow
      # This requires a disk space exporter or custom metric. Assuming a hypothetical metric.
      # expr: node_filesystem_avail_bytes{mountpoint="/data/db"} / node_filesystem_size_bytes{mountpoint="/data/db"} * 100 < 10
      expr: mongodb_mongod_storage_data_size_bytes > 0 # Placeholder, replace with actual disk usage metric
      for: 15m
      labels:
        severity: critical
      annotations:
        summary: "MongoDB data directory is running low on disk space."
        description: "Disk space for MongoDB data on {{ $labels.instance }} is below 10%."

And for WooCommerce (assuming PHP-FPM exporter): /etc/prometheus/rules/woocommerce_alerts.yml:

- groups:
  - name: woocommerce.rules
    rules:
    - alert: PHPFPMHighProcessCount
      expr: php_fpm_pool_process_active > php_fpm_pool_process_max
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "PHP-FPM pool {{ $labels.pool }} has reached maximum active processes."
        description: "The PHP-FPM pool {{ $labels.pool }} on {{ $labels.instance }} has reached its configured maximum of {{ $labels.process_max }} active processes."

    - alert: PHPFPMHighSlowRequests
      expr: php_fpm_pool_slow_requests_total > 0
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "PHP-FPM pool {{ $labels.pool }} is experiencing slow requests."
        description: "The PHP-FPM pool {{ $labels.pool }} on {{ $labels.instance }} has recorded {{ $value }} slow requests."

Update /etc/prometheus/prometheus.yml to load these rules:

rule_files:
  - "/etc/prometheus/rules/*.yml"

Reload Prometheus for the rules to take effect. Test your alerts by temporarily lowering thresholds or simulating conditions that trigger them.

Advanced Considerations: Blackbox Exporter and Log Monitoring

Beyond internal metrics, external availability is paramount. The Prometheus Blackbox Exporter allows you to probe endpoints over various protocols (HTTP, TCP, ICMP) to simulate user experience and check external accessibility of your WooCommerce site.

Configure the Blackbox Exporter similarly to mongodb_exporter, defining targets for your WooCommerce domain. Then, add a scrape job in prometheus.yml:

- job_name: 'blackbox_http'
  metrics_path: /probe
  params:
    module: [http_2xx] # Or http_post, http_get, etc.
  static_configs:
    - targets:
      - https://your-woocommerce-domain.com # Target URL
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: blackbox_exporter_ip:9115 # Blackbox exporter address

For deeper insights, integrate log monitoring. Tools like Loki, paired with Promtail for log collection and Grafana for querying, can correlate logs with metrics. Promtail agents can be deployed on your WooCommerce and MongoDB Linodes, forwarding logs to a central Loki instance. This allows you to search logs based on labels that match your Prometheus metrics, providing a unified view of system health.

Consider implementing distributed tracing with Jaeger or Zipkin if your WooCommerce architecture involves microservices or complex inter-service communication. This provides end-to-end visibility into request flows, pinpointing latency bottlenecks across different components.

Primary Sidebar

A little about the Author

Having 9+ Years of Experience in Software Development.
Expertised in Php Development, WordPress Custom Theme Development (From scratch using underscores or Genesis Framework or using any blank theme or Premium Theme), Custom Plugin Development. Hands on Experience on 3rd Party Php Extension like Chilkat, nSoftware.

Recent Posts

  • Disaster Recovery 101: Architecting Auto-Failovers for Redis and PHP Deployments on OVH
  • How We Audited a High-Traffic WooCommerce Enterprise Stack on Google Cloud and Mitigated Race conditions during high-concurrency payment processing
  • Disaster Recovery 101: Architecting Auto-Failovers for Elasticsearch and Magento 2 Deployments on DigitalOcean
  • An Auditor’s Checklist for Securing WordPress Backends on OVH
  • Step-by-Step: Diagnosing Perl script high CPU throttling due to unoptimized regular expressions on AWS Servers

Copyright © 2026 · Vinay Vengala