Demo
Demo

Knowledge base

PMTA knowledge base›Monitor screen§ 11.1.7

Service summary

Summary Report Display
One of the four Signals reports

The SparkPost Signals summary report: sending metrics for a selected period grouped by recipient domain, sending domain — part of the Sender or From header — campaign (this is the job identifier), sending address and address pool.

The report lives in the SparkPost application, not in the node’s monitor: the node only sends accounting data there and reads nothing back. Access to the report is through a SparkPost account, not http-access.

It overlaps with our analytics: the breakdowns are the same. The service’s own health score lives not here but in the Signals overview.

Data arrives with a delay: the service needs several thousand messages and batch processing, so on first connection the report may fill in only after a day.

The main trap is expecting a message-for-message match with node accounting. The service counts by its own rules and with a processing delay, and records the size of messages larger than 2.1 GB truncated — the average delivery size in the summary will diverge from accounting.
What the Hub does. It does not use it: the Hub does not write a <signals> block, and no data goes from the nodes to SparkPost. The Hub builds its own breakdowns by receiver and sending address from the accounting the nodes send it via the webhook.
Recommended values

Where to look for what:

Question Where
sending metrics broken down by the service here
bounces by SparkPost’s classification the Signals bounce report
health score and spam traps the Signals overview
exact node numbers node accounting
The report’s groupings, one-way data sending, the processing delay and truncation of large messages come from the manual (§ 11.1, § 11.1.7). The split of questions is ours.
Example configuration
# without a signals block no data goes to the service and the report is empty
<signals>
    api-key 0123456789abcdef012345678901234567890123</signals>
The key is 40 hexadecimal characters issued by SparkPost; without the api-key line the engine with a <signals> block will not start.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
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.
⇄

Related entries

1 relation

Where you can see it

The vendor's analytics — and what leaves the node for itThe mechanism that is visible here. § 11.1.7

How to check on the node
Check whether data goes to the service at all:
grep -n -A3 '<signals>' /etc/pmta/config
grep -n 'enable-signals' /etc/pmta/config
No block means no report. enable-signals false on an address or pool turns off data sending only for them.
◇

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 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.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.

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