|
This solution is comprised of the following components:
| ▪ | The PATROL Agent (core layer and required component to any PATROL-based solution) |
| ▪ | The PATROL for Windows KM to monitor Windows performance metrics as well as specified processes and Windows services |
| ▪ | The PATROL for UNIX KM to monitor UNIX performance metrics as well as specified processes |
| ▪ | The PATROL for Log Management to monitor log files |
Acquisition of BMC Performance Manager for Servers brings not only the monitoring framework, but also a few monitoring tools to help monitor custom applications. These features come for free and include:
| ▪ | Processes and Windows services monitoring |
| PROS — | Most applications generate log files to record operations and errors. Checking the presence of the various processes and parsing log files for errors is often considered as an alternative way of monitoring an application without developing a custom KM dedicated to it. This feature is free. |
| CONS — | Relying only on information gained through processes and log files monitoring features of BMC Performance Manager for Servers is more than often considered as a non-ideal solution because of several limitations: |
| • | General: Inability to group the monitoring of processes, services and logs application-wise under a single icon in the Console prevents rapid problem-identification. Several alerts could be raised, but the operators have to study each alert in thorough detail to know which applications they stem from. |
| • | Process: Inability to efficiently monitor processes of Java applications, or ensure that some processes are running as a specified user. |
| • | Log: Inability to analyze files with multi-lines entries or search for complex regular expressions. It has also great difficulties dealing with very large log files. Another limitation of this log file monitoring feature is that it does not allow the administrator to raise alerts to the operators with the actual content of the log file in the event, thus leaving the operator with a meaningless event stating that “an error” was reported in the log file. The only way to find the root cause is for the operator to sift through the log file line by line to see what the problem is. |
| • | Log: Relying only on log files can be dangerous: for instance if nothing is recorded in the log file, it could either imply that everything is working properly or that the application is completely frozen. |
| • | General: Relying on processes and log files monitoring leaves out more recent applications composed of a Web front-end, a database back-end and often a Java Application Server in the middle. Such applications do not have specific processes and most often do not produce any log files. Ensuring the availability of the Web server and the database server does not necessarily mean that the application based on those infrastructure components is running properly (a dropped table in a database, for example, can cause an entire application to fail while the Web and database servers are just running fine). |
| • | General: There is no easy way to duplicate the monitoring setup for one application on one serve to another server running the same application, especially with the monitoring of processes. Things get even worse if the said application is installed in another directory than the original one. |
| • | General: Log files and processes monitoring do not allow administrators to monitor performance metrics and response times related to an application, which means that even a huge slow-down of an application or other IT component being monitored will not be reported. |
These limitations in BMC Performance Manager for Servers often lead IT administrators to consider the development of custom monitoring solutions in order to be able to properly monitor applications for which there no KMs are available in the BMC Software’s catalog. This option is described in the following section.
|
