Monitor one or more ISC Bind servers.
Example Netdata charts
Depending on the number of views your bind has, you may get a large number of charts. Here this is with just one view:
How it works
The plugin will execute (from within node.js) the equivalent of:
Here is a sample of the output this command produces.
From this output it collects:
- Global Received Requests by IP version (IPv4, IPv6)
- Global Successful Queries
- Current Recursive Clients
- Global Queries by IP Protocol (TCP, UDP)
- Global Queries Analysis
- Global Received Updates
- Global Query Failures
- Global Query Failures Analysis
- Other Global Server Statistics
- Global Incoming Requests by OpCode
- Global Incoming Requests by Query Type
- Global Socket Statistics (will only work if the url is
http://127.0.0.1:8888/json/v1, i.e. without
/server, but keep in mind this produces a very long output and probably will account for 0.5% CPU overhead alone, per bind server added)
- Per View Statistics (the following set will be added for each bind view):
- View, Resolver Active Queries
- View, Resolver Statistics
- View, Resolver Round Trip Timings
- View, Requests by Query Type
The collector (optionally) reads a configuration file named
/etc/netdata/node.d/named.conf, with the following contents:
You can add any number of bind servers.
If the configuration file is missing, or the key
true, the collector will also attempt to fetch
http://localhost:8888/json/v1/server which, if successful will be added too.
XML instead of JSON, from bind
The collector can also accept bind URLs that return XML output. This might required if you cannot have bind 9.10+ with JSON but you have an version of bind that supports XML statistics v3. Check this for versions supported.
In such cases, use a URL like this:
v3 has been tested.
- which is then transformed to emulate the output of the JSON output of bind (CPU intensive - and yes the converted JSON from XML is different to the native JSON - even bind produces different names for various attributes),
- which is then processed to generate the data for the charts (this will happen even if bind is producing JSON).
In general, expect XML parsing to be 2 to 3 times more CPU intensive than JSON.
So, if you can use the JSON output of bind, prefer it over XML. Keep also in mind that even bind will use more CPU when generating XML instead of JSON.
The XML interface of bind is not autodetected.
You will have to provide the config file
/etc/netdata/node.d/named.conf, like this:
Of course, you can monitor more than one bind servers. Each one can be configured with either JSON or XML output.
Auto-detection is controlled by
enable_autodetect in the config file. The default is enabled, so that if the collector can connect to
http://localhost:8888/json/v1/server to receive bind statistics, it will automatically enable it.
Bind (named) configuration
To use this plugin, you have to have bind v9.10+ properly compiled to provide statistics in
Normally, you will need something like this in your
(use the IPv4 or IPv6 line depending on what you are using, you can also use both)
Verify it works by running the following command (the collector is written in node.js and will query your bind server directly, but if this command works, the collector should be able to work too):