Monitoring any amount of servers (anything greater than one) quickly becomes a task that literally sucks the joy and happiness out of your daily existence. You spend hours reading the novels worth of syslog config files and spend afternoons staring at nagios readings rendered at such a terrible resolutions that they’d be perfectly at home on a the display of an oscilloscope.
For these reasons, we’ve made it a core mission to build out our own monitoring tools to provide clean, live, and low SNR readings from our machines. We wanted to be able to, at a glance, gauge the health of our service and if there was ever a problem, quickly identify where that problem was originating from.
Also, we were excited to have something fancy running on our rarely used TV screens.
Our monitoring system (which will become its own blog post at a later time) is made possible by the nifty tool out of Mountain View known as Protocol Buffers. To quote the big G:
“Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler.”
Protocol Buffers provided us with a way to efficiently stream reports from our machines or instantly send commands back to them (encrypted, also another blog post) without having to SSH into the box or setup a bizarre concoction of monitoring tools. With protocol buffers, we simply define a .proto file with our desired message format, and then the protoc compiler generates the includes (for C++, in our case) which build an API that allows the specific message to be crafted.
The .proto format is very straightforward and easy to understand. Here’s an example:
Reading a Message
- The package declaration ‘tutorial’: This creates the namespace in C++ for your generated classes.
- A message definition ‘Hello’: the message definition contains many simple data types that define the message you are trying to craft including but not limited to bool, int32, float, double, and string.
- ‘=1’ and ‘=2’: These are unique tags that identify the unique tag that field is going to use in the binary encoding. Numbers 1 – 15 require one less byte to encode then higher numbers.
- ‘required’, ‘optional’, and ‘repeated’ modifier: Defined:
- Required: A value for this field must be provided when encoding the message.
- Optional: This field may not be set.
- Repeated: The field may be repeated any number of times.
*Keep in mind changing the ‘required’ fields will necessitate a recompile.
Compiling Protocol Buffers:
This will create two files in your specified directory:
This ends up creating an API for filling your message values:
Writing a Message
Voila! You now have rudimentary messaging format.
For better and much more detailed references, head on over to: https://code.google.com/p/protobuf/downloads/list and download the source.
About the Author
Engin Akyol, our Co-Founder and CTO, came to Distil Networks from Cisco systems where he had five years of experience providing networking and network testing consulting for core enterprise customers as part of Cisco’s ECATS group. Engin’s responsibilities included creating and executing test plan’s based on customers’ requirements, interacting with developers to provide quick resolution to issues, and providing recommendations for deploying new networking equipment and software.More Content by Engin Akyol