The Script or Program Monitor, an advanced feature of IPNetwork Monitor, executes external applications or scripts, interpreting their return codes and output as monitored data. This versatile tool triggers alerts when necessary, offering a universal solution for situations where built-in monitors are insufficient. The external tool can be any Windows executable (command-line programs are preferred; GUI applications should only be used if they have an unattended/batch mode). Because IPNetwork Monitor anticipates specific return codes and output, sysadmins often create custom scripts to gather data not accessible through standard tools. However, improper use or neglecting to monitor these scripts can lead to unforeseen service disruptions or data loss, depending on the monitored resource. IPNetwork Monitor provides an effective method to execute and analyze the output of these programs/scripts, automating a process often difficult to manage manually.
Setting up a Script or Program Monitor is straightforward. Locate the executable or script file. Specify any necessary command-line arguments, ensuring proper quoting. Indicate whether it’s a program (direct execution) or a script (executed via the Windows Scripting Engine). Designate it as a standard program or a Nagios plugin. If required, supply credentials (domain, username, and password) for program execution (default credentials are inherited from IPNetwork Monitor). An optional divisor can be applied to the output value.
Successful execution should yield a zero return code and an integer printed to standard output, which is then used to determine performance status. A non-zero return code, accompanied by an error message, indicates an issue.
Employing a Script/Program Monitor typically signifies that other built-in monitor types are unsuitable. Due to the potential inefficiencies and risks associated with running external programs (e.g., memory leaks), alternative monitoring methods like WMI monitors should be prioritized when feasible. Developers can utilize this monitor type to verify build processes (e.g., confirming file creation and size). System administrators can also leverage it for checking S.M.A.R.T. values. Submitting feature requests to IPNetwork Monitor developers for missing monitor types is encouraged.
Because this monitor can consume significant time and resources, it’s advisable to first employ less demanding monitors, such as File or WMI monitors, to ascertain the need for script execution. Consider configuring these lighter monitors as dependencies.
Description of other features:
| Monitoring Features | Here you can find the list of monitor types supported in IPNetwork Monitor and brief description of their parameters. |
| Application Templates | Here you can find the list of application templates supported in IPNetwork Monitor and their short description. |
| Network Discovery | Helps you to create a basis of your monitoring configuration and automates the task of detection network hosts and network services. |
| Alerting Features | Here you can find the list of alert types (ways of reaction to the problems happened during monitoring) available in IPNetwork Monitor, and their brief description. |
| Reporting Features | Here you can find the list of report types available in IPNetwork Monitor with brief descriptions. |
| IPNetwork Monitor interfaces and structure | Here you can find an overview of IPNetwork Monitor components, Windows and web interfaces. |