BIND 9 Statistics for Cacti

[Rossco]

Hi Chris

Can I ask roughly how many domains are you graphing? Also, are you using the original one, or the one I modified to be persistent?

Have you tried walking the snmp oids using snmpwalk etc to make sure the script is still responding correctly?

Cheers

Rossco

[chris.rolves]

I downloaded the script that is at the first post of this thread. Also Yes I have done an SNMP walk on the server to make sure the script is working and it works great. as far as how many domains we are hosting i believe its somewhere between 150 and 200.

[Rossco]

Hi

Odd, the only thing I could suggest is that you have so many domains the snmp polling never finishes correctly within the polling cycle. This was the eventual problem I had (circa 600 domains). I modified the original script slightly to be persistent. Otherwise you end up invoking the perl interpreter for every domain query you do e.g. for you 100-150 times - this could well explain your load issues.

The modified script is posted by me somewhere above in the thread. The only other suggestion I could give is wireshark/tcpdumping the queries looking for obvious issues.

Cheers

Rossco

[chris.rolves]

Ok, I used that and now if i do an snmpwalk on .1.3.6.1.4.1.2021.55 it fails but if i remove the .55 from the equation it works on snmpwalk so should i not worry about the .55 or is that needed for all this?

[Rossco]

Sorry, I dont seem to get that problem on mine - a snmpwalk starting from .1.3.6.1.4.1.2021.55 works fine for me?

Is your graphing working again?

Rossco

[chris.rolves]

wow I am such a n00b lol, i found my issue with the .55 not working. I had forgot to point the the proper location of my named.stats file for the perl script.

[chris.rolves]

And I must say, running the new script with pass_persist in the snmpd.conf has really lessened the cpu times on the DNS server.

[Rossco]

Glad to hear it.

I was giving myself a headache by generating more monitoring load than DNS load until I got pass_persist working

Hats off to the original script writer though.

Cheers

Rossco.

[chris.rolves]

hmmm, I still seem to be having trouble with the graphs gapping out but this time only for the DNS graphs not all of Cacti. The graphs almost look like its only getting info every 5 minutes and then there is a couple minutes of gap

[Rossco]

Odd - is you cron job set for every 5 mins on the name server?

Also, what cacti version are you running / are you running boost? / is this a new setup? You could do a tcpdump to confirm if you are getting back the replies with data when you get your gaps, which would narrow it down to snmp script on the server or internal cacti issues.

[greginmadison]

I read every post in this thread about why I am getting the following error when I manually do a snmp get from my cacti box:

nwlmad0p0080:/srv/www/htdocs/cacti/resource/snmp_queries # snmpget -v1 -c xxxx xxxx .1.3.6.1.4.1.2021.55
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: UCD-SNMP-MIB::ucdavis.55

nwlmad0p0080:/srv/www/htdocs/cacti/resource/snmp_queries # snmpwalk -v2c -c xxx xxx .1.3.6.1.4.1.2021.55
UCD-SNMP-MIB::ucdavis.55 = No Such Instance currently exists at this OID\

Here is a tcpdump of the cacti server talking to the dns server when I click on the green circle when attempting to add graphs on the device:

cactiserver.36260 > dns-server.161: [udp sum ok] { SNMPv1 C=xxx { GetNextRequest(29) R=1961571406 .1.3.6.1.4.1.2021.55.1 } }
dns-server.161 > cactiserver.36260: [udp sum ok] { SNMPv1 C=xxx { GetResponse(31) R=1961571406 .1.3.6.1.4.1.2021.100.1.0=1 } }
cactiserver.36260 > dns-server.161: [udp sum ok] { SNMPv1 C=xxx { GetRequest(28) R=1961571407 .1.3.6.1.2.1.1.3.0 } }
dns-server.161 > cactiserver.36260: [udp sum ok] { SNMPv1 C=xxx { GetResponse(32) R=1961571407 .1.3.6.1.2.1.1.3.0=17025554 } }
cactiserver.36260 > dns-server.161: [udp sum ok] { SNMPv1 C=xxx { GetNextRequest(21) R=1961571408 .0.1 } }
dns-server.161 > cactiserver.36260: { SNMPv1 C=xxx { GetResponse(102) R=1961571408 .1.3.6.1.2.1.1.1.0=[|snmp] } }

This seems to indicate that I am requesting the correct OID, but not getting anything back. Running some debug statements in bind9-stats-snmpd.pl shows that the perl script is executing on the DNS server using the snmpd pass statement, giving me back info on 1.3.6.1.4.1.2021.100.1.0 ????????????????????????

I know the perl script bind9-stats-snmpd.pl is executing because I added some debug lines that opened of file in /var/log/junk.txt and print some info. When I execute a snmpwalk from my cacti box, the /var/log/junk.txt file is created and my print commands show up.

EDIT: This was a file permission problem because of a NFS mount. Moved the file STAT_FILE=/var/cache/bind/named.stats to somewhere else and it works.

[Threepwood]

Hi everybody !. New in the forum. I spent many hours trying to make snmpwalk work. The script was just running fine, but then when I had to add the following line to my snmpd :

