PowerMTA statistics collection.
Runs
and data checks.

The tiles show the statistics collection schedule and the result of the last run — the first thing to check if the numbers on other tabs look doubtful. Once a day at 03:40 the Hub runs pmtastats right on the server, and what travels over the network is the result, not the accounting files themselves. In the example the last run is a manual one, Oct 23 at 22:24, “with a warning”, and the tile tells you right away that the screens show data from 03:40. 15 of 15 servers polled, needing attention — 0. The last run took 1 m 15 s and parsed 122,032 records; the history in the Hub is 9 days, with a one-week retention on the server. If it says “with a warning”, look for the cause in the log below.

Enlarge

• Schedule — once a day at 03:40, pmtastats right on the server.
• Last run — manual, Oct 23 at 22:24, “with a warning” — the screens show data from 03:40.
• Progress — 1 m 15 s, 15 of 15 servers, 13 with sending, 122,032 records.
• History — 9 days, with one-week retention on the server.
• Attention — 0 — all servers are reachable.

What travels over the network is the result, not the accounting files themselves.

The cards show how collection went on each server: when it was polled, how many accounting files were taken, what period of data it keeps and how many records were parsed. The screen tells you whether every server made it into the statistics. In the example thirteen servers handed over 8 files each, from 4,267 to 37,169 records, while lab-01 and mta-11 are marked “no sending” — that's normal, not an alarm. At the bottom — how much space the accounting takes in the Hub: about 1.8 GB a year. MailerQ servers are listed separately: they have no PowerMTA accounting. It's important to tell “no sending” apart from a silent server: an empty accounting file and a server that didn't answer are different things.

Enlarge

• Thirteen servers — manual run 22:24–22:25, 8 files each, data Oct 16–Oct 23.
• Records — from 4,267 to 37,169 on tx-01; utility 6.0r3.
• lab-01 and mta-11 — “no sending” — zero files.
• MailerQ — listed separately — no PowerMTA accounting.
• Space — 10.1 MB for 9 days, about 1.8 GB a year.

“No sending” is normal, not an alarm.

The history depth screen shows how much accounting data is kept on the server and how much has already been collected in the Hub. It tells you whether any days were lost: files on the server live for a week, and whatever isn't collected in time disappears. In the example the server keeps 7 days under the delete-after directive, which the Hub writes itself, while the Hub holds 9 days and 122,769 records, with 0 missed days. Days still on the server don't count as gaps. If a server doesn't answer for a long time, its days will sooner or later be deleted from the server and become a real gap — so it's worth keeping this counter at zero.

Enlarge

• On the server — 7 days — the delete-after directive.
• In the Hub — 9 days, 122,769 records, data since Oct 13.
• Missed — 0.

Days still on the server don't count as gaps.

The run log is the list of collection runs with the result of each: time, number of servers and files, records, duration and the check result. A row expands into a console where you follow the run server by server. In the example the two nightly runs on Oct 21 and Oct 23 finished with “success”, and the manual run on Oct 23 at 22:24 is expanded: SSH connection, pmtastats over 8 files, “4,330 records parsed in 4.1 s”. Console lines are in the Hub's interface language, with numbers and server names. The nightly runs took 1 m 15 s each, 104 files each, 122,462 and 122,769 records. If a run failed, the result of its check is at the end of the console, on the next screen.

Enlarge

• Nightly — Oct 21 and Oct 23 at 03:40 — 15 servers, 104 files, the check added up.
• Manual — Oct 23 at 22:24.
• Console — SSH, pmtastats over 8 files, “4,330 records parsed in 4.1 s”, slices.

Console lines are in the Hub's interface language.

The end of the console shows the result of the run — the check for each server: the server name and twelve checks in a column. This is exactly where you see why the result wasn't published. In the example the bounce breakdown by vMTA didn't add up on cl-01: 197 versus 195 — this happens when records are appended to the current day's file while it's being parsed. So the result wasn't published, and the statistics tabs still show the nightly run's data. The run's result — 15 of 15 servers, 104 files, 122,032 records, 75.4 s. Unchecked numbers didn't reach the screens: they keep the data that added up.

Enlarge

• Check — the server name and twelve checks in a column.
• cl-01 — bounce breakdown by vMTA — 197 versus 195.
• Result — 15 of 15, 104 files, 122,032 records, 75.4 s — not published.

The tabs show the nightly run's data.

The “Worth knowing” block gathers the warnings and errors of recent runs in one place, so you don't have to read the whole console. Each entry names the server and gives the numbers. In the example there's one line here: the check didn't add up on cl-01 — “run not published, previous data is shown”. The overall run result doesn't go here, because it isn't an event. Look here after every run that finishes “with a warning”. Under the list is a reminder: an empty accounting file and a silent server are different things, and mixing them up is dangerous. The detailed course of the run is in the log console above.

Enlarge

• Didn't add up — cl-01 with the numbers — “run not published, previous data is shown”.
• Overall result — doesn't go here — it isn't an event.

An empty accounting file and a silent server are different things, and mixing them up is dangerous.