In the Network monitoring is a commodity mythI argued that network monitoring is far from being a commodity and on the contrary needs innovation to cope with the increasing complexity.

As cote mentioned in the comments of that post, there has been some fresh blood in the IT management industry. Several open source companies/projects are tackling the monitoring problem, which is a good thing, yet I feel we're still missing some pieces. AFAIK, most of the monitoring solutions seem to be following existing paradigms :

• monitoring the devices (nodes) through SNMP agent

• synthetic transcations to determine the status of services running on nodes

The understanding of the network topology is missing in both paradigms. In other words, nodes are what's being monitored. Not the network. The network topology (except layer 3) is largely unknown. This limits the effectiveness of the monitoring. Monitoring tools (or rather functionality offered by the tools) can be categorized broadly as the following:

• Polling the devices: Most common approach in IP networks. Most IP networking devices have an SNMP agent that supports at least MIBII so basic availability and performance information can be obtained. For more detailed information however, use proprietary MIBs is needed. Many IT management guys spent long hours trying to understand these MIBs, which data is where, compile them to be used by their monitoring tools, etc.

• Listening for exceptions: Not every network device has an available agent that can be polled, especially in lower layers below IP. And when available, ability to listen for information is useful as it can be more immediate. In IP networks, these are typically SNMP traps or syslog events. In others, there are often element managers that convey messages. Again, IT management folks spent countless, often frustrating hours, trying to make sense of the traps, syslog events, etc. normalizing them, translate them into human language, identifying what is important and what's not etc.

• Listening to the pipes: It is possible to learn a lot by listening to what goes on the network. Flow tools (Netflow and its kin cFlow, J-Flow, netstream, sflow, etc.) generate end to end traffic statistics based on flow of data through the network device that support it. Another approach seems to be analyzing the traffic going through a device using a span port. Although it seems this method is popular to analyze application traffic. I don't have a lot of personal experience with these tools so I'll leave it to others to explain it better or correct me. From what I see these tools often require hardware distributed throughout the network to get full visibility which may be a hurdle for adoption.

IMHO, all of the approaches I've tried to summarize above have some shortcomings. As far as I can see, the situation may improve in two ways:

• someone may come up with a new technology, a clever way to monitor the network and identifytthe problems, may be discover & represent the network etc. IMO, this can only happen if some of the investment and attention in tools that target “business users” with sexy, shiny UIs flow back to the muck. When the payoff is so low (who wants to tackle a “commodity” problem?) significant investment is not likely.

• The power of the community is harvested to solve tedious problems once and share rather than each user struggling to solve the same problems over and over independently. There are already some examples of this splunk is attempting to create a repository of log events and what they mean. ZipTie open source project is working on solving device configuration through collaboration of vendors and customers (how come they are not a member?)

There is a lot more that can be done in the monitoring realm, if we can manage to setup the right collaboration platform (commercially, legally as well as technically) to facilitate sharing, which is sorely lacking in IT management for whatever the reasons may be.

From what I can see, ZipTie model is particularly interesting and suitable. Ability to collaborate and share is potentially a major competitive advantage for open source projects. I believe there are opportunities here for collaboration among open source projects/companies and their users/customers.

For example, in the case of discovery and representation of the network topology, how to get the topology data out of vast number of different type of devices is can be shared. If a common model can be defined to represent the topology, adapters to populate the model for each device can be developed.

In case of trap and event log processing, the knowhow of what each trap may mean, what the varbinds are can be shared. And again if a commong model can be defined to represent the traps/events, adapters to convert the traps into the common model can be developed.

I think these activities are naturally conducive to be solved through collaboration, and the life in the trenches would improve significantly if we were tackling them together instead of drowning in them alone.

What is Open Management Consortium?

The about page states the primary objective as "Create awareness of open source management tools in the market", so the focus is open source mangement tools. Fair enough.

But open management need not mean open source management. There is a lot more to openness than seeing the source code. In my experience ability to see the code is not even highly sought after by the customers ( I work with). I think the term "open source" has come to embody a lot of things that we've been longing for: interoperability, integration, transparency which are also somewhat mentioned in the objectives. I think the "Open Management" as a term is a better embodiment of these principles.

This is not just a play with words. The nuance is important. There are already calls for the large management vendors (loosely referred as Big 4) to open source their products. I don't this approach is neither realistic nor productive. I think we ought to demand them to be more "open", and this does not mean they have to open source their products. There are many other steps that are much less controversial, yet may even be more useful for the industry. IT management vendors (as most software vendors) are typically very "closed" organizations. What do I mean by that?

How many of you have signed an NDA with a vendor? It's pretty much demanded by every company I dealt with so far that restricts what I can share in public. NDAs are used routinely in the industry. You want to have access to software, you have to sign an NDA. This may sound trivial but I think it illustrates the attitudes and the problem. Tendency is guard information, not share it.

Can you go to the websites of the Big 4 (or to any of the other large management tools vendors) , download the product you're interested and give it a spin to see whether it meets your needs? Overwhelming majority of the vendors do not even have evaluation copies available. Transparency. Do you feel like you can participate in the direction the product? Can you even see where the product is heading? And pricing. Can you tell how much the price of the product is without putting a gun on the account manager's head?

I think "open source" products are on the rise, not necessarily because we can see the code (most of us can't care less) or we can contribute to the development (most of us are not devleopers) but if a product is open source, it is assumed to be "open". We can take the open source product,s evaluate/use as long as we want, learn from experiences of the others in the community, and earn our say on where the product is heading, well, not always, but may be most of the time.

In short, I believe we should value emphasize the open in open source more.

I think one reason we are relying on open source as the litmus test for openness is that the other criteria for open source is easier to establish than criteria for being open. Not having an established way to measure openness, it is easy to descend into subjective "I'm more open" pissing match. So I wonder whether it would be possible to come with the criteria to measure how open a company is. I've already hinted some of my criteria, I'm sure there are other better ones.

1. Access to the software. There is no reason why potential customers and partners should not be able to download and evaluate the software, without being harrassed by sales people first.

2. Published APIs and developer programs. Almost all companies claim some sort partner program, but few has active ones, and there are lots of barriers. No reason why the API and documentation should not be available to any interested party, along with the software. The process to become a partner or use the APIs should be simple and transparent. Software vendors should take a page from the book of companies like Google, Yahoo and Amazon in creating APIs and developer ecosystems. The process to use APIs should be straight forward both from technical and commercial perspectives. This is essential for integration and interoperability.

3. No NDAs to silence customers and partners. Let people share their opinions and knowledge as they like. In all these years in the industry I've signed many NDAs, I don't think I ever knew anything worth protecting. This approach is simply poisonous to sharing and collaboration.

4. Available communication channels for the community to participate. Having couple of product managers talk to couple of important customers simply won't do. To ensure the products stay relevant and useful, the best option is to let the community have a stong voice and provide guidance. This is probably harder to quantify than others.

5. Transparent pricing. The game of hiding the prices, having very high list prices and offering big discounts is getting old. Why not publish the prices?

If the software vendors did all of the above but kept the source closed, I'd be more than happy. I'd wager that most companies would not score all that well using these criteria.

What do you think? Are these reasonable? Other criteria to quantify openness of a company?