The reason I ask is that it would seem that across our dozen different infrastructure areas - ONMS seems to be (or is currently planned to be) targeted to those areas other than the network itself (such as office automation, mid ranges services, mail and messaging), but not to network itself (lan/wan/man network, firewall, vpn services, url filtering,etc) . Network seems to have a myriad of alternate tools - so before asking network why ONMS is not on radar, I couldn’t help but wonder if ONMS had some major network feature gaps/issues.

Tks again!!!

It makes a lot of sense re: an enterprise solution like ONMS across the entire infra.

Don’t know what mgt will go for re: funding, but have narrowed down our options to 3 now - i.e.

a) build a common cdb as hub to multiple disparate cdb’s in use today (so this option would be “fit for purpose and use” but likely would be a long, complex, costly and questionably supportable process given the multitude of disparate monitoring tools that would still be left in use - with their disparate cdbs to be joined into this one overall home grown solution),

b) buy (vet reqts and cost first) a vendor cdb product that is best at joining disparate cdbs - e.g. hyperformix data manager, bmc or teamquest cdb software products - this could end up being more practical as opposed to in-house development/supportability (but would still require the same work effort re: cdb requirement gathering, gap analysis, may still fall short re: filling the need, do little to align the disparate monitoring tools in place and possibly be more expensive than one common open source monitoring tool using its one cdb) or

c) buy (vet reqts and cost first) into an open source enterprise, scalable, self-discovering, visible, fully featured, “easier than most others to configure” monitoring solution like OpenNMS (gtreat erporting capability and fully supported at a reasonable rate). I was considering whether to table this third option a few weeks ago as option #3, but was hesitant to do so due to the sheer challenge of aligning so many ingrained groups - until I read your blog yesterday. So it’s back on the table again. (I formed this option after some in-house demos of both nagios and OpenNMS, then reading your blog comparing both).

You will likely know which one of the three I am leaning towards - the latter is the best long term (5 year?) strategy to follow - it is simpler since there is only one tool, one cdb in the end and the option may even prove to be financially attractive re: ROI etc. - however as I have inferred, this third option would require an incredible amount of buy-in from all infrastructure sectors, much more time to nail monitoring, common cdb requirements - and likely more time (and thus money) to deploy.

Oh well, I will let you know which of the 3 above, if any (since option 4 would be “status quo”), mgt decides to go with.

Once again, thanks for the feedback …

To answer your question about JRRD first:

JRRD is not a data store in itself, it is a java interface to rrdtool, which stores its data in rrd files.

I’m guessing your OpenNMS installation is pretty old as JRRD was replaced by JRobin as far back as version 1.3.2 if memory serves.

Regardless - it is possible to extract the data from RRD files as XML as you state, so you could then convert this to whatever format you require if you wanted to do something else with it. I believe there might be a few tools out there to tie RRD files into some ODBC compliant form, but generally this is regarded as unnecessary and probably more trouble than it is worth. Hopefully the reasons for this will become apparent below…

It’s been a while since I was active in this area so I’m not sure what the latest developments are, I’m also not sure what you’re referring to with regard to a federated CDB or an enterprise solution.

OpenNMS is an enterprise solution. It is designed to be an enterprise grade Network Management System, so if this is what you mean by a federated CDB all I can say is just because you have to pay for something it doesn’t necessarily make it better.

Rather than spending time and money trying to find an expensive solution to pull in data from a variety of different monitoring systems, might it not be a better approach to look at consolidating your half dozen or so disparate systems into a single platform to monitor the whole network?

Having worked in a number of places which sound like yours, where various different products have been installed by a succession of different Systems Administrators, largely on a whim, and which are usually then not maintained, it quickly becomes a real headache to manage. The best approach is generally to get rid of them all and start with a clean sheet. Trying to tie them all together usually just adds even more complexity.

If the solutions you are looking at are not affordable, as you say, I strongly encourage you to spend some time looking into the capabilities of OpenNMS.

If budget is available I’d also strongly encourage you to talk to the guys at OpenNMS and see what they can do to help in terms of support.

I’m not sure if that answers your questions but I hope its some useful information.

I am not a techie and know very little about Nagios/ONMS etc - but after reading your blog, I thought perhaps you might have an opinion on the following.

From what I understand about ONMS (at least based upon how the older version was deployed at work here), it seems that the KPI metrics are stored by default in JRRD while newer non - KPI related (e.g. availability management) data has been stored in Postgres.

A fellow in our department was looking at a number of our environment tools recently (seems that ONMS has not been deployed across all of them so we have half a dozen in use in production today) and was considering doing a small proof of concept re: an interim solution (creating of a federated cdb to yield a common consolidated view across all these areas) until such time as an enterprise solution became affordable.

He then said that he would like to communicate with the historical data (or a subset) from all of these tools’ disparate CDBs created from disparate tools (most are Oracle odbc compliant) but that he would not be able to communicate with ONMS’s KPI data due to it being stored in JRRD.

So, I have two questions:
a) have you encountered such an issue re: JRRD and is there an easy way to export/convert the JRRD data into another format - perhaps Postgres? Or is it easier to first export the desired data from JRRD to xml format first, then load it into an odbc complaint rdbms?
b) have you had much/any experience with creating an enterprise cdb to tie together disparate remote cdb data?
c) I have looked on the web at enterprise cdb solutions and came across TeamQuest’s Enterprise CDB solution. Are you aware of what other folks are doing in the industry to address this enterprise cdb issue?

Many tks in advance for whatever insight you can supply…

We need businesses to support us. To have faith & confidence in us as a community of experts - not as a bunch of geeks with a grudge.

We need to polish our messages - not to go “corporate”, but talk to them as peers. To engage in a dialog that they understand and feel welcomed by.

With the support of the non-technical sides of the business - so we get more involved. Our status as trusted advisors that we *really* looking out for their interests - not to fleece them via quasi-legal lock-ins.

That requires us all to invest in learning how to present ourselves. A “commercial” & a “community” website along side materials, webinars, demos and fully-enabled professional partner programmes to support the delivery of quality services - globally.

We need to compete head-to-head with HP, BMC, CA, EMC, IBM and the mid-tier too. We need to give those engineers that want to deploy our solutions the tools to be agents of change. They need business cases, support packages, structured professional services - they need the experience they receive from the traditional proprietary channel.

That’s a long way from where we are today - but at least the software is already there.

I’m hoping to have the pleasure to collaborate with them on an interesting project. They have worked enormously hard to deliver a great software product and develop their expertise.

We’ve chosen to work with OpenNMS and invest in further development because of their product - and their quality service. Well done Tarus, Jeff, David and the rest of the crew.

Of course, a little marketing polish wouldn’t hurt - as long as you understand it to mean -> engaging in a meaningful two-dialog with everyone involved in the process - budget holders, managers, engineers.

Just wanted to know your take on OpenNMS is appreciated, and I’m glad you “get it” — this is exactly the kind of experience we’re trying to make sure all of our customers and users get.