pass .1.3.6.1.4.1.2021.55 /usr/bin/perl /usr/local/bin/bind9-stats-snmpd.pl

Running snmpwalk from other host and from localhost did not work, there were just no return of data, all empy.
So as I see that the script was running fine I though that it may be something wrong in the snmpd.conf, searching and reading finally I got something to try. I replaced the pass definition with exec :

exec .1.3.6.1.4.1.2021.55 /usr/bin/perl /usr/local/bin/bind9-stats-snmpd.pl

I'm posting this because the README says to add the pass statement to snmpd, so maybe someone is wasting time as I did.
Is this OK ?. Has anybody got the same problem ?. After this I got data, so it remains to try it on CACTI.

Greetings,
Lucas.

[dexter001]

ok .. I'm trying to run it on localhost, my named server is set up and running, but the script doesn't seem to work ..

[root@d3xt3r01 scripts]# ./bind9-stats.pl index
GLOBAL
[root@d3xt3r01 scripts]# ./bind9-stats.pl getall GLOBAL
[root@d3xt3r01 scripts]#


named_stats content ...
+++ Statistics Dump +++ (1212095402)
++ Incoming Requests ++
42 QUERY
++ Incoming Queries ++
41 A
1 AAAA
++ Outgoing Queries ++
[View: default]
36 A
1 NS
17 AAAA
[View: _bind]
++ Name Server Statistics ++
42 IPv4 requests received
3 requests with EDNS(0) received
42 responses sent
3 responses with EDNS(0) sent
41 queries resulted in successful answer
6 queries resulted in authoritative answer
36 queries resulted in non authoritative answer
1 queries resulted in nxrrset
24 queries caused recursion
++ Zone Maintenance Statistics ++
++ Resolver Statistics ++
[Common]
[View: default]
44 IPv4 queries sent
10 IPv6 queries sent
44 IPv4 responses received
12 query retries
5 IPv4 NS address fetches
5 IPv6 NS address fetches
5 IPv6 NS address fetch failed
[View: _bind]
++ Cache DB RRsets ++
[View: default]
36 A
8 NS
1 CNAME
8 AAAA
2 !AAAA
[View: _bind]
++ Per Zone Query Statistics ++
[d3xt3r01.tk]
4 queries resulted in successful answer
5 queries resulted in authoritative answer
1 queries resulted in nxrrset
[dorene.ro]
1 queries resulted in successful answer
1 queries resulted in authoritative answer
[localhost.localdomain]
[localhost]
[1.0.0.127.in-addr.arpa]
[0.in-addr.arpa]
[127.IN-ADDR.ARPA]
[254.169.IN-ADDR.ARPA]
[2.0.192.IN-ADDR.ARPA]
[255.255.255.255.IN-ADDR.ARPA]
[0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA]
[1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA]
[D.F.IP6.ARPA]
[8.E.F.IP6.ARPA]
[9.E.F.IP6.ARPA]
[A.E.F.IP6.ARPA]
[B.E.F.IP6.ARPA]
[version.bind (view: _bind)]
[hostname.bind (view: _bind)]
[authors.bind (view: _bind)]
[id.server (view: _bind)]
--- Statistics Dump --- (1212095402)

[oldsk8trbabe]

Had to upgrade due to the latest vulnerability. Now the new statistics file is different so the Cacti script is no longer graphing. Can the script be reworked so we can gather stats with the latest versions of BIND?

new stats output:
+++ Statistics Dump +++ (1215631501)
++ Incoming Requests ++
390 QUERY
++ Incoming Queries ++
200 A
32 PTR
71 MX
10 TXT
67 AAAA
1 A6
1 SPF
8 ANY
++ Outgoing Queries ++
[View: default]
17 A
1 NS
1 MX
24 AAAA
[View: _bind]
++ Name Server Statistics ++
390 IPv4 requests received
94 requests with EDNS(0) received
390 responses sent
94 responses with EDNS(0) sent
292 queries resulted in successful answer
340 queries resulted in authoritative answer
50 queries resulted in non authoritative answer
72 queries resulted in nxrrset
26 queries resulted in NXDOMAIN
7 queries caused recursion
++ Zone Maintenance Statistics ++
993 IPv4 notifies sent
272 IPv4 SOA queries sent
7 IPv4 IXFR requested
7 transfer requests succeeded
++ Resolver Statistics ++
[Common]
[View: default]
41 IPv4 queries sent
2 IPv6 queries sent
40 IPv4 responses received
3 query retries
8 IPv4 NS address fetches
9 IPv6 NS address fetches
7 IPv6 NS address fetch failed
[View: _bind]
++ Cache DB RRsets ++
[View: default]
53 A
9 NS
1 MX
8 AAAA
9 !AAAA
[View: _bind]
++ Per Zone Query Statistics ++
--- Statistics Dump --- (1215631501)


Old stats output:
+++ Statistics Dump +++ (1215630901)
success 274943762
referral 3806452
nxrrset 31625903
nxdomain 137763922
recursion 173131598
failure 27469127
--- Statistics Dump --- (1215630901)

Thanks,
Robin

[gagadget]

Seems that BIND 9.4 is using the same stats format than BIND 9.5