I just released version 0.5 of Ruby PDNS. This mainly introduces a full statistics capability and fixes a minor bug or two.
I didn’t intend on releasing another version before 1.0 but it turns out the stats feature were quite a big job worthy of a release.
The stats is complicated by the fact that PDNS runs multiple instances of my code sharing the load between them, this makes keeping stats pretty hard because I have no shared memory space like you would in a multi threaded app. So I’d somehow need to dump per process stats and calculate totals. Everyone I asked suggested writing a log and summarizing the log data but this just never felt right to me – there would be issues with log rotation and knowing till when you last counted stats and so forth – so I kept looking for a solution.
I struggled to come up with a good approach for a long time, finally settling on each process writing a YAML file with it’s stats and a cron job to aggregate it regularly. This turned out to be quite elegant – much more so than processing logs for example – as the cron job cleans up files it already processed and also ignore too old ones etc. If the cron job keeps running it should be zero maintenance.
I added a script – pdns-get-stats.rb – to query the aggregated stats:
$ pdns-get-stats.rb –usec –record puppet
usagecount:896 totaltime:165844 averagetime:185$ pdns-get-stats.rb –usec –record ruby-pdns-totals
usagecount:68705 totaltime:11056529 averagetime:160
The puppet record is using GeoIP so you’d expect it to be a bit slower than ones that just shuffle records and this is clear above, though I am quite pleased with the performance of the GeoIP code. Times are in microseconds.
Those who know Cacti will recognise the format as being compatible with the Cacti plugin standard – if there is demand I can easily add Munin, Collectd etc query tools
Using the details I was able to draw a quick little graph below using Cacti
The release is available in RPM, tgz and gem at the project site.
The next major step is to write a API that is externally accessible, perhaps using REST over HTTP, this means you could send data from your monitoring or CMDB and adjust weights or really anything you can code using external data.
