Boundary: Follow the network flows Boundary is a monitoring tool based on the idea that sometimes you don't need to capture so much information. In the United States, for instance, the police need to convince a judge to issue a warrant before they can eavesdrop on a phone conversation, but they don't need one to get a list of the phone numbers a person called. While the list of numbers sounds boring, it can be surprisingly revealing despite not holding any information about the content of the calls. The list is simple, efficient, and free of all the small talk and gossip that fill up real phone coversations.
Boundary takes a similar approach to monitoring your server stack. While Circonus and Librato Silverline will poke and prod, looking for information about the OS and its applications, Boundary installs itself in the networking corner of the OS and quietly keeps track of all of the traffic between all of the machines. These flows are distilled into a concise illustration that explains where the data is going and who is doing the talking.
It's not exactly true that Boundary works like the "pen recorders," the name the police gave to the machines they used to capture the numbers dialed on phones. Boundary will also dig into the header of each packet and classify it according to the type of traffic. It's not doing deep packet inspection, so it won't tell you what lies beyond the header, but it can tell you something about the packet type and size.
This is surprisingly useful. One of Boundary's smarter features lets you group your machines into tiers. Boundary automatically starts watching the traffic between the groups, which lets you isolate the performance. Is there an abnormally large amount of traffic going to the database? Perhaps some of the queries are misfiring.
You end up with a general feel for the Web stack -- a pulse, you might call it. The graphs of traffic start falling into a pattern that indicates everything is healthy. Boundary also lets you write rules that will trigger alerts, but I'm not so sure this is an easy thing to do. It's much easier to write a simple rule for trouble when you are looking at the content of the packets and noticing that a database query is returning no lines when it should be finding a pile of information. It's bound to be harder when you're working with just some basic information about the flow.
There are other advantages to just skimming. Packet headers don't hold personal information about you or your customers, so it's safer to export to a distant Web service owned by a third party.