Demo
Demo

Knowledge base

PMTA knowledge base›Block <prometheus-listener>›Directive§ 3.3.25.1

time-first-attempt-domains-file

<prometheus-listener>

A file of receivers for which the metric is broken out separately
in the configuration this is a linetime-first-attempt-domains-fileinside the block <prometheus-listener>
Whom to count by name and whom in bulk

The pmta_smtp_first_attempt_seconds metric carries a receiver label, but not for everyone. The line sets a file with a list of names — one per line — and only they get their own label. The rest fall into other.

The limit is strict: a hundred names. This is not arbitrary — that is how metrics work: each new label value creates a separate series, and an unlimited list would turn one metric into thousands. The vendor chose a ceiling for you beyond which the explosion begins.

The line applies only with track-time-first-attempt enabled, and it lives in the <prometheus-listener> block — that is, it configures not the counting but its representation in the metric.

Without it the metric is not useless: it remains, just with the other label for all receivers. The overall delay is visible, the breakdown by receivers is not.

The main trap is thinking that receivers not on the list have dropped out of the metric. They are there, all together, under the other label. Which means the other value is a mixture, and it cannot be used to judge an individual receiver from the tail of the list.
What the Hub does. It does not write it: we do not configure the metrics listener.

If we do, the list is worth building from the fleet automatically — the receivers that account for the bulk of the traffic are known to us, and a hundred names cover everything worth analyzing by name with room to spare.

Recommended values

The list is short and meaningful, not complete:

What Note
format a text file, one name per line
ceiling a hundred unique names
the ones not listed get the other label, they do not disappear from the metric

The line is useless without track-time-first-attempt.

The hundred-name ceiling, the other label for the rest and the condition “only with counting enabled” come from the manual (§ 3.3.25.1). The explanation of why there is a ceiling at all is ours.
Example configuration
# by name — only the ones being analyzed; the rest go to other
track-time-first-attempt true

<prometheus-listener 0/0:9090>
    time-first-attempt-domains-file /etc/pmta/tfa-domains.txt</prometheus-listener>
The file has one receiver name per line. It is worth keeping the list short: a hundred names is a ceiling, not a target.
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▶

Putting the fleet's entire receiver list into the file

§ 3.3.25.1

What it costsBeyond a hundred names it will not work, and every name in the metric is a separate series. The metrics storage swells, while only a handful are analyzed anyway.
How to spot itThe file has hundreds of lines, the metric has a hundred labels and other.
How to do it rightKeep the ones that account for the bulk of the traffic and are actually analyzed.

Judging an individual receiver by the other value

our experience

What it costsIt is a mixture of everyone not on the list. Its value says nothing about a specific receiver.
How to spot itThe delay in other has grown, and which receiver is to blame is unknown.
How to do it rightAdd the suspects to the file and wait for new data.
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
time-first-attempt-domains-file <path>
Values
a path to a text file; one receiver name per line in it, no more than a hundred
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<prometheus-listener>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside <prometheus-listener>, and a node can have only one such block. So there is also only one receiver list for the metric per node.
⇄

Related directives

2 relations

Does not work without

track-outbound-perf-statsGlobalA neighboring value of the same listener — the sending delay, with no breakdown by receiver. § 3.3.1.44

Works together with

track-inbound-perf-statsGlobalA neighboring value of the same listener — the acceptance delay, with no breakdown by receiver. § 3.3.1.43

Referenced from

Exposing metrics to a collectorThe directive that enables this mechanism. § 11.22

How to check on the node
Look at the metric itself — the labels immediately show who made it into the list:
curl -s http://NODE:9090/metrics | grep pmta_smtp_first_attempt_seconds
Labels with receiver names mean the file was read. Only domain=”other” means the file is not set, not found, or counting is off.
◇

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.◇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.◇How an accounting record is structuredHow an accounting record is structured: the record type in the first column, then the fields, whose composition is configurable.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability · Collect telemetry