Plugin: go.d.plugin Module: powerdns_recursor
This collector monitors PowerDNS Recursor instances.
It collects metrics from the internal webserver.
Used endpoints:
This collector is supported on all platforms.
This collector supports collecting metrics from multiple instances of this integration, including remote instances.
This integration doesn’t support auto-detection.
The default configuration for this integration does not impose any limits on data collection.
The default configuration for this integration is not expected to impose a significant performance impact on the system.
You can configure the powerdns_recursor collector in two ways:
| Method | Best for | How to |
|---|---|---|
| UI | Fast setup without editing files | Go to Nodes → Configure this node → Collectors → Jobs, search for powerdns_recursor, then click + to add a job. |
| File | If you prefer configuring via file, or need to automate deployments (e.g., with Ansible) | Edit go.d/powerdns_recursor.conf and add a job. |
:::important
UI configuration requires paid Netdata Cloud plan.
:::
Follow webserver documentation.
Follow HTTP API documentation.
The following options can be defined globally: update_every, autodetection_retry.
| Group | Option | Description | Default | Required |
|---|---|---|---|---|
| Collection | update_every | Data collection interval (seconds). | 1 | no |
| autodetection_retry | Autodetection retry interval (seconds). Set 0 to disable. | 0 | no | |
| Target | url | Target endpoint URL. | http://127.0.0.1:8081 | yes |
| timeout | HTTP request timeout (seconds). | 1 | no | |
| HTTP Auth | username | Username for Basic HTTP authentication. | no | |
| password | Password for Basic HTTP authentication. | no | ||
| bearer_token_file | Path to a file containing a bearer token (used for Authorization: Bearer). |
no | ||
| TLS | tls_skip_verify | Skip TLS certificate and hostname verification (insecure). | no | no |
| tls_ca | Path to CA bundle used to validate the server certificate. | no | ||
| tls_cert | Path to client TLS certificate (for mTLS). | no | ||
| tls_key | Path to client TLS private key (for mTLS). | no | ||
| Proxy | proxy_url | HTTP proxy URL. | no | |
| proxy_username | Username for proxy Basic HTTP authentication. | no | ||
| proxy_password | Password for proxy Basic HTTP authentication. | no | ||
| Request | method | HTTP method to use. | GET | no |
| body | Request body (e.g., for POST/PUT). | no | ||
| headers | Additional HTTP headers (one per line as key: value). | no | ||
| not_follow_redirects | Do not follow HTTP redirects. | no | no | |
| force_http2 | Force HTTP/2 (including h2c over TCP). | no | no | |
| Virtual Node | vnode | Associates this data collection job with a Virtual Node. | no |
Configure the powerdns_recursor collector from the Netdata web interface:
The configuration file name for this integration is go.d/powerdns_recursor.conf.
The file format is YAML. Generally, the structure is:
update_every: 1
autodetection_retry: 0
jobs:
- name: some_name1
- name: some_name2
You can edit the configuration file using the edit-config script from the
Netdata config directory.
cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config go.d/powerdns_recursor.conf
An example configuration.
jobs:
- name: local
url: http://127.0.0.1:8081
Basic HTTP authentication.
jobs:
- name: local
url: http://127.0.0.1:8081
username: admin
password: password
Note: When you define multiple jobs, their names must be unique.
Local and remote instances.
jobs:
- name: local
url: http://127.0.0.1:8081
- name: remote
url: http://203.0.113.0:8081
Metrics grouped by scope.
The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels.
These metrics refer to the entire monitored application.
This scope has no labels.
Metrics:
| Metric | Dimensions | Unit |
|---|---|---|
| powerdns_recursor.questions_in | total, tcp, ipv6 | questions/s |
| powerdns_recursor.questions_out | udp, tcp, ipv6, throttled | questions/s |
| powerdns_recursor.answer_time | 0-1ms, 1-10ms, 10-100ms, 100-1000ms, slow | queries/s |
| powerdns_recursor.timeouts | total, ipv4, ipv6 | timeouts/s |
| powerdns_recursor.drops | over-capacity-drops, query-pipe-full-drops, too-old-drops, truncated-drops, empty-queries | drops/s |
| powerdns_recursor.cache_usage | cache-hits, cache-misses, packet-cache-hits, packet-cache-misses | events/s |
| powerdns_recursor.cache_size | cache, packet-cache, negative-cache | entries |
There are no alerts configured by default for this integration.
Important: Debug mode is not supported for data collection jobs created via the UI using the Dyncfg feature.
To troubleshoot issues with the powerdns_recursor collector, run the go.d.plugin with the debug option enabled. The output
should give you clues as to why the collector isn’t working.
Navigate to the plugins.d directory, usually at /usr/libexec/netdata/plugins.d/. If that’s not the case on
your system, open netdata.conf and look for the plugins setting under [directories].
cd /usr/libexec/netdata/plugins.d/
Switch to the netdata user.
sudo -u netdata -s
Run the go.d.plugin to debug the collector:
./go.d.plugin -d -m powerdns_recursor
To debug a specific job:
./go.d.plugin -d -m powerdns_recursor -j jobName
If you’re encountering problems with the powerdns_recursor collector, follow these steps to retrieve logs and identify potential issues:
Use the following command to view logs generated since the last Netdata service restart:
journalctl _SYSTEMD_INVOCATION_ID="$(systemctl show --value --property=InvocationID netdata)" --namespace=netdata --grep powerdns_recursor
Locate the collector log file, typically at /var/log/netdata/collector.log, and use grep to filter for collector’s name:
grep powerdns_recursor /var/log/netdata/collector.log
Note: This method shows logs from all restarts. Focus on the latest entries for troubleshooting current issues.
If your Netdata runs in a Docker container named “netdata” (replace if different), use this command:
docker logs netdata 2>&1 | grep powerdns_recursor
Want a personalised demo of Netdata for your use case?