Operations¶

Service control¶

The RPM ships a systemd unit named pdns-pf-settingssyncer.service, running as the pdns-settingssyncer user. Everyday commands:

# Status and recent logs
systemctl status pdns-pf-settingssyncer

# Follow the log stream
journalctl -u pdns-pf-settingssyncer -f

# Restart after a config change
systemctl reload-or-restart pdns-pf-settingssyncer

The service does not watch its config file for changes; restart it after editing settingssyncer.yaml.

On restart the service re-subscribes and performs a full bulk load from each configured Redis server before processing incremental updates again.

Config location¶

The default config path is /etc/pdns-pf/settingssyncer.yaml. A commented template with every option is shipped alongside it as /etc/pdns-pf/settingssyncer.example.yaml. See Configuration for the full reference.

If the file is absent, the service looks for it at /etc/pdns-pf/settingssyncer.yaml automatically; pass --config to override.

Command-line flags¶

Flag	Default	Purpose
`--config`, `-C`	(auto-discovered)	Path to the YAML config file.
`--debug`	`false`	Force log level to `debug`, overriding the config.

Observability¶

All live-inspection surfaces are served by the HTTP server bound to http.address (see Configuration → http).

Status page. A simple HTML page at / with a link to the metrics endpoint.
Prometheus metrics. Scraped at /metrics.

Metrics reference¶

Bulk load metrics¶

Metric	Type	Description
`settings_syncer_bulk_started_time_seconds`	gauge	Unix timestamp when the last bulk load started. Labels: `server`.
`settings_syncer_bulk_in_progress`	gauge	`1` while a bulk load is running, `0` otherwise. Labels: `server`.
`settings_syncer_bulk_count`	counter	Total bulk load completions by outcome. Labels: `server`, `status` (`success` or `error`).
`settings_syncer_bulk_duration_seconds`	histogram	Duration of each bulk load in seconds. Labels: `server`, `status`.
`settings_syncer_bulk_last_count`	gauge	Number of entries written in the most recent bulk load. Labels: `server`, `db`, `region`.
`settings_syncer_bulk_errors`	counter	Number of bulk load errors, labelled by error text. Labels: `server`, `error`.

Incremental (pubsub) metrics¶

Metric	Type	Description
`settings_syncer_incr_recv_count_total`	counter	Total pubsub messages received, including the timestamp channel. Labels: `server`.
`settings_syncer_incr_updates_count_total`	counter	Total pubsub messages received, excluding the timestamp channel. Labels: `server`.
`settings_syncer_incr_updates_count`	counter	Pubsub messages received per channel. Labels: `server`, `db`.
`settings_syncer_incr_latency_msec`	gauge	Subscription latency in milliseconds, measured from the timestamp published in the `timestamp` channel to local receive time. Labels: `server`.
`settings_syncer_incr_latency_excessive_count`	counter	Number of timestamp messages processed with excessive latency (above 3000 ms). Labels: `server`.
`settings_syncer_incr_errors`	counter	Number of pubsub errors. Labels: `server`, `error`.

Using the metrics¶

Is the bulk load completing? Check settings_syncer_bulk_count{status="success"} — it increments on each successful load. settings_syncer_bulk_in_progress stays at 1 for the duration; a long-running bulk load indicates a large dataset or slow Redis.

Is the subscription keeping up? Watch settings_syncer_incr_latency_msec. Values consistently above a few hundred milliseconds mean the subscriber is falling behind the publisher. settings_syncer_incr_latency_excessive_count counts messages that arrived more than 3 seconds late.

How many entries were synced? settings_syncer_bulk_last_count breaks down the entry count by server, database, and region after each bulk load.

Performance notes¶

scan_count¶

scan_count controls how many entries the syncer fetches per HSCAN/ZSCAN round-trip during bulk load. The default (1000000) is chosen for production datasets so a bulk load with millions of entries does not spend most of its time on Redis round-trips. Lower it only if Redis reply size, memory pressure, or network characteristics make the large scan batches a bottleneck.

batch_size¶

batch_size controls how many LMDB writes are grouped into a single transaction. Larger batches improve write throughput for bursts. The worker does not wait for a full batch, so quiet traffic is still committed promptly. The default (10000) is suitable for production while keeping individual transactions bounded.