Cacti (home)ForumsDocumentation

dnsresponsetimeping

type:
userscript
userscript:
dnsresponsetimeping
author:
wayne_anderson
description:
Script and template to monitor and graph DNS server response latency.
version:
1.0.0
homepage:
http://www.wynwebtechnologies.com/
date:
2009-12-09
scripts:
dns,
latency,
dig,
Net::DNS

Download

This script (and the associated graphing template) can be downloaded here: dnsresponsetimeping-latest.tar.gz

Purpose

This script and associated template provides the basic framework for cacti to monitor the latency of DNS resolution requests. The script provided sends a single DNS request to a target DNS server looking for a specified host or domain. The time that this request takes to return is then recorded in RRA for analysis as a graph.

This script differs from previously provided options for cacti in that instead of looping for up to a minute to do repeated checks over a period of time and then recording more comprehensive statistics, this is a single resolution query check. This allows RRA and the associated graphing functionality to do the statistical analysis for you over time.

Further, this script also offers users the opportunity to use dig to make the DNS queries instead of the PERL Net DNS functionality.

The result is a fast script which can be used to monitor a wide variety of target DNS servers without unnecessarily slowing spine/poller cycles.

Features

  • Monitor point-in-time DNS Resolution Latency
  • Supports PERL Net-DNS
  • Supports command-line Dig
  • Highly commented and whitespaced for ease of modification

Prerequisites

Installation

Installing the script and template for cacti is very easy.

  • Download the tgz file, linked above, to your server.
  • Decompress the file to a local, easily-accessible directory.
  • Copy the perl script to wherever your cacti scripts are stored. As an example, on Fedora 10, that location is /usr/share/cacti/scripts
  • Make sure the XML file is accessible to you wherever you browse to your cacti front end. If that is not your server, you will need to open the tgz file on your desktop and extract the .xml file from the archive.
  • Navigate to your cacti console, choose “import templates” on the left side.
  • Click the browse button and select the XML file that you extracted from the compressed file. This should be named similar to cacti_graph_template_dns_resolution.xml
  • Click the “Save” button.

Usage

Within Cacti


Once the script and template are installed, you are strongly encouraged to verify the implemented templates and also to make modifications to suit your needs.

Confirming Configuration

To examine the data acquisition side of using this script, from the console menu, choose “Data Input Methods”. Choose “DNS Resolver” from the list of scripts. The key item to examine here is the “Input String” which is actually the command that is executed to return the input to cacti. Key changes you may wish to make is removing the '-d' argument from the command line if it is present, which will no longer use dig, or to change the integer value after the '-t' argument which specifies the time to wait for a DNS resolution timeout, in seconds.

Another value most installations may consider changing is the host to be resolved at the target DNS server. In my case, I have chosen 'www.wynweb.net' as that is a domain that I own and control and hence can reliably predict its existence and continued performance for this script. You may change it to any Fully Qualified Domain Name which can be resolved by the DNS servers you intend to target.

Next, verify the graph configuration. From the left side, choose “Graph Templates”. From the list, choose “DNS Resolution”. The key values you may want to consider changing here are the Height and Width of the graph that is generated to conform to the display of the remainder of your cacti installation. Another value to consider for UI conformity is the color of the graph body, which is set to a bright green by default. To change the color, click on “Item #1” and then select the appropriate color from the drop down list and choose the “save” button to continue.

Adding a DNS Resolution Target

To actually use the script, there are a few key steps as with almost any data point in cacti.

  1. Add a device for the DNS resolution target. In most cases, the host template will be none. If possible, with DNS servers you should use an IP address in many instances for the 'hostname' rather than the FQDN unless you are targetting a server which changes often or will change soon.
  2. Add a data source. Select DNS resolution as the selected data template. Select the newly created device as the host. Click save and then save again.
  3. Add a graph. Under graph management, choose add. Select DNS resolution as the graph template, and the host that you created during your add device. Click create. Now choose the DNS resolution data source by selecting the “DNS resolution” from the drop down list. Click save.
  4. Add your graph to one of your graph trees if you are not using host based graph trees.

As a Script


As the script which makes the resolution request is simply a command line perl script, it may also be used independently from cacti, particularly if you are troubleshooting cacti integration.

perl dnsResponseTimePing.pl -h host -s server [-r] [-v] [-d] [-t timeout]

perl dnsResponseTimePing.pl -h www.icrc.org -s 129.132.98.12 -r -v -d -t 5

There are 6 key command line arguments which are expected at the command line.

  • h - REQUIRED - The hostname to be resolved in DNS.
  • s - REQUIRED - The server (FQDN or preferably IP) of the DNS server to measure resolution latency.
  • r - Optional - An argument with no attributes whose presence indicates to make the request recursive.
  • v - Optional - An argument with no attributes whose presence indicates to be verbose.
  • d - Optional - An argument with no attributes whose presence indicates to use dig.
  • t - Optional - The number of seconds to wait for a DNS query to timeout.
The Recursion Flag

In DNS, many name resolution records point to other places before they ultimately end in a “true” record for address of a name. For example, something may be called www.something.com and there is another record called something.com. That record about “www” sometimes does not have an IP address and instead points to “something.com” which does. This is VERY common in web hosting operations where there are many systems hosted on the same physical systems.

Setting the recursion flag tells the script to allow the DNS query to follow those pointers until it gets to a record which returns an IP address. This recursion is not done by the script, it is done by the DNS resolution piece. If you do not set recursion and the name that you are looking for is not an “A” record (the type of record that has an IP address), it may return an error.

The recursion flag is off by default if you do not specify it on the command line.

This choice is made because in some cases, recursion may add a few small bits of time to follow that “pointer” to figure out what the IP address is for the record. Administrators implementing this script should be aware that either they are pointing to a true A record or that they are consciously accepting the small time penalty that may result from measuring the round trip of a CNAME record resolution with recursion.

Verbosity

The verbose flag is off by default if it is not specified on the command line. It is STRONGLY recommended that you DO NOT set the verbose flag in your cacti configuration for this data input script as verbosity results in text error messages being output instead of an expected value.

An error in the script will result in an output of 0 in normal conditions. With the verbose flag on, a text error will be appended that lets you know what the error was. If you see a string of 0 latency for a DNS resolver, it would then be recommended that you run the script on the command line to troubleshoot with the verbose flag on.

Additional Help?

Possible Bugs?

  • Zero input validation is done on the values you provide. As the administrator of cacti, the script trusts that you are not providing a malicious configuration.
  • Script does not look to see if dig exists before executing against it if you have set the -d flag. -d explicitly says to use dig. The script trusts that the cacti administrator understands whether dig is available or not.
  • Very little validation testing of this script done on windows. It is strongly advised that you test the script before planning to depend on it.

Sample Output






Personal Tools