Date: Tue, 19 Mar 2024 07:15:29 +0000 (UTC) Message-ID: <1784963713.2869.1710832529208@ip-10-0-1-161.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2868_675785500.1710832529205" ------=_Part_2868_675785500.1710832529205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
When a problem occurs at a datacenter, Application, or SL= A, the Monitoring Station can send alerts to users. Alerts are notification= s that inform users who are configured to receive alerts of the problem. Th= e notification message contains the following information:
Whenever the status of an Element changes (for example, f= rom Critical to Warning), Uptime Infrastructure Monitor sends an alert.
You can also configure alert esca= lations that occur if a warning is sent and is not acted upon. For exa= mple, if an alert is sent to a system administrator, and the administrator = does not attend to the problem within a specified amount of time, then the = alert is sent to the administrator=E2=80=99s manager.
Uptime Infrastructure Monitor can send alert to a phone, = pager, or one or more email addresses.
The following is a sample email alert:
Notific= ation type: Problem 1/12/2008 10:52 Host: filter Host State: N/A Service: FS Capacity - Filter Service State: WARN/ Output: /var is 92% full
The following is a sample pager alert:
subject= : CRIT Alert content: 5/7/2005 13:22 Type: Problem Service: FTP (CRIT) Host: filter (CRIT)
Alerts in Uptime Infrastructure Monitor follow a specific= flow. When Uptime Infrastructure Monitor detects a problem with a host, it= issues an alert. Uptime Infrastructure Monitor then continues to check the= host at specific intervals and reports on the status of the host.
Considering the following example:
Uptime Infrastructure Monitor encounters a critical error= on a host. Uptime Infrastructure Monitor performs three rechecks at one mi= nute intervals=E2=80=93all of which return a critical error=E2=80=93an= d then sends an alert after the third recheck.
Uptime Infrastructure Monitor then checks the host every = two hours. While Uptime Infrastructure Monitor encounters two critical erro= rs, it does not send an alert. Then, the status of the host changes from Cr= itical to Warning. When this change is detected, Uptime Infrastructure Moni= tor sends an alert informing recipients of the change in status. When the s= tatus of the host changes to OK, Uptime Infrastructure Monitor issues an al= ert informing recipients that the host has recovered.
This alert flow is illustrated in the following diagram:<= /p>
All service monitors have a common set of Monitor Alert Settings that configure aspects of the alert flow.
Alert Profiles are templates that tell Uptime Infrastruct= ure Monitor how to react to various alerts that are generated by service ch= ecks. Alert Profiles enable Uptime Infrastructure Monitor to execute a seri= es of actions in response to the failure of a service check or when a thres= hold is exceeded. The following diagram illustrates how an Alert Profile wo= rks:
An Alert Profile can send an alert via email, or to a pag= er or a cell phone. You can configure any or all of these actions to occur = simultaneously by associating the Alert Profile to multiple Notification Gr= oups. For example, if a Web server process stops responding, both the syste= m administrator and Web server administrator can be notified.
Alert Profiles include standard message templates for ema=
ils and pagers, which are well suited for most alerting needs. However, you=
can customize the format of the alert using predefined variables. When cre=
ating or configuring an Alert Profile, selecting the Custom Format<=
/strong> option provides you with a template to modify, and override the me=
ssage template for the alert type you have selected:
See Custom Alert Message Variables for more information.
In addition to sending alert messages, Uptime Infrastruct= ure Monitor can also execute an alert script. When an outage occurs, the sc= ript is run on the Monitoring Station, once for each user who receives noti= fication. Like custom alert messages, alert scripts use predefined variable= s to represent outage-specific information; these variables are passed to t= he script at the time of the outage.
For information on alert script variables, see Script Alert Variables.= For more information on alert scripts, see the IDERA Knowledge Base articl= e, Creating Custom Alert Scr= ipts in Uptime Infrastructure Monitor Alert Profiles.
To create Alert Profiles, do the following:= p>
Email Alert
Sends the alert to the email addresses of the members of a Notification Gr=
oup.
Pager Alert
Sends the alert to the pagers of the members of a Notification Group.
Script Alert
Executes an alert script on the Monitoring Station, once for each user who=
receives notification of the alert.
Because this alert option relies on a script or batch file, enter its name=
and path in the Script Path field (for example, on Linux,=
/usr/local/uptime/scripts/scriptAlert.sh
).
To view Alert Profiles, do the following:
Notification type: Problem=
27/4/2006 09:19
Host: Test Host (OK)
Ser=
vice: Test Monitor
Service State: OK
Outp=
ut: This is a test notification; please ignore.
Alert Profile Tested
appe=
ars in the popup window. If an error message appears in the popup window, e=
dit the profile and test it again.To edit Alert Profiles, do the following:
You can associate an Alert Profile to any Service Monitor= , Application, or SLA if their state changes from OK to Warning or Critical= . Alert Profiles are normally associated with any of these monitored items = at the time of their configuration; you can also modify Alert Profile assoc= iations using existing service monitor definitions.
See Usin= g Service Monitors, Working with Applica= tions, and Adding and Editing SLA Definit= ions for more information about configuring Service Monitors, Applicati= ons, and SLAs, respectively.
Action Profiles are templates that direct Uptime Infrastr= ucture Monitor when it encounters a problem on a monitored system. You can = associate an Action Profile to any Service Monitor, Application, or SLA if = their state changes from OK to Warning or Critical. Action Profiles are nor= mally associated with any of these monitored Elements at the time of their = configuration; Action Profile associations can also be changed when you are= modifying existing service monitor definitions.
See Usin= g Service Monitors, Working with Applica= tions, and Adding and Editing SLA Definit= ions for more information about configuring Service Monitors, Applicati= ons, and SLAs, respectively.
Actions include one of the following tasks:
As templates, Action Profiles can be reused for any numbe= r of Service Monitor configurations. This means you can create a series of = them as standard actions used to respond to typical types of problems you m= ay encounter, depending on what role a Service Monitor is playing (for exam= ple, availability or performance).
If an administrator has integrated Uptime Infrastructure = Monitor with VMware vCenter Orchestrator (see VMware vCenter Orchestrato= r Integration), you can configure Action Profiles to initiate Orchestra= tor workflows.
Orchestrator is a VMware vCenter Server add-on that allow= s its administrators to create workflows that automate vCenter management t= asks. These Orchestrator workflows are open ended: all vCenter actions are = available for automation through the processing of parameters and runtime a= rguments. Uptime Infrastructure Monitor Action Profiles can be configured t= o provide input parameters to specific workflows, thus integrating vCenter = management with Uptime Infrastructure Monitor=E2=80=99s monitoring and aler= ting capabilities.
For example, if Uptime Infrastructure Monitor is monitori= ng memory, CPU, and hard disk use for a virtualized server, the passing of = performance thresholds can trigger an Action Profile that, in turn, trigger= s an Orchestrator workflow that creates a new virtual machine to alleviate = resource strain. In a converse example, if Uptime Infrastructure Monitor is= monitoring a virtualized server for long periods of inactivity, a triggere= d Action Profile can initiate an Orchestrator workflow that shuts down the = instance to free up resources.
By tightly integrating Uptime Infrastructure Monitor=E2= =80=99s monitoring and alerting with VMware vCenter Orchestrator=E2=80=99s = automated virtual environment administration, you can accelerate your organ= ization=E2=80=99s reaction time with virtual systems management, and map es= tablished policies to automated actions.
When configuring Action Profiles, Uptime Infrastructure M= onitor communicates with Orchestrator and dynamically produces a list of al= l available workflows. (This includes any third-party workflow packages tha= t are installed on the Orchestrator server, including the Uptime Infrastruc= ture Monitor Orchestrator package.)
When a workflow is selected, and the Get Paramete= rs button is clicked, the corresponding input parameter fields are= dynamically displayed, allowing you to specify parameter values required t= o completely configure the workflow for execution should an Uptime Infrastr= ucture Monitor alert initiate it.
When configuring a VMware vCenter Orchestrator workflow, = you have at your disposal a set of Uptime Infrastructure Monitor-specific v= ariables that can be entered as parameter variables, and whose ensuing runt= ime values are passed to the Orchestrator workflow during execution. The va= riables available to you are those that are used when creating a custom ale= rt format. See = Custom Alert Message Variables for information.
You can also configure an Action Profile to send an SNMP = trap to a particular host. An SNMP trap is a notification issued by a syste= m that is running SNMP when a problem occurs. The host to which the SNMP tr= ap is sent must be running an SNMP trap listener.
If you use SNMP traps,= the trap message is sent in the format specified by the Uptime Infrastruct= ure Monitor MIB. This MIB is found in the/scripts
directory. =
The Uptime Infrastructure Monitor enterprise OID is .1.3.6.1.4.1.242=
16
.
To create Action Profiles, do the following:<= /p>
"/usr/local/uptime/recover.sh" "24/12/2014 5:01:05" =
"Problem" "printserver" "null" "WinSrv-Print Spooler" "CRIT/threshold error=
" "servicestatus: Not Running does not match Running (Service 'Print Spoole=
r' found, status: Not Running, took 12ms)"
For information on predefined variables that can be used in Action = Profile scripts, see Recovery Script Variables.
You can also use the recovery script to file trouble tickets with a syst= em like Remedy, or to interact with third-party software packages.
Windows Host
The name of the host on which the service is running.
Enter $HOSTNAME$
in this field to create a dynamic hostname=
. For failing services that call this Action Profile, the corresponding hos=
tname is used when this action runs.
You can use this dynamic hostname in conjunction with service groups, wh= ere an issue can originate from one of many hosts.
Windows Service
The display name of the specific Windows service to which the Action Profi=
le applies. The display name of a service appears in the Name column of the Services Control Panel, or in the
The service display name must be entered verbatim, including spaces, oth= erwise it is not correctly processed. Double-clicking a service name in the= Services Control Panel opens a properties window where yo= u can highlight and copy the service Display name.
Windows Service
The display name of the specific Windows service to which the Action Profi=
le applies. The display name of a service appears in the Name column of the Services Control Panel, or in the
The service display name must be entered verbatim, including spaces, oth= erwise it is not correctly processed. Double-clicking a service name in the= Services Control Panel opens a properties window where yo= u can highlight and copy the service Display name.
Monitoring Periods are the times over which a service mon= itor is actively monitoring a host. The Monitoring Periods also apply to th= e times when Uptime Infrastructure Monitor sends alerts
Uptime Infrastructure Monitor comes with the following Mo= nitoring Periods:
You can add Monitoring Periods that suit your needs. For = example, you can create a Monitoring Period called " Weekends" that only mo= nitors a host from 12:00 a.m. on Saturday to 11:59 p.m. on Sunday.
To add Monitoring Periods, do the following:<= /p>
On the Uptime Infrastructure Monitor tool ba= r, click Services.