How to Monitor PowerMTA with Grafana

When you run your own email infrastructure, the difference between a healthy mail server and a silent disaster is visibility. If you want to monitor PowerMTA Grafana dashboards, you need to turn PowerMTA's accounting data into metrics that Grafana can chart — throughput, queue depth, bounces, and per-domain delivery rates — so problems surface before your IP reputation takes the hit.

Why Monitor PowerMTA Grafana Dashboards

PowerMTA is a workhorse: it can push enormous volumes of email reliably. But out of the box it only gives you text logs and command-line tools like pmta show. Without a visual layer, you will miss slow-burning problems — a queue that grows 5% per hour, a single domain rejecting more mail than usual, or a warmup pool that never reaches its target throughput.

Grafana fixes this by giving you real-time dashboards and alerting. A single glance tells you whether deliveries are flowing, where bounces are spiking, and which domains need attention. For anyone sending bulk or transactional mail, this visibility is not optional — it is how you protect sender reputation.

Understanding PowerMTA Accounting Files

The foundation of every PowerMTA monitoring setup is the accounting file (acct). PowerMTA writes a record for every message it handles, including delivery attempts, bounces, deferrals, and rejections. A typical acct line includes the message ID, recipient domain, status code, delivery time, and virtual MTA used.

To make acct data usable, enable accounting in your PowerMTA configuration:

<acct-file /var/log/pmta/acct.csv>
move-interval 5m
compress-after-move yes
</acct-file>

Rotating the file every 5 minutes keeps it small and gives your parser fresh data to chew on. You can also enable the log-acct option on specific virtual MTAs if you want per-pool accounting.

Parsing Acct Files into Metrics

Acct files are CSV-like and machine-readable, so parsing them is straightforward. The classic approach is a small script that tails the acct file and emits counters:

  • pmtaacct — an open-source utility that parses PowerMTA acct files and exposes delivery statistics.
  • Custom logtail scripts — a Python or shell script that reads new lines, classifies each record (delivered, bounced, deferred, dropped), and increments counters keyed by domain and virtual MTA.
  • mtail or grok exporters — tools that extract metrics from text logs using regular expressions and expose them over HTTP.

Whatever you choose, the key design decision is the same: convert per-message records into aggregated counters with labels like domain, vmta, and status. Counters are exactly what Prometheus and Telegraf expect.

Building the Pipeline: Prometheus and Telegraf

Once you can produce counters, you need to get them into a time-series database. Two proven paths:

Option 1: Prometheus with a Custom Exporter

Write your parser as a Prometheus exporter — a small HTTP service that serves metrics at /metrics. Prometheus scrapes it every 15–30 seconds. Metrics to expose include:

pmta_delivered_total{domain="gmail.com",vmta="default"}
pmta_bounced_total{domain="yahoo.com",bounce_type="hard"}
pmta_deferred_total{domain="outlook.com"}
pmta_queue_size{queue="gmail.com"}

For queue size, query PowerMTA's status directly (via pmta show queues or the HTTP API) since the acct file only tells you about finished deliveries.

Option 2: Telegraf Tail Input

Telegraf's tail input plugin can watch the acct file, and a processor (or a small exec script) can parse each line and write metrics to InfluxDB or Prometheus. This is the fastest route if you already run Telegraf for host metrics via node exporter or the system plugin.

Either way, to monitor PowerMTA with Grafana in production, keep the scraper/parser on the same server as PowerMTA. Parsing acct files over NFS or a remote mount is asking for lag and lock contention.

Setting Up the Grafana Dashboard

With metrics flowing into Prometheus, point Grafana at it as a data source and build your dashboard. A practical PowerMTA dashboard has these panels:

  • Delivery throughput — messages delivered per minute, stacked by virtual MTA. Shows whether your sending rate matches expectations.
  • Queue depth — current queue size per domain over time. A growing sawtooth here is your earliest warning sign.
  • Bounce rate — hard and soft bounces as a percentage of deliveries, per domain. Spikes mean list quality or reputation problems.
  • Delivery rate per domain — successful deliveries divided by attempts, per recipient domain. Essential during IP warmup.
  • Deferral reasons — top deferral/bounce codes so you can see, for example, that Gmail is rate-limiting you versus rejecting you outright.

Use template variables for domain and vmta so one dashboard covers your entire fleet. Grafana's table panel is perfect for a per-domain breakdown sorted by worst delivery rate — that is the view you will check every morning.

Alerting on Queue Spikes and Delivery Drops

Dashboards are for humans; alerts are what save you at 3 AM. When you monitor PowerMTA with Grafana, configure alerts (or Prometheus Alertmanager) for these conditions:

  • Queue spike: queue size for any domain exceeds your threshold (e.g., 10,000 messages) for more than 10 minutes — possible throttling, DNS, or reputation issue.
  • Delivery rate drop: per-domain delivery rate falls below 90% over a 15-minute window — investigate before the ISP starts bulk-foldering everything.
  • Bounce rate surge: hard bounce rate doubles versus the 24-hour baseline — usually a stale list or a compromised account.
  • Zero throughput: no deliveries for 5 minutes during expected sending hours — PowerMTA may be paused, or the server may be out of disk.

Route critical alerts to PagerDuty or Telegram and informational ones to email. Always include the domain and virtual MTA in the alert message so you can act without opening the dashboard.

Hardware and Hosting Considerations

Running Prometheus, Grafana, and a PowerMTA parser alongside your mail server adds real load — especially disk I/O from acct files and TSDB writes. On a busy sender, give the monitoring stack its own VPS rather than sharing the mail server's disk. Providers with generous NVMe storage and unmetered bandwidth keep costs predictable; Contabo's VPS plans are a popular budget choice for running Grafana next to a PowerMTA box.

Key Takeaways

  • When you monitor PowerMTA Grafana dashboards consistently, small deliverability problems get caught before they become inbox disasters.
  • PowerMTA's accounting (acct) files are the raw material — enable rotation and parse them into labeled counters.
  • Expose counters through a Prometheus exporter or Telegraf's tail plugin, and query live queue depth from PowerMTA directly.
  • A good Grafana dashboard tracks throughput, queue depth, bounce rate, and per-domain delivery rates.
  • Alerts on queue spikes, delivery-rate drops, and zero throughput catch problems before they damage sender reputation.
  • Run the monitoring stack on a separate VPS with fast disk so it never competes with the mail server itself.

Set up this way, you can monitor PowerMTA with Grafana confidently from a single dashboard and catch delivery problems while they are still cheap to fix.

Related Guides

Leave a Comment Cancel reply

Exit mobile version