“Do you always look at [the data] encoded like that”, asked Neo as he looked over the shoulder of his crewmate. Cypher responds, “Well you have to. There’s way too much information to decode the Matrix. You get used to it. I don’t even see the code. All I see is blonde, brunette, red-head …”. For the uninitiated this dialog is from the 1999 Sci-Fi film “The Matrix”. I thought of this scene recently when a customer requested help in generating a report that would have yielded a result larger than 62,000 records. I said to myself, “That request is absolutely bananas. Not only would it take ages to extract the data, but it would take even longer to parse and analyze it.”
This experience started me thinking about the larger topic of IT reporting in general and the role it should play in an organization. I honed in on two of the “5 Ws” (thank you Journalism 101). “What” things should a Network Management System (NMS) be configured to report on and “Why” do IT reporting at all? Which “W” should be a higher priority to a company’s leadership team?
To remove any ambiguity, for the purpose of this post, “Reporting” means looking at a historical view of particular variables on a group of objects in the NMS. The “Top 10 servers last week sorted by memory utilization” or “The average latency of all the routers maintained by my MPLS provider this year” are just two examples.
On one hand we’ve got the question of “What” objects should be reported on. Since all enterprise-level NMS tools do reporting of some kind, this question morphs into a decision about what objects even should be monitored. All Servers? Production web applications only? Equipment maintained by outside vendors? An IT Manager needs to ask: What things in my infrastructure do we need better visibility into? Of course, the answers to these questions become a function of licensing costs, administrative burden to setup, and other factors.
An additional aspect of the “What” question comes at the problem from the other direction. Instead of saying what objects need more visibility, IT leadership should ask: “What are the pain points in our system?” Do users constantly complain they can’t adequately stream video? Perhaps customer feedback from your E-Commerce storefront indicates credit card transactions take too long? The point here is that you back into your monitored object list based on the problems currently plaguing your environment.
So far we’ve got a pretty compelling case for “What”. Except “Why” has merit of its own. Why bother with reporting? By far the biggest reason to setup reporting is that it can be used to catch problems in your infrastructure before they escalate into critical issues which impact a business’s day-to-day operations.
The other reason why reporting is important is an offshoot of the “catching problems before they become PROBLEMS” scenario, and that’s the idea of IT capacity planning and business intelligence. Let’s say it’s time to prepare the IT infrastructure budget for next year. What better source of information is there to decide if need a new server farm or lease resources from AWS than your NMS tool? The 62000-record result set example I opened this post with was actually a request from the customer’s BI team looking to analyze bandwidth consumption for their Internet-facing routers during “peak” season. These types of tasks are “Why” structured historical reporting is so important in today’s IT landscapes***.
Two “W”s and four good reasons. Surely, we’ve enough information to make a judgment on which should be a higher priority, right? As is so often the case, the answer in IT is “it depends”. Yipee! Another so-called “expert” blathers on about a topic for 750 words only to avoid giving a real answer. I know. It irritates me too, so here you go. Yes, it depends upon many variables, however, “Why” should be a higher priority. Yes, this blog is meant to convey systems and network management best practices. However, a reoccurring sub-theme from month-to-month is that the sole purpose of IT in an organization is to improve business operations in one aspect or another. Take a closer look at the two sides of the “W” ledger again. Which of the two is more high-level and business-centric in its approach? None of this is to say “What” shouldn’t be a consideration, but a reporting strategy needs to be driven from the top down. Once the “Why” questions are answered, the answers to “What” become clear.
While the decisions on how to setup IT reporting are hardly as existential as the Red-Pill/Blue-Pill debate, there are myriad details and aspects to consider. When “following the white rabbit” in this regard just have a clear idea of the desired end-state (higher uptime, more accurate budgets, etc) and it will be worth all the effort you put in.
***For the record, I was able to ultimately talk the customer in question out of running such a massive query and instead pointed them to a “canned” report that yields the roughly same information as a detailed analysis of all that data.
