Date: Fri, 29 Mar 2024 07:13:00 +0000 (UTC) Message-ID: <506253543.5649.1711696380023@ip-10-0-1-161.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5648_910156643.1711696380018" ------=_Part_5648_910156643.1711696380018 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In some cases, the standard Uptime Infrastructure Monitor= service monitors may not fully enable you to monitor all of the systems, a= pplications, and proprietary devices in your environment; in some cases, yo= u may need to capture unique metrics. To do this, you can configure advance= d service monitors, or download and install plugin monitors.
These advanced monitors can be simple scripts that run se= rvice checks on a host. You can write a shell script, or use a higher-level= scripting language like Perl, Python, or Ruby. Or, the advanced monitors c= an be binary programs that interact with more sophisticated applications. O= n top of that, advanced monitors do not require an agent to be installed on= the system that you are monitoring.
Regardless of how you develop your advanced monitor scrip= ts or programs, those scripts or programs should return the following codes= :
Uptime Infrastructure Monitor captures the output from th= e script or program, usually from standard output ( = stdout ). The output appears in the service status section of the Global Scan dashboard (see Understanding the Status o= f Services). The Uptime Infrastructure Monitor monitoring framework pic= ks up any error codes and triggers the appropriate monitoring action.
If you have already written scripts or programs for other= monitoring tools, you can re-use those scripts or programs with Uptime Inf= rastructure Monitor. You simply point your advanced monitor to where your s= cripts or programs are located and Uptime Infrastructure Monitor runs them.=
The uptime user account on t= he Uptime Infrastructure Monitor Monitoring Station must be able to execute= the script or program that you use.
Contact IDERA customer support Services for help with creating custom mo= nitor scripts.
When creating a script or an executable for an advanced m= onitor, you should ensure that:
Many of the fields that you use to define an advanced mon= itor are the same as those used with agent and agentless monitors. You can = find more information about those fields in the following sections.
A Custom monitor runs a script that captures information = which is related to a situation that may be unique to your environment. Whe= n the script is run, the monitored system returns a single line of informat= ion to standard output ( stdout ). The script r= eads stdout, which may contain an error or ret= urn value. This error or return value is then displayed in the Uptime Infra= structure Monitor Monitoring Station.
As well, you can specify that the monitor writes the data= that the script returns to the Uptime Infrastructure Monitor DataStore. Yo= u can use the retained data to later generate a Service Metrics report (see= Service Monitor Metrics Report) or a Service Metrics graph.
Script Name
The name of, and path to, the script or program on the Monitoring Station =
that collects metrics.
Custom monitors with Retained Data return the following i= nformation:
You can specify whether the monitor writes any returned d= ata to the Uptime Infrastructure Monitor DataStore. You can use the retaine= d data to later generate a Service Metrics report (see Service Monito= r Metrics Report) or a Service Metrics graph (see Viewing Sy= stem and Service Information).
You can also specify whether the monitor uses retained va= lues as arguments in the custom monitor script. The values used are from th= e last instance the monitor was run. This most recent data sample can be us= ed in cases where you would like to set alerts based on value comparisons.<= /p>
When you wish to refer to retained values in a script, us= e the following environment variable as an argument:
%UPTIME_PREV_CUSTOM#%
Replace =E2=80=9C # =E2=80=9D= with the ordered value the custom monitor is configured to save (i.e., 1 - 10 ).
For example, running a sample script called application.exe with the following arguments would make use= of retained values for Variable 1 and Variable 5 as retained by the monitor:
%UPTIME_PREV_CUSTOM1% %UPTIME_PRE= V_CUSTOM5%
Script Name
The name of, and path to, the script or program on the Monitoring Station =
that collects metrics on the system.
The External Check monitor captures asynchronous events. = Uptime Infrastructure Monitor does not actively monitor these events by pol= ling or initiating service checks; instead, External Check monitors rely on= an external event to generate the information that the monitors capture. E= xternal Check monitors enable you to determine when to collect service data= for the event that you specify.
After you define an External Check monitor, it has a stat= us of UNKNOWN until the it is updated with a URI similar to the following t= emplate:
http://= $UPTIME_HOST:9996/command?command=3Dexternalcheck&name=3D$ELEMENT_NAME&= amp;status=3D$STATUS&message=3D$MESSAGE&hostname=3D$MONITOR_NAME
$UPTIME_HOST
: the hostname of the Uptime Infrastructure Mon=
itor Monitoring Station
$ELEMENT_NAME
: the hostname (not display name) of the syste=
m the External Check is assigned to
$STATUS
: an integer indicating the status of the monitor: 0=
=3D OK, 1 =3D WARN, 2 =3D CRIT
$MESSAGE
: the message explaining the status
$MONITOR_NAME
: the name of the External Check monitor
A sample script, extevent.pl
, is included wi=
th Uptime Infrastructure Monitor in the /scripts
subdirectory,=
and serves as an example of how to automate the receiving of asynchronous =
events, and update the External Check monitor accordingly. When the script =
is called with the appropriate arguments, it connects to Uptime Infrastruct=
ure Monitor command port (9996), and updates the status, triggering the app=
ropriate Alert Profiles and Action Profiles.
Before using an External Check monitor, contact IDERA Customer Support f= or assistance. You need specific detailed instructions for configuring this= monitor depending on the nature of the applications that generate asynchro= nous events for Uptime Infrastructure Monitor.
Plugins are custom service monitors that are not part of the standard Up= time Infrastructure Monitor distribution, but can be integrated with it to = augment the type of metrics collected. They are typically created by IDERA = Client Support Engineers or Solutions Architects to address specific custom= er needs. Whether created by IDERA or other customers, plugins are hosted o= n the Grid, the community repository for custom m= onitors, gadgets, dashboards, and other enhancements. Each plugin on the Gr= id includes the main distributable archive, any applicable auxiliary files,= and essential installation steps.
Installing and maintaining plugins can also be managed from within Uptim= e Infrastructure Monitor. Users can browse, install, and update plugins usi= ng the Extension Manager if their User Role permits plugin management (see = Working with User Roles for more information).
Users who are allowed to manage plugins can access this option by clicki= ng the Search for monitors link at the top of the = Add Service Monitor pop-up window (accessed by clicking Se= rvices > Add Service Monitor). Clicking this l= ink opens the Extension Manager, and displays the followin= g:
When you install a plugin through the Extension Manager, the plugin is d= ownloaded from the Grid and installed automatically. A confirmation dialog = indicates that the plugin is installed and is now available to be selected = in the Add Service Monitor pop-up window. (The catego= ries the plugin appears in depend on its service monitor definition; see Plugin Guide for more information.= ) The confirmation dialog also instructs you on follow-up steps, if applica= ble:
When upgrading a plugin, typically, all the necessary follow-up steps ar= e already performed.