Applications Manager offers out-of-the-box monitoring support for 50+ applications and servers to help you take control of your heterogeneous IT Infrastructure. But what happens when your pre-built Applications Manager monitors just aren’t enough to monitor your enterprise? Think ad-hoc custom scripts. Dedicated custom scripts provide the flexibility to tailor your monitors to suit your needs.
With Applications Manager’s script monitoring functionality, you can automatically monitor the output of your in-house Windows, Linux and Solaris scripts. You can monitor script present in a local or remote system, generate periodic graphical reports on the attributes configured, set thresholds for the script’s output and receive E-mail or SMS alerts when there is a threshold breach.
Since my last post detailing a use case of the file/directory monitor, I was on the lookout for more interesting use case scenarios. And, courtesy of our support team, I happened to come across one such use case of the script monitoring functionality (hence the intro).
The Scenario
A company wants to migrate their monitoring script to Applications Manager. They use a batch processing app deployed on their application server for processing jobs. These jobs are triggered on-demand by the users. Whenever a job is performed, the output is written into a text file with a unique job ID. The company’s operation/support team can determine from the output file if a job triggered by the user has been executed successfully. Here is a sample of the output received:
RUN_CODE: 6832
——> JOB_ID: 1559807 /opt/www/exc.mirrorglazz.com/aps/outputlog_155.txt
| Error/Failure: 0 Warn: 1
——> /opt/apps/dsww-perl/out/prod/log/gen_Lastminute.log_1
| Error/Failure: 0 Warn: 1
RUN_CODE: 25431
——> JOB_ID: 1559801 /opt/www/exc.mirrorglazz.com/aps/outputlog_151.txt
| Error/Failure: 0 Warn: 0
——> /opt/apps/gsws-perl/out/prod/firebrigade/log/gen_lPidVZmOms.log_1
| Error/Failure: 0 Warn: 72
The Problem
The output generated by the company’s custom script of nonstandard format and is not compatible with Applications Manager – it has multiple attributes that vary depending on the nature of the job triggered by the user, making it difficult to define attributes. The RUN_CODE and JOB_ID in the output are fetched from a dynamic query and the values change with every run.
How can an operation/support team integrate with ManageEngine Applications Manager to monitor the output and receive e-mail alerts without defining specific attributes? Additionally what if the support team wanted to add some extra troubleshooting inputs than just simple attribute values and graphic reports? Solving this would go a long way for the NOC.
This query got us thinking and this is what we came up with.
Our Solution – predefined attributes using Script Monitor
For the script monitor, availability is based on successful execution of the script (script return code). However you can override the availability or response time logic, measured for custom scripts, by using predefined reserved attributes in the output file.
The script output looks something like this:
script_availability=1 (Allowed values are “0” for success and “1” for failure.)
script_message=http url to access the output.
script_responsetime=10
While parsing the output file, availability will be determined based on the script_availability value.
To pass extra inputs for the NOC, we can pass on a link via the “script_message” attribute. The script_message denotes the html file that contains the output. When availability is down, the script_message will be appended in the E-mail alert that the team receives along with the detailed information to keep support team informed of what’s happening.
To know more about configuring a script monitor in Applications Manager, go to our Script Monitors help page.
