Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 1.4

What the node tells about itself and through which channels

critical

monitoring and management tools
A map of what you can ask the node

This is the list of everything the node can tell about, and choosing between these channels is half the design of any fleet observation system.

Each surface answers its own question at its own price:

Surface Answers the question Price
web monitor what is happening now polling, a management key
console (text, XML, JSON, DOM) the same, but from a script access to the machine
log what the node did and why something failed disk space
accounting what happened to the messages, fully space, a delay until the file is closed
accounting search find a message in what has accumulated CSV format only
metrics summary numbers in someone else’s format a port, nothing more
external analytics how messages were received on the other side data goes outside

Three questions — three different kinds of answer, and a fleet needs all three: “now” (monitor, console, metrics), “what happened” (accounting, log), “how it was received” (external analytics, complaints).

Log verbosity is configured per receiver, not only for the whole node. It is an important detail: raising verbosity for the one receiver under investigation costs almost nothing, while raising it for the whole node is the usual way to fill up the disk.

The console returns four formats, including JSON — that is, machine reading is possible without parsing screen output.

The main trap is building observation on a single surface. The monitor does not remember the past, accounting does not show the present, metrics do not know individual messages, and the log does not know their fate. Each of them on its own answers “I don’t know” to two thirds of the questions.
What the Hub does. It uses three of the seven, each differently.

Accounting — via the webhook; it is the source of all fleet analytics. The monitor — by polling once a minute; it is the current state and commands. The log — by hand, during investigations, over SSH.

We do not use: metrics (there is a place in the schema — metrics_port — but it is not filled in), accounting search, external analytics.

🔎 The fleet dashboard’s breakdown — queues, sending addresses, jobs, last error per receiver — matched what the vendor’s monitor shows. We arrived at it independently; worth knowing when comparing capabilities.

Recommended values

The mechanism has no values of its own — each surface is enabled by its own:

Surface Enabled by
web monitor http-mgmt-port and http-access
log log-file and the log-* switches
accounting an <acct-file> block
metrics a <prometheus-listener> block
The list of surfaces, the console’s four output formats, both accounting formats and per-receiver log verbosity come from the manual (§ 1.4). The split into three kinds of questions and the analysis of our choice are ours.
Example configuration
# three surfaces the fleet uses
http-mgmt-port 1000              # what is happening nowlog-file /var/log/pmta/log       # what the node did

<acct-file /var/log/pmta/webhook.json>
    records d, b, rb, t, feedback-loop
    http-webhook-url https://hub.example.com/api/telemetry/pmta/7
</acct-file>                     # what happened to the messages
The fourth surface — metrics — is added with one block and does not require any of our secrets.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Building observation on the monitor alone

our experience

What it costsThe monitor shows the present and does not remember the past. Any question like “what happened yesterday” stays unanswered, and there is nothing to reconstruct it from.
How to spot itAn incident investigation runs into the lack of history.
How to do it rightSet up accounting in advance: it is the node’s memory.

Raising log verbosity for the whole node

§ 1.4

What it costsVerbosity is configured per receiver, and there is usually only one under investigation. Raising it globally multiplies the volume by the number of receivers and fills up the disk.
How to spot itThe log grew in a jump after a configuration edit.
How to do it rightEnable verbosity in the block of the receiver or source under investigation.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Inheritance
The mechanism has no inheritance — the directives that enable each surface are inherited. The only one of them configurable per receiver is log verbosity; the rest are set per node.
⇄

Related entries

8 relations

Works together with

The vendor's analytics — and what leaves the node for itThe seventh surface and the only one that sends data outside: how messages were received on the other side. § 1.4Figure out why a queue to one receiver is growingInvestigating a single receiver is exactly choosing between these surfaces in order. § 4.1.1

Applies to

Accept, route, deliverWhat is being observed: a message’s path through the node from receipt to delivery. § 1.4

Where you can see it

Node statusThe monitor page that answers the question “what is happening now.” § 1.4Queue state together with event historyThe same question from the console — and in machine formats, not just on screen. § 1.4Delivered — the record everything is counted byThe accounting record the answer to “what happened to the message” is made of. § 1.4A summary of the accounting filesThe statistics application: one more reader of the same accounting. § 1.4Search through accounting filesSearch through accumulated accounting — it works only with the CSV form. § 1.4

Referenced from

How a message gets into the engineWhere to see which door messages actually come through. inferenceThe watchdog that restarts the engineThe watchdog’s email is the only surface where a crash with an automatic restart is visible. inferencetrack-time-first-attemptGlobalThe value appears on two surfaces at once: in accounting and in metrics. § 1.4The telemetry contractOne of the three observation surfaces of a node — the one history comes from, rather than current state. § 1.4Monitor response formatsA related mechanism: they work together. § 4.1.1Command output formatsA related mechanism: they work together. § 4.1.1

How to check on the node
There is one check for all surfaces: see what responds at all:
ss -lntp | grep -E ':(1000|9090)'
The management interface port and the metrics port are two of the seven surfaces. The rest are checked by their files: the log and accounting must grow, each in its own way.
◇

What else to read

3 articles

◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇The telemetry contractOne block describes the accounting output in full: which record types, which fields, where they go, how files rotate and what gets anonymized.◇The log and accounting — two files and two different questionsThe engine keeps a separate log and a separate accounting file; the separation is made for the sake of format, performance and the ability to hand over the log without disclosing data.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability · Untangle a stuck queue · Collect telemetry
Priority
critical