Like it or not, in recent years network engineers have come to know more about application monitoring tools than they might like. Apps are icky -- configured by cowboy admins who still view our networks as magical tubes. In many cases, we only approach app monitoring to disprove assertions that our networks are the cause of poor service delivery. Over time, however, the nature of network engineers and their methodical approach to monitoring their networks have made them the go-to resources for unbiased data, and sometimes, even the final arbitrators of performance disputes. Interestingly, that's true for teams both small and large.
NASCAR and IT: Doing the hat dance
A redeeming quality of 1,000 channels of TV is the chance to see what happens after a big event ends. If you've ever watched the end of motorsport event, you've seen the "hat dance." The team takes a photo, the PR people rush up and jam another set of sponsor hats on everyone and they take another picture. Sometimes they'll do this more than a dozen times. None of the pit crew, drivers or managers enjoys this; it's just part of the job. Say cheese: I'm Sunoco, I'm Goodyear, I'm Home Depot.
Just like a NASCAR team, IT personnel often find themselves having hats slapped on them, but with the expectation they really become the tag on the cap. You're VoIP, you're Storage, you're Systems. Network administrators are not immune.
For the majority of IT teams, a decent percentage of the crew manages both networks and systems, with a few dedicated gurus off on the margins. A mid-career admin whose hottest tickets are healing executives' broken Exchange mailboxes may also be walking the floor with the wireless sniffer, wrestling with Remote Authentication Dial-In User Service (RADIUS), doing VPN config and keeping the VoIP infrastructure working. Although he's not technically a net admin, he's certainly doing network administration, as recognized by Cisco's new specialist certification programs.
He's wearing lots of hats and monitoring applications, and the network as a single infrastructure seems natural. Wi-Fi thin clients and controllers up, dynamic host configuration protocol requests visible in NetFlow, RADIUS server box and services up. Life is good.
Get in there…I don't care what you smell
If on the other hand you're a (mostly) dedicated network engineer, you probably don't have as much involvement with application monitoring as your IT generalist peer, but when you do, you have to rely more on your monitoring systems. No one reasonably expects people who can remember dozens of core IPv6 addresses off the top of their head to also roll up their sleeves and debug issues with high SQL disk write queue lengths. You tell the database guy to go talk to the SAN guy. You're in an airport doing command-line interface firewall configs over the VPN on your phablet. You live by the metrics and alerts from your network performance monitoring system. Why gum that up with somebody else's problems?
Actually, there are a couple of good reasons to help your sys admin peers. First, in most cases you know more than they do about what their applications actually are doing. You know what sort of traffic they generate, you're tweaking routing to streamline app services and you sprinkle the magical ultra-low-latency fairy dust on the links between their virtual machine hosts and the SAN. Forget the unfathomable swirling bits inside the servers. Your network is what glues application tiers together and connects services to users.
Second, you already have the core of the monitoring infrastructure in place and are in a position to drive the selection of the tools the app team will use. You can ensure it integrates with your existing software and provides end-to-end monitoring of all elements of the application: physical network, routing, topology, traffic analysis, virtual and physical server hardware, OSes and the applications themselves.
Best of all, the latest systems monitoring software already understands most popular application servers. Not only can you provide rich monitoring, but you can monitor all systems equally as well. You won't have to waste time creating semi-automated processes for critical servers that are too complex to maintain on every system.
One final suggestion: After you send the sys admin his first URL where he can see all elements of his service delivery in one place, be nonchalant. It's the icing on great work that makes you an oracle.
About the author:
Patrick Hubbard is a head geek and senior technical product marketing manager at SolarWinds Inc. With 20 years of technical expertise and IT customer perspective, his networking management experience includes work with campus, data center, storage networks, VoIP and virtualization with a focus on application and service delivery in both Fortune 500 companies and startups in high tech, transportation, financial services and telecom industries. He can be reached at Patrick.Hubbard@solarwinds.com.