|
The BMC PATROL framework provides the ability to the administrators to create custom monitoring solutions to cover their specific needs. This can be achieved with the BMC PATROL Developer Console that lets the user develop what is called a custom KM written in PATROL’s own scripting language: PSL.
| PROS — | Developing a custom KM with PSL is logically the most flexible solution in order to cover a custom application because the developer has the liberty to tailor a monitoring solution that is specific to his custom needs. It can be done in-house and at any time. |
| CONS — | Developing a custom KM cannot really be considered as THE obvious choice because of several issues, besides, although at first it may seem more economically viable, on a deeper project planning, the hidden costs are revealed. In addition, a large and complex environment may require many such custom KMs….Here are some of the commonly stated difficulties encountered by customers who have ventured on this path, and no longer wish to repeat the experience. |
| • | Human resources: Developing a custom KM with PSL obviously requires developer skills, deep knowledge of the PATROL Agent’s internals and PSL skills, which means having people dedicated to the task. Apart from the cost of man-hours spent on the development, it is a fact that people with good PSL skills are hard to find as PSL is now considered as an aging technology and hence few developers invest in learning PSL. |
| • | Re-inventing the wheel with repetitive basic coding: Gathering the information needed to check the health of an application or other IT component often requires the KM developer to re-create code that has already been done many times by other professional developers. Having to re-invent the wheel to collect monitoring data is the most pitiful time wasting issue when developing a custom KM. For example: Executing an SQL query, sending an HTTP request or listening to SNMP traps, all generally considered as basic tasks, but which nevertheless require hundreds of well-thought lines of code, especially when using PSL. |
| • | GUI and Packaging: The pure PSL coding part is sometimes not the most time-consuming step when developing a custom KM. For proper use in production, a custom KM needs to be packaged for the various components of the PATROL framework (consoles, agents, Console Servers, Web Console, etc.). The packaging of a KM often implies dealing with time-consuming tasks such as creation of suitable graphical user interface, the icons, online help, proper platform targeting, etc. None of these tasks are automated in the PATROL framework and require a thorough knowledge of the packaging and installation systems. |
| • | Testing: The testing of a custom KM is extremely important before deploying it into production. To be valid, testing and debugging need to be done in a proper test environment once the package has been created and installed on the test servers. A poorly designed KM can cause the targeted application to crash or can consume 100% of system resources. It can also simply fail because the packaging was done incorrectly. Once problems have been detected in the test environment and bugs have been identified and resolved, the whole fixing, packaging, testing and deployment process cycle starts all over again. This needs to be repeated as many times as necessary in order to get a fully functional yet non-problematic custom monitoring solution. |
| • | Deployment: Once a custom KM has been successfully validated, it needs to be deployed into production, which again is not an easy task depending on the deployment tools being used, and which involve time and risks. The main issue with deployment is that it’s a recurring issue: each new custom KM needs to be packaged and deployed into production while other standard solutions (like the Log Management KM described above) need to be deployed only once on a server. |
| • | Solution upgrades and release management: The development process is an interminable cycle. Once a custom KM is released, the developers continually face requests from users and administrators: new bugs to be fixed, small feature improvements, performance improvements, and updates to keep in step with the application’s releases, as well as other brand new features that were not planned during the development process. Once these requests are legitimated, the development cycle restarts all over again. In addition, the alteration of the code of an existing custom KM is possible or easier when done by the team that worked on its creation… however it seems that PSL developers rarely spend more than 2 years in the same PSL development position. So it’s back to square one – trying to find the suitable human resources for the project. |
Although on one hand custom KMs seem like the most flexible and viable solution at the outset, it is proven in today’s world of fast-changing technologies, that in the long run, it turns out it is economically more viable to purchase a ready KM specifically designed to deal with complex and diverse monitoring needs; one that is regularly upgraded and maintained by professionals bound by terms of contract.
|
