If you’re reading this update, or any of the previous updates then you are at least marginally interested in enterprise management and data collection. In the four previous posts I’ve discussed some of the issues with enterprise data collection and, specifically, the challenges that MOM 2000 presents as a collection solution. In this, the final installment, I’d like to take a peek into the future of MOM and briefly discuss some other collection options.
In our current environment we use MOM 2000 as our central collection mechanism for Event and Performance Data. As I’ve stated previously, there are some real challenges to using MOM and some very tangible benefits. One of the benefits is that we know MOM is an immature product. In essence MOM 2000 is just the NetIQ code with a Microsoft label slapped on top of it. That does not excuse its many shortcomings, it is simply the reality of the product. But that also means that Microsoft is only just ramping up on its commitment to enterprise management and the MOM product in particular.
In fact, MOM 2005 is right around the corner and while I am not at liberty to discuss the details of the product, I can say with certainty that many of the major challenges in scaling MOM 2000 have been alleviated by MOM 2005. This version represents the first true Microsoft coded version of this product line and while it has improved the product in many areas, it will also suffer from many of the typical version 1.0 and version 2.0 problems that all immature software suffers from. In fact, I don’t believe you can even discuss the maturity of a product until it has reached its fourth iteration.
One of the biggest improvements in MOM 2005, at least in my opinion, has been the architecture changes behind the Agent Manager queue limitations and database table partitioning. The queue sizes allow for a significantly larger file size without the horrendous corruption problems of its predecessor, which means that more agents can be managed per Agent Manager. It also means a greater factor of reliability. But, it also means that an event storm or similar situation can create a huge queue size which can create long delays in data processing. Now many enterprises may not see much benefit from the changes to the database table portioning. In fact, I suspect most DBAs such as myself will think it a very poor implementation. However, in our case it is extremely beneficial. We do not use the MOM database as a repository, only a way point where data is kept for only a few minutes before it is moved to another storage or reporting data store where it can be properly processes and handled by the individual consuming applications and services. So for us, the partitioning of the table greatly improves the overall performance of our environment by allowing us to keep no more than a few hours worth of data in a single table, thusly keeping the latency of inserts and index operations to a minimum.
From my perspective the future of MOM and the Microsoft vision of enterprise management is somewhat cloudy. While I do understand what the company is trying to accomplish, I cannot say I entirely agree with the strategy.
MOM 2005 will likely be the last stand alone iteration of the product. Post ship, both MOM and SMS will be loosely coupled into a single product currently referred to as System Center. System Center 1.0 will likely be nothing more than a bundling of SMS and MOM into a package like BackOffice, but going forward we should start to see more integration between the two products and perhaps better value for customers.
Sure, we could have rolled our own collection mechanisms using Web Services and WMI into an agentless mechanism that would certainly lack many of the issues we’ve seen with MOM. But that environment would not mature quickly if at all. In fact most operations tools never mature, they are simply replaced. In addition, the MOM product would be slower to mature and our application would be reliant on the notoriously sporadic WMI interface (in this example). We could, of course, write an agent to do our collection locally without the need to interface with WMI, but now we would need to write an agent management layer as well. MOM already has one. MOM already collects event. MOM already collects performance data. MOM has problems, but problems that can be solved.
Will
