I was reviewing some presentations on monitoring and visual charts from the monitorama conference. This caught my eye for a 3D representation for unicast, Multicast and Broadcast traffic (using Barycentric co-ordinates if I understand correctly).
Barycentric representation uses 3D-coordinate system.
Presentation can be found here
Monitoring for Humans
Can’t remember how I found this link Monitoring for Humans by Mathias Meyer
Yet the biggest question that I get every time I talk to someone about monitoring, in particular people new to the idea, is: “what should I even monitor?”
With all the tools we have at hand, helping people to find the data that matters for their systems is still among the biggest hurdles that must be conquered to actually make sense of metrics.
Can we do a better job of educating people what they should track, what they could track, and how they can figure out the most important metrics for their system? It took us six months to find the single metric that best reflects the current state of our system. I called it the soul metric, the one metric that matters most to our users and customers.
I have many, many problems with Network Monitoring and Management. The underlying protocol that we use today, SNMP, is a disaster for providing good quality data. It’s badly designed and not extensible. It lacks descriptions and data validation (even though it was designed with all of these things. Whatever tools you are using, it’s fundamentally junk because the data sources from physical network equipment is so crap.
We need more thinking about why we are monitoring and how we show that data. 2D plot graphs based on RRDTool concepts from a decade ago are simply are not enough for modern complexity.
Gene Kim – DevOps
Ever since being introduced to Gene Kim by Steve Chambers I’ve become a passionate believer in DevOps, Agile and other cheesy buzzwords that normally I would be ridiculing. For example, consider that innovation in the storage industry is an attempt to rename 16Gb FibreChannel as “Gen5” – WTF ?
Here is Gene Kim at a recent DevopsDay event in London explaining why the state of IT Operations (and Network Ops) is a business problem not a technology problem. Watch this and use these points to argue with your management to get a better deal for you & your team.
Introduction to DevOps
Speaking of Gene Kim and DevOps, this book utterly changed the way I looked at IT Management. As a network engineer, I’ve been pretty sure that my leaders were not able to develop the right vision. I started reading this book for a 30 minutes “break” then cleared my calendar for the next four hours to read the whole thing.
I found this totally inspirational. If you are a Network Architect you absolutely need to rush out and read this book. I have totally changed the way I view network ownership and my interactions with business managers. ITIL & ITSM have created the fallacy that technology & operations can be “managed” but this didn’t account for change and adaptation.
Read this book, it’s easy to read.
Bill is an IT manager at Parts Unlimited. It’s Tuesday morning and on his drive into the office, Bill gets a call from the CEO.
The company’s new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill’s entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline inter-departmental communications, and effectively serve the other business functions at Parts Unlimited.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they’ll never view IT the same way again
I recently found this story “My experience with introducing DevOps in a traditional enterprise
The problem with the traditional software delivery process (or the lack thereof) is that it is not well adapted to support these two requirements simultaneously. So companies have to choose between either delivering changes fast and ending up with a messy production environment or keeping a stable but outdated environment.
This doesn’t work very well. Most of the time they will still want both and therefore put pressure on the developers to deliver fast and on the ops guys to keep their infrastructure stable. It is no wonder that dev and ops will start fighting with each other to protect their objectives and as a result they will gradually start drifting away from each other, leaving the Head of IT somewhere stuck inside the gap that arises between the two departments.
but I agree, in principle, with the conclusion
As I already mentioned I don’t know if it is possible to DevOps-ify traditional enterprises the way web 2.0 companies do it (namely by almost completely automating the software delivery process and installing a culture of continuous delivery from the early beginnings). But it may make sense to not look too far ahead in the future but instead start by tackling the biggest and simplest problems first, optimizing and automating where appropriate, and as such iterating towards a better situation. And hope that in the meantime a web 2.0 company has not run away with their business
The EtherealMind View
I’ll admit that spending time researching monitoring, ownership and operational management just makes me confused. I’m hopeful that the industry is moving through a time of change / upheaval / punctuated equilibrium and the future will become clearer. On the other hand, I wouldn’t have it any other way.