3. But
• NSCA (Nagios Service Check Acceptor)
– Lots of limitations
•
•
•
•
63 char hostnames
127 char service names
No multiline
Result data limited too (512 bytes)
– In Opsview it was frustrating that “bigger”
(distributed) instalations got limited features
4. Looked at NSCA code…
• Problems didn’t seem fixable in a backwards
compatible manner.
– Reimplementation in a dynamic language seemed
easy (after all, just pushing results around a network)
• Is a dynamic language a problem?
– I Think not
• Performance
– Just do things right… Optimize later
• Flexibility
– Prototype new functionality
6. Code reuse
• Net::Server
– Process model
– Config file
• JSON::XS
– Fast (blazingly fast)
• Crypt::CBC
– Free Crypt::XXX functionality
• Digest::XXX
7. So what did I do?
Just play around with the components
Idea,Implement, abstract, implement, abstract, i
dea, abstract, implement…
Did I say that there is a test suite?
8. So what did I do?
Just play around with the components
Idea,Implement, test, break, implement, test, ab
stract, idea, abstract, implement, test, abstract
, test…
9. Flexibility in development
• Fast changes
– SSH tunnel tests show that client can think that a
packet was sent… but the server never recieves it
– commit packet implemented
• writers benefit from new “commit” functionality
11. Open up!
• googlecode project from the start
– Ton Voon (Opsview project starts testing NRD)
• Committing actively with really good results
–
–
–
–
NRD::Client
SSH tunnel testing
Documentation
Help with writing to resultdir
13. Results
(Based on sending 2016 results in a single transaction over an SSH
tunnel from a slave to a master. Times measured on the client.)
So in the end NRD is faster and less traffic consuming than NSCA