Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.43

track-inbound-perf-stats

Global

Whether to measure the duration of an inbound SMTP conversation
in the configuration this is a linetrack-inbound-perf-stats falseinside the block Global
How long the node takes to accept a message

The line enables counting the duration of an inbound SMTP transaction — from the MAIL FROM command to the end of DATA. The default is false.

🔴 It is useful only together with <prometheus-listener>. The manual says so directly: the value goes nowhere except the pmta_smtp_request_duration_seconds metric. It is not in accounting, and not in the log either. Without the listener the line counts into the void.

The metric is a summary with quantiles 0.50, 0.90, 0.95 and 0.99, and the direction label tells acceptance from sending. This line opens the in half, the neighboring track-outbound-perf-stats the out half.

Why it is needed. Acceptance delay is an early sign of saturation: it grows before queues start to pile up and deliverability starts to fall. A submitting platform that “started sending slowly” often hits exactly this.

The main trap is enabling it without a metrics listener and waiting for data. The value will not appear anywhere: no column in accounting, no line in the log. There will be no error either — simply nothing will change.
What the Hub does. It does not write it and does not configure the metrics listener.

🔎 The schema has a place for it — the node_engines.metrics_port column — but nothing fills it. That is, the path was planned and not taken.

Our own telemetry answers other questions: accounting says what happened to a message, not how long the conversation took. Acceptance delay is a value we do not have at all right now.

Recommended values

Enabled only as a pair with the listener:

Value When
false (default) there is no metrics listener
true the listener is configured and acceptance delay is needed

The other half is track-outbound-perf-stats: they are usually enabled together, otherwise the metric will be one-sided.

The false default, the definition of a transaction (from MAIL FROM to the end of DATA) and the caveat “useful only with the metrics listener” come from the manual (§ 3.3.1.43, § 11.22). Reading the delay as an early sign of saturation is ours.
Example configuration
# both halves of the metric and the listener that serves them
track-inbound-perf-stats truetrack-outbound-perf-stats true

<prometheus-listener 0/0:9090>
</prometheus-listener>
Without the block below, both lines count into the void: the value goes only into the metric.
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▶

Enabling counting without configuring a metrics listener

§ 3.3.1.43

What it costsThe value goes nowhere: neither into accounting nor into the log. The line runs idle, and this can be understood only from the absence of data anywhere at all.
How to spot itThe line is enabled, and no new numbers have appeared anywhere.
How to do it rightAdd a <prometheus-listener> block — otherwise the line is useless.

Enabling only one half

our experience

What it costsThe metric becomes one-sided: acceptance delay is visible and delivery is not, or vice versa. Comparing them — which is exactly what answers the question “where is the bottleneck” — is impossible.
How to spot itThe metric has only one value of the direction label.
How to do it rightEnable both lines together.
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.
Reference data
Syntax
track-inbound-perf-stats <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.43
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line is written at the root of the file, in the Global section, and applies to all inbound transactions of the node. It has no split by source — the metric label distinguishes only the direction.
⇄

Related directives

2 relations

Does not work without

Serving node metrics in a standard formatThe only place this value goes to; without the block, counting goes into the void. § 3.3.1.43

Works together with

track-outbound-perf-statsGlobalThe other half of the same metric: one about acceptance, the other about sending. § 3.3.1.44

Referenced from

time-first-attempt-domains-file<prometheus-listener>A neighboring value of the same listener — the acceptance delay, with no breakdown by receiver. § 3.3.1.43

How to check on the node
Check it at the metrics listener — the value appears only there:
curl -s http://NODE:9090/metrics | grep pmta_smtp_request_duration_seconds
Lines with the direction=”in” label mean the counting works. Their absence with a configured listener means the line is not enabled.
◇

What else to read

3 articles

◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇Five ways for a queue to hand off a messageA queue does not have to use SMTP: it can write to a file, run a program, call over HTTP or discard.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Collect telemetry
Neighboring settings of the block Global:http-mgmt-porttrack-outbound-perf-statsdummy-smtp-update-statshttp-default-max-itemshttp-default-sort-orderAll 108 directives of the block →