Provided by |
Tools used to monitor Unix-based servers have been around for more than a decade.
During this time, we have seen many products come and go, with successful tools adapting and maturing as their customer base drove new features and functionalities.
Given the current economic climate and the increasing interest in improving IT operations and reducing costs, many organisations are re-evaluating their existing tool investments and considering what was once thought improbable: replacing entrenched tools with newer tools/technologies, usually from different vendors. This action begs the question, "What evaluation criteria should be used?"
META Trend: Through 2005, users will seek to minimise the number of infrastructure and application management vendors for similar technology (e.g., one monitoring vendor). Through 2006, new infrastructure and service pricing models (e.g., subscription, usage, term), continuing capacity- and version-driven cost increases, and expiring enterprise agreements will cause buyers to reassess procurement efforts. The focus will be on more function-specific, loosely coupled, "good enough" suites built around Web services protocols.
With a technology base that can be a decade old, many Unix monitoring tools have not aged gracefully to fit comfortably into the stable of tools relied on by IT organisations (ITOs) for day-to-day monitoring. Many vendors have continued to invest R&D dollars into such technologies in an effort to stave off obsolescence, while others have moved their older products into more of a maintenance mode and sought to develop or acquire newer technology more in line with managing a complex modern data center. The end result for the consumer is a very jagged monitoring tool landscape that must be navigated wisely.
With the current more complex environment due to increasingly interconnected technologies (e.g., Web servers connected to application servers connected to database servers), the typical common assumption of -follow the market leader and you cannot go wrong" does not quite work as well. ITOs have learned that viewing infrastructure technology in segmented silos is somewhat helpful, but now mapping applications or business services across such silos raises their utilities to a whole new level. This is not to say that component level (silo) management is no longer needed and that everything should be looked at from an application topology perspective.
Rather, silos need an added layer of intelligence on top of them to remain relevant. Given the state of the market and consumers' increasing demands for tools, it is expected that, during the course of the next 18 months, features like automatic technology relationship discovery and mapping, more intelligent business views of monitoring data, and business impact assessments of identified problems will be the norm. There are four key areas of consideration when evaluating Unix monitoring technologies.
Agent versus agentless vs a -good" agent
A great deal of discussion has taken place in the past about the best approach as to how data should be collected from Unix servers. The typical dilemma has been whether to use an agent on the server or to use a polling mechanism to collect data from across the network. Although it is commonly agreed that an agentless approach is preferable only when more simplistic data is needed and agents are preferred when more detailed data (typically application level) is required (as well as local action), there is a third dimension to this discussion to consider, which is whether or not the agent is a good agent.
A good agent would be described as having two main characteristics above and beyond what would be expected from an agent:
For most organisations, agentless technology will be the preference based in part on past experiences with poorly performing agents.
5%
8%
