Alerts Manual

iDashboards Alerts Manual
Version 7.5
V7.5
iDashboards Alerts Manual Version 7.5

No part of the computer software or this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from iDashboards. The information in this document is subject to change without notice. If you find any problems with this documentation, pleased report them in writing to support@iDashboards.com. iDashboards does not warrant that this document is error free.
Copyright 2004 - 2011 iDashboards. All rights reserved.
Trademarks: The iDashboards logo and tagline are trademarks of iDashboards. All other products and company names referenced herein are the trademarks of their respective owners. This product includes software developed by the Apache Software Foundation.
Support information: iDashboards 700 Tower Drive, Suite 400 Troy, MI 48098 Phone: (248) 528-7160 Fax: (248) 828-2770 Email: support@iDashboards.com
Web site: http://www.iDashboards.com
V7.5
Table of Contents
VERSION 7.5......................................................................................................................................... 3 1 INTRODUCTION ........................................................................................................................... 7 1.1 1.2 1.3 1.4 2 ABOUT THIS MANUAL................................................................................................................ 7 SYSTEM OVERVIEW.................................................................................................................. 7 W HAT IS AN ALERT? .............................................................................................................. 8 TERMINOLOGY USED IN THIS MANUAL ....................................................................................... 8
INSTALLATION .......................................................................................................................... 11 2.1 SYSTEM REQUIREMENTS ........................................................................................................ 11 2.2 INSTALLATION ROADMAP ........................................................................................................ 12 2.3 CREATING THE IVIZGROUP HOME DIRECTORY ........................................................................... 12 2.4 CONFIGURING IVIZGROUP.PROPERTIES ................................................................................... 13 2.4.1 RUNTIME LOCATION OF IVIZGROUP.PROPERTIES .............................................................. 13 2.4.2 CONFIGURATION OVERVIEW ............................................................................................ 14 2.4.3 TROUBLESHOOTING ....................................................................................................... 15 2.5 INSTALLING THE LICENSE FILE ................................................................................................ 16 2.6 DEPLOYING THE APPLICATION ................................................................................................ 16 2.6.1 CHOOSING A CONTEXT ROOT ......................................................................................... 17 2.7 LOGGING INTO THE ALERTS SERVER CONSOLE ....................................................................... 17
SYSTEM CONFIGURATION ...................................................................................................... 19 3.1 SYSTEM SETTINGS ................................................................................................................. 19 3.2 MODIFYING A SYSTEM SETTING .............................................................................................. 20 3.3 ALERT SETTINGS ................................................................................................................... 21 3.3.1 SERVER STARTUP STATE ............................................................................................... 21 3.3.2 ALERT INSTANCE RETENTION (DAYS) .............................................................................. 21 3.3.3 BROWSER ALERT CHECK INTERVAL (MINUTES) ............................................................... 21 3.3.4 MAXIMUM DISPLAYED ALERT INSTANCES......................................................................... 21 3.4 LOG SETTINGS....................................................................................................................... 22 3.4.1 GENERAL LEVEL ............................................................................................................ 22 3.4.2 XML LOGGING ENABLED ................................................................................................ 23 3.4.3 HTTP REQUEST LOGGING ENABLED............................................................................... 23 3.4.4 MAX FILE SIZE ............................................................................................................... 23 3.4.5 MAX BACKUP FILES........................................................................................................ 23 3.5 DOWNLOADING LOG FILES...................................................................................................... 23 3.6 SENDING LOG FILES TO IDASHBOARDS TECHNICAL SUPPORT .................................................. 23 3.7 BROWSER ALERT CHECKS ENABLED....................................................................................... 24
MANAGING SEVERITY LEVELS ............................................................................................... 25 4.1 4.2 4.3 ADDING A SEVERITY LEVEL..................................................................................................... 26 MODIFYING A SEVERITY LEVEL ............................................................................................... 27 DELETING A SEVERITY LEVEL ................................................................................................. 28
NOTIFICATION EMAIL SETTINGS ............................................................................................ 29 5.1 EMAIL CONFIGURATION ROADMAP .......................................................................................... 29 5.2 CONFIGURING THE SMTP SETTINGS....................................................................................... 29 5.3 CONFIGURING THE NOTIFICATION EMAIL SETTINGS .................................................................. 31 5.4 CONFIGURING THE EMAIL TEMPLATES ..................................................................................... 33 5.4.1 TEMPLATE DIRECTORIES ................................................................................................ 33
ii
Table of Contents
5.4.2 TEMPLATE FILES ........................................................................................................... 34 5.4.3 HTML SUPPORTING FILES ............................................................................................. 35 5.5 MAIL MACROS ....................................................................................................................... 35 5.5.1 ALERT MACROS............................................................................................................. 36 5.5.2 CHART MACROS ............................................................................................................ 36 5.5.3 EVENT MACROS ............................................................................................................ 37 5.5.4 ERROR MACROS ........................................................................................................... 37 5.5.5 MISCELLANEOUS MACROS ............................................................................................. 38
SERVER OPERATION ............................................................................................................... 39 6.1 PAUSING AND RESTARTING THE SERVER ................................................................................ 40 6.2 UNDERSTANDING SERVER EVENTS......................................................................................... 40 6.2.1 EVENT ID ...................................................................................................................... 40 6.2.2 LEVEL ........................................................................................................................... 41 6.2.3 TIMESTAMP ................................................................................................................... 41 6.2.4 SUBJECT ....................................................................................................................... 41 6.2.5 MESSAGE...................................................................................................................... 41 6.3 REFRESHING THE EVENT LIST ................................................................................................ 41 6.4 FILTERING THE EVENT LIST .................................................................................................... 41 6.5 TROUBLESHOOTING ERROR EVENTS ...................................................................................... 42 6.6 EVENT RETENTION ................................................................................................................ 43 6.6.1 QUALIFIED EVENT RETENTION ........................................................................................ 43 6.7 EMAIL EVENTS ...................................................................................................................... 44
ALERT ADMINISTRATION ........................................................................................................ 45 7.1 RETRIEVING AN ALERT ........................................................................................................... 46 7.1.1 SEARCHING BY ALERT ID ............................................................................................... 46 7.1.2 SEARCHING BY CHART ID .............................................................................................. 47 7.1.3 BROWSING FOR AN ALERT.............................................................................................. 48 7.2 MODIFYING AN ALERT ............................................................................................................ 48 7.3 IMPORTING AND EXPORTING CHARTS WITH ALERTS................................................................. 48
USER APPLICATION: CREATING ALERTS IN CHARTS ...................................................... 49 8.1 CONFIGURING ALERTS ........................................................................................................... 50 8.1.1 CONFIGURE ALERTS MENU OPTION................................................................................ 50 8.1.2 ALERT CONFIGURATION ................................................................................................. 52 8.1.3 ALERT NOTIFICATIONS ................................................................................................... 64 8.2 CHARTS WITH ALERTS ........................................................................................................... 66 8.3 ALERT NOTIFICATION SETTINGS ............................................................................................. 67
APPENDIX A
I.
DEPLOYING THE ALERTS SERVER TO TOMCAT ............................................. 69
ALTERNATE INSTALLATION PROCESS ...................................................................................... 70 LOG CONFIGURATION ......................................................................................... 71
APPENDIX B
Introduction
1.1 About this Manual

Some of the information required for installing and administering the Alerts Server (such as installing JDBC drivers) can be found in the iDashboards Administrators Manual; therefore this manual should be used in conjunction with that one. It is assumed that the reader is already familiar with the iDashboards Server and its basic architecture, and is familiar with the repository database, etc. If not, please review the iDashboards Administrators Manual.
1.2 System Overview

iDashboards Alerts is a separate server from the iDashboards Server. Like the iDashboards Server, the Alerts Server is J2EE web application, packaged in a WAR file. It is entirely separate from the iDashboards Server web application. It can be deployed in the same application server as the iDashboards Server, or in a different one running on the same or different machine. Figure 1-1 provides an overview of the Alerts Servers deployment environment. The Alerts Server connects to the iDashboards repository database, which it reads and updates during its operation. It also connects to the external data sources configured by the iDashboards Server, for the purpose of reading and examining chart data. An external SMTP service, such as UNIX Sendmail or Microsoft Exchange Server, is used for sending notification emails. This component is optional, however; the Alerts Server can operate without sending notification emails.
Chapter 1: Introduction
Server Side
External User Authentication Service (MS Active Directory, Novell eDirectory, etc.)
Client Side
iDashboards Repository (RDBMS)

JDBC
LDAP
SMTP Service
SMTP
J2EE Application Server (Tomcat, Weblogic, WebSphere, JBoss, etc.) iDashboards Alerts Server (J2EE Web Application)
Alerts Server Console Browser (IE, Firefox)
HTML/XML over HTTP
HTML/Javascript Pages
JDBC
JDBC
JDBC
RDBMS
Data Mart
Data Warehouse
External Data Sources

Figure 1-1
1.3 What is an Alert?

The term alert can have different meanings in different contexts. At a general level, an alert is a mechanism that notifies iDashboards users that certain conditions exist within chart data. The term alert is sometimes used to refer to the notification itself, i.e. the item appearing in a users alerts dashboard. It is also used to describe the configuration stored in the repository that defines the conditions for an alert, its name and the message that is displayed to users when the conditions are met.
1.4 Terminology Used in This Manual

In this section some of the terms used in this manual are defined. Alert Unless its context suggests otherwise, the term alert, as used in this manual, will refer to the configuration of an alert the conditions, name, severity level, message text, etc. that is stored in the iDashboards repository database.
iDashboards Alerts Manual Check An alert is checked by the alerts server according to a predefined schedule. This means that the alerts server loads the data of the chart for which the alert was configured, and evaluates it according to the alerts rules. Fire If, during an alert check, the alert's rules are satisfied by the chart data, then the alert is said to fire. Instance When an alert fires, an instance of the alert is created. It is this instance that appears in the alerts dashboard of the Flash-based iDashboards User Application.
10
Chapter 1: Introduction
This page intentionally left blank.
11
Installation
The iDashboards Alerts Server is a J2EE 1 web application, which can be deployed to virtually any J2EE compliant application server. 2 A J2EE web application is packaged in a WAR3 file with a .war filename extension. A WAR file is simply a compressed file in the common zip format, with a specific internal structure. A WAR file contains most or all of the resources used by a J2EE web application, such as HTML files, image files, and Java binary code. The Alerts Server WAR file is named idbalerts.war. The iDashboards Alerts Server is an add-on to iDashboards. As such, it can function effectively only in conjunction with an installation of iDashboards. The installation process described in this document assumes that iDashboards has already been fully installed; therefore, the steps for creating the repository database tables are omitted from this document.
2.1 System Requirements

Operating System - Microsoft Windows 2000 or higher, or any version of UNIX or Linux for which a Java Virtual Machine is available. Application Server - Any J2EE-compliant application server that supports at least the Servlet 2.3 API and the JSP (Java Server Pages) 1.2 API. Any J2EE application server released since 2003 should suffice. The Apache Tomcat application server, which is bundled with iDashboards, is highly recommended. Java - A Java Development Kit (JDK), version 1.5 or later, depending on the requirements of the application server, must be installed on the server. A JDK includes a Java Virtual Machine (JVM) to run the application server, and a Java compiler, which is used to compile JSP pages. If the bundled version of Apache Tomcat is used as the application server, then a Java Runtime Environment (smaller than the JDK) version 1.5 or later can be used. JDBC Drivers - JDBC (Java Database Connectivity) drivers for the repository database, and any database used as the data source for a dashboard. JDBC drivers are usually bundled with a database, or they can be downloaded for free from the vendors website.
http://support.idashboards.com/links/j2eereference
The iDashboards Alerts Server must be deployed to an application server that supports at least the Servlet 2.3 and JSP 1.2 specifications, and runs on a version 1.5 or later Java Virtual Machine. Most application servers released since 2003 should meet these requirements. WAR stands for Web ARchive.
12
Chapter 2: Installation Browser - Internet Explorer 5.5 or above, Firefox or any other comparable browser is required to access the Alerts Server console.
2.2 Installation Roadmap

The exact procedure for installing the iDashboards Alerts Server will vary from one installation to the next, since a wide variety of application servers may be used. If it is being deployed to the same application server that is hosting iDashboards, then section 2.3, 2.4, and 2.5 below may be skipped. Otherwise, the basic installation steps are: Create the ivizgroup home directory This is a directory where the Alerts Server stores needed information. See section 2.3, Creating the ivizgroup home directory, for more information. Configure the ivizgroup.properties file This is a text file read by the Alerts Server that contains information needed to connect to the repository database. See section 2.4, Configuring ivizgroup.properties, for further information. Install the iDashboards license file This file, named idashboards.lic, is provided separately from the installation CD. It is read by the Alerts Server and must be present for it to operate properly. See section 2.5, Installing the License File, for more details. Deploy the idbalerts.war file to the application server See section 2.6, Deploying the Application for more information.
2.3 Creating the ivizgroup home directory

NOTE: If the Alerts Server is being deployed to the application server where iDashboards has already been installed, this step may be skipped. The Alerts Server will use the same ivizgroup home directory as iDashboards. The ivizgroup home directory (also referred to as a folder) is where various files, such as the license and configuration files, needed by the iDashboards Alerts Server and the main iDashboards application are kept. In order for iDashboards to function properly, this directory must exist and be readable. The ivizgroup home directory must be manually created as part of the Alerts Server installation if the alerts server in on a separate server than the main iDashboards application. The default location is in the home directory of the user account under which the iDashboards application server is running, and the default name is ivizgroup (all lowercase). So for example, on a Windows system where the application server is running as the Windows user tomcat, the ivizgroup home directory would be C:\Documents and Settings\tomcat\ivizgroup.
iDashboards Alerts Manual The default location of the ivizgroup home directory can be overridden by setting a Java system property 4 called ivizgroup.home to the path of the ivizgroup home directory. NOTE: Throughout the remainder of this document, <IVIZGROUP HOME> will be used to indicate the ivizgroup home directory. After the location of the ivizgroup home directory has been established and created, three subdirectories must be created within it: 1. <IVIZGROUP HOME>\config This directory is where iDashboards configuration files are kept. 2. <IVIZGROUP HOME>\drivers JAR files containing JDBC drivers (explained in the iDashboards Administrators Manual) can be stored in this directory, making them available to the Alerts Server at runtime. 3. <IVIZGROUP HOME>\logs This directory is where Alerts Servers log files are written.
13
2.4 Configuring ivizgroup.properties

NOTE: If the Alerts Server is being deployed to the application server where iDashboards has already been installed, this step may be skipped. The Alerts Server will use the same ivizgroup.properties file as iDashboards. The ivizgroup.properties file is a plain text file read by the Alerts Server application. It contains the information the Alerts Server needs to connect to the repository database and the settings that control runtime logging. 2.4.1 Runtime location of ivizgroup.properties By default, the Alerts Server will look for the ivizgroup.properties file in the <IVIZGROUP HOME>\config directory. Both the name and the location of ivizgroup.properties can be overridden, however, by setting a Java system property called ivizgroup.properties to the path and filename of the alternate file. The ivizgroup.properties file is in Java properties format, which has the following characteristics: 1. Blank lines, and lines whose first non-whitespace character is # or ! are ignored. (Lines beginning with # or ! can be used for comments.) 2. Other lines should adhere to the format: name=value
A Java system property is set on the command line that is used to start a Java Virtual Machine. For many J2EE application servers, this command line will be contained within a startup script. A system property is set with the switch -Dname=value, so for example, an alternate ivizgroup home directory might be set with the switch -Divizgroup.home=C:\ivizgroup.
4
14
Chapter 2: Installation
where name is the name (unique within the file) of a particular property, and value is the value assigned to that property. Property names and values are both casesensitive. 3. Although the Java properties format allows for leading and trailing whitespace in property names and values (when properly escaped), neither property names nor values in ivizgroup.properties should contain leading or trailing whitespace. A template ivizgroup.properties file is located in the config directory of the installation CD. The names of the properties needed by iDashboards are included in the supplied file, along with instructional comments. 2.4.2 Configuration overview The Alerts Server actually uses a pool of at least three connections to the repository database. There are two possible ways the Alerts Server gets access to a pool of repository database connections: 1. Server-Managed Connection Pool The Alerts Server uses a connection pool created and managed by the J2EE application server. (This may be referred to as a DataSource in the servers documentation.) This option is for advanced users. 2. iDashboards-Managed Connection Pool The Alerts Server creates and manages its own connection pool. This is the recommended option for most users. 2.4.2.1 Using a server-managed connection pool If a server-managed connection pool is used, it must be accessible through the application servers naming and directory service, which can also be referred to as the servers JNDI (Java Naming and Directory Interface) service. Such a connection pool is given a JNDI Name, which web applications can use to access it. To use a server-managed connection pool, only a single setting is needed in ivizgroup.properties:
db.jndiName=<JNDI name of server-managed connection pool>
An example entry might look like:

db.jndiName=idbRepository
2.4.2.2 Using an iDashboards-managed connection pool It is important to note that the presence or absence of the db.jndiName property in ivizgroup.properties determines whether or not the Alerts Server will use a server-managed connection pool. If such an entry is present, iDashboards will always try to look up and use a connection pool by that name, and it will fail if one is not available. If iDashboards is to create and use its own connection pool, then the db.jndiName setting must be removed or commented out of ivizgroup.properties. To make the Alerts Server create and manage its own pool of connections to the repository database, four settings are needed in ivizgroup.properties:

db.user=<database username to connect with> db.password=<database password to connect with> db.driverClass=<The Java class name of the JDBC driver to use> db.url=<The URL of the repository database>
15
Additonally, three optional properties may be specified:

db.maxConnections=<maximum size the connection pool may grow to> db.validateConnections=<true or false> db.password.encrypted=<true or false>
The db.user and db.password properties are the credentials used to connect to the repository database. As mentioned in the iDashboards Administrators Manual, the database user account that the Alerts Server connects with must have SELECT, INSERT, UPDATE and DELETE privileges on the repository tables. The db.driverClass and the db.url properties depend on the type of database and the JDBC drivers used to connect to it. The documentation for the JDBC drivers should be consulted when entering values for these properties. For information on JDBC drivers, see Appendix A of the iDashboards Administrator's Manual. The db.maxConnections property indicates the maximum number of connections that will be created by an iDashboards-managed connection pool. If this property is missing or blank, a default value of 20 will be used. Connections will only be created and added to the pool on an as-needed basis, so the maximum number of connections may never be reached unless the Alerts Server console is being simultaneously accessed by many users. The db.validateConnections property indicates whether or not connections should be tested when they are returned to the connection pool after use. If true, then a test query will be run on each connection when it is returned to the connection pool, and if it fails, the connection will be considered dead and removed from the connection pool. Since there is a small performance cost associated with testing connections, this property should be set to true only in cases where the repository database may go temporarily offline while the Alerts Server remains online. The db.password.encrypted property is set to true to indicate that the password set with the db.password property has been encrypted with the idb_encrypt tool. This is a command line tool shipped with iDashboards that can encrypt a password, so it can be included in the ivizgroup.properties file without being revealed to unauthorized persons who may have access to the file. If the value for db.password.encrypted is anything other than true (case-insensitive), then the password is assumed to be in cleartext. For information on encrypting passwords with idb_encrypt, see the iDashboards Administrator's Manual. 2.4.3 Troubleshooting The first step in troubleshooting problems with ivizgroup.properties is to make sure that iDashboards is able to locate it at runtime. Although you wont be able to login and use iDashboards until ivizgroup.properties has been properly configured, you will be able to view the Alerts Server consoles login screen, which, if the suggested defaults have been used,
16
should be at http://<hostname>/idbalerts. 5 The path to the ivizgroup.properties file is also displayed on this screen, along with a Reload link that will reread the contents of the file. The Reload link should only be used while troubleshooting problems with the ivizgroup.properties file or connecting to the repository database. Once a connection to the repository database has been established, hitting the Reload link will have no effect on the current connection, and any changes to the connection properties will require a server restart to take effect.
2.5 Installing the License File

NOTE: If the Alerts Server is being deployed to the application server where iDashboards has already been installed, this step may be skipped. The Alerts Server will use the license file from the same location as iDashboards. In order for iDashboards to function properly, the iDashboards license file, named idashboards.lic, should be copied to the <IVIZGROUP HOME> directory. The default location of the license file, however, can be overridden. iDashboards looks for the license file in the following locations, in the order listed, and the first one it finds will be the one used: 1. It will search the application servers Java classpath 6 for a file named idashboards.lic. 2. It will check for a Java system property called idashboards.license, which, if present, must be set to the full path (including filename) of the idashboards.lic file. 3. It will check in the <IVIZGROUP HOME> directory for a file called idashboards.lic. 4. It will check in the current working directory of the J2EE application server for a file named idashboards.lic. After iDashboards has located and read the license file, its location will be displayed near the bottom of the iDashboards administrative login screen.
2.6 Deploying the Application

The idbalerts.war file is located in the bin directory on the installation CD. The procedure used to deploy the WAR file depends on the type of J2EE application server used. Since the Alerts Server can be installed on a variety of different application servers, it would be impossible to document here the exact steps required for each one. Deployment of a WAR file is usually a straightforward process, however, which should be thoroughly explained in the application servers documentation. The process may involve copying the WAR file to a
5
The URL for the administration login screen may vary according to how your application is deployed. See section 2.6, Deploying the Application for more information. An explanation of the Java classpath is beyond the scope of this document, and installing the idashboards.lic file in the Java classpath is not recommended.
iDashboards Alerts Manual specific directory and restarting the server, or uploading the WAR file to the application server through a web interface. Some manual editing of server configuration files may be required. Note: If the bundled version of Apache Tomcat is being used as the application server, the deployment process is documented in Appendix A of this manual. 2.6.1 Choosing a Context Root Regardless of the application server used to host the Alerts Server, it must be assigned a context root within the servers URL space. Conceptually, the context root can be thought of as a subdirectory beneath the servers root URL, which forms the root of the web applications URL space. This allows multiple web applications from different sources to be deployed to the same application server without URL conflicts. It is recommended that /idbalerts be used as the context root for the iDashboards web application. Since the Alerts Server WAR file is named idbalerts.war, some application servers (such as Tomcat) will automatically default its context root to /idbalerts, so choosing that can simplify the deployment process.
17
2.7 Logging into the Alerts Server Console

After the alerts server has been deployed to the application server, the Alerts Server console can be logged into through a Web browser. If the application server is running on intranet.mycompany.com, and /idbalerts was used as the context root, the URL for the Alerts Server console login screen (shown in Figure 2-1) would be: http://intranet.mycompany.com/idbalerts If the application server is listening for connections on a port other than 80, the port number must be included in the URL For example, the default port used by Apache Tomcat is 8080, which would make the URL: http://intranet.mycompany.com:8080/idbalerts Any iDashboards user account with the admin role can log into the Alerts Server console.
18
Figure 2-1
19
System Configuration
Various aspects of the Alerts Server can be controlled through the system configuration screens of the Alerts Server console. Some of these aspects, such as severity levels, are discussed in detail in other chapters of this manual; those that do not merit an entire chapter are discussed here. The system configuration screens are accessed by clicking SYSTEM on the application menu, as shown in Figure 3-1.
Figure 3-1
3.1 System Settings

System settings are global settings used to control the Alerts Servers behavior. They are managed through the System Settings screen, which is the first screen displayed when SYSTEM is clicked on the application menu. The System Settings screen can also be accessed by clicking the System Settings tab that appears on the other system configuration screens. System settings are grouped according to their function into setting categories. A dropdown list of the available setting categories appears near the top of the System Settings screen. When a category is selected, a list of the system settings for that category appears on the System Settings screen as shown in Figure 3-2.
20
Chapter 3: System Configuration
Figure 3-2
3.2 Modifying a System Setting

The three categories of system settings are: 1. Alerts 2. Notification Email Settings (covered in Chapter 5, Notification Email Settings) 3. SMTP Settings (covered in Chapter 5, Notification Email Settings) To modify a system setting, click its Edit icon ( ). A form similar to the one shown in Figure 3-3 will appear through which the setting can be edited. For most system settings, the value must be entered into a textbox, while for others, the value can be selected from a dropdown list. The edit form for a system setting will include a description of that setting and its valid values. After a system setting has been modified, click the Save button to save the changes, or Cancel to discard the changes and return to the system settings screen.
21
Figure 3-3
3.3 Alert Settings

Notification email settings and SMTP settings are discussed in other chapters of this manual. The settings in the Alerts category are discussed below. 3.3.1 Server Startup State This setting determines the initial state of the server upon startup. The two possible values are:
1. Running (default) The Alert Monitor Thread will be started, and the server will check for alerts according to its schedule. 2. Paused The Alert Monitor Thread will be in the paused state when the server starts up. It will need to be started manually through the STATUS screen of the Alerts Admin application.
3.3.2 Alert Instance Retention (Days) This setting indicates the number of days an alert instance will be kept before it "ages out" of the alert queue and is deleted from the repository database. Allowable values are from 1 to 9999. If the setting is left blank, then alert instances will remain in the queue indefinitely. Note: This setting will not remove or alter alert configurations. The default is null. 3.3.3 Browser Alert Check Interval (Minutes) This setting indicates the interval, in minutes, in which a users Alerts dashboard will check for new alert instances. Allowable values are from 1 to 60. The default is 1 minute. 3.3.4 Maximum Displayed Alert Instances This setting indicates the maximum number of alert instances that will be displayed in a user's Alerts dashboard. If the number of alert instances for a user exceeds this maximum, the newest ones will be given priority. Allowable values are from 20 to 200.The default is 50 instances.
22
Chapter 3: System Configuration
3.4 Log Settings

Log settings are managed through the Log Settings screen. The Log Settings screen can be accessed by clicking the System Logs tab on any of the system configuration screens where it appears (see Figure 3-4).
Figure 3-4
When the iDashboards server is started, the initial log settings are read from the ivizgroup.properties file, and if they are not present, the defaults shown in Figure 3-4 are used. Once the server has been started, the settings can be changed through the Log Settings screen, however, changes made will not persist beyond a server restart. Under normal operating circumstances, the settings shown in Figure 3-4 should be used. Changes made to log settings are not applied until the Apply button has been clicked. The available settings are: 3.4.1 General Level This setting determines the types of log messages that will be written to the log file. Each level can be thought of as a threshold, with Debug being the lowest and Error the highest. When a level is selected, all messages categorized at that level and above will be written to the log. The available levels are as follows: Debug This is the most verbose setting, and could impact system performance on a busy server. Debug log messages are generally only useful to an iDashboards support representative, so this level should only be used when troubleshooting problems.
iDashboards Alerts Manual Info (default) This is a far less verbose level than Debug, which writes information about the operating environment to the log when the iDashboards server is started. It is the recommended level for normal operations. Warn In addition to error messages, this level will write warning messages about server events that are noteworthy but not critical. Error This is the least verbose log level. It will only write messages to the log when a critical error occurs.
23
3.4.2 XML Logging Enabled When this checkbox is checked, XML that passes between the Alerts Server Console screens and the server is written to the log file. It causes very verbose output which is only useful to an iDashboards support representative, so it should remain unchecked except for troubleshooting purposes. The default is unchecked. 3.4.3 HTTP Request Logging Enabled When this checkbox is checked, information about the HTTP requests that are sent to the Alerts Server from the Alerts Server Console screens is logged. As is the case with XML logging, it causes very verbose output which is only useful to an iDashboards support representative, so it should remain unchecked except for troubleshooting purposes. The default is unchecked. 3.4.4 Max File Size This is the maximum size to which a log file will be allowed to grow before it is overwritten by a new one or archived. The default is 10Mb. 3.4.5 Max Backup Files This setting indicates the maximum number of archived log files that will be kept. When an active log file, named idbalerts.log grows to its maximum allowed size, it will be renamed with to idbalerts.log.1 and a new idbalerts.log file will be started. If there is already a file named idbalerts.log.1 in the logs directory, it will be renamed idbalerts.log.2, and so on, up to the maximum number of archived log files. When the maximum number has been reached, the oldest archived log file will be discarded. The default is 10.
3.5 Downloading Log Files

The active log file (idbalerts.log) and any existing archived log files (idbalerts.log.1, idbalerts.log.2, etc.) can be downloaded through the Log Settings screen. To do so, select the desired files from the list at the right of the screen and click the Download button. The selected files will be bundled into a ZIP file by the server and downloaded.
3.6 Sending Log Files to iDashboards Technical Support

When working with iDashboards technical support to troubleshoot problems with the Alerts Server, it is useful to provide the Alerts Servers log file(s) to the support representative. Problems can be diagnosed and corrected more expeditiously if these steps are followed prior to contacting iDashboards technical support:
24
Chapter 3: System Configuration 1. Set the General Level to Debug, and enable XML logging and HTTP Request Logging. 2. Recreate the error condition through the User Application or the appropriate Administrator Application screen. 3. Download the idbalerts.log file, and the idbalerts.log.1 file if it exists, as described in section 3.5, Downloading Log Files. 4. Email the ZIP file containing the log file(s), along with a description of the problem (and steps to recreate it if possible) to support@idashboards.com.
3.7 Browser Alert Checks Enabled

This setting can be found in the iDashboards Administrator Application, under the SYSTEM tab. Note that this is different from the Alerts Administrator Application that has been discussed so far in this chapter. This setting determines whether or not browsers will contact the iDashboards server periodically to check for new alerts. The default setting is TRUE; however it can be set to false when the Alerts server is offline for an extended period of time, to reduce the load on the iDashboards server. This setting is sent to a user's browser upon login, so changing it will have no effect on active login sessions.
Figure 3-5
25
Managing Severity Levels
Every alert has a severity level associated with it, which indicates whether the news brought by the alert is good or bad, and to what degree it is good or bad. A severity level is represented by an integer value from 0 to 999. Although the meaning associated with a severity level is determined by the administrator who configures it, the suggested convention is that lower numbers (0-499) should be used to indicate bad news the lower the number, the worse the news and higher numbers (500-999) indicating good news the higher the number, the better the news. In addition to its integer value, a severity has two other important attributes: The severity name a short name, for example Crisis or Monthly Sales Goals Reached. The severity color a color that is displayed on alert notifications.
The name and color associated with a severity level can be changed, but its integer value cannot. In its default configuration, the Alerts Server provides four built-in severity levels:
Level 300 400 600 700 Name Crisis Caution Good Excellent Figure 4-1 Color Red Yellow Blue Green
These levels cannot be deleted; however their names and colors can be changed. In addition to the default severity levels, an administrator can add new ones and delete existing (non-built-in) ones. Severity levels are managed through the Severity Levels screen. To access the Severity Levels screen, select SYSTEM from the application menu, as shown in Figure 4-2, and then click the Severity Levels tab as shown in Figure 4-3.
26
Chapter 4: Managing Severity Levels
Figure 4-2
Figure 4-3
4.1 Adding a Severity Level

To add a severity level click the Add New button on the Severity Levels screen. This will open the Severity Level edit screen, shown in Figure 4-4. Enter an integer value from 0 to 999 for the severity level, and a name consisting of from one to 50 characters. The severity color is defined as a mixture of red, green and blue component colors. Enter an integer value from zero to 255 for each component color, or click and drag on the colors slider bar to set its value. The severity color will be displayed in the preview box to the right of the slider bars. The red, green, and blue values that make up a color are often referred to collectively as the colors RGB value. RGB values are often expressed as three concatenated 2-digit hexadecimal numbers, representing the red, green and blue values respectively. For example, a color with the red, green and blue values of 255 (FF in hexadecimal), 127 (7F in hexadecimal) and 0 (00 in hexadecimal) would be expressed as FF7F00 in hex RGB format.
iDashboards Alerts Manual In HTML, a hex RGB value is usually preceded by a pound sign (#), for example #FF7F00 . After the Severity Level Edit screen has been completed, click the Save button to save the new severity level, or the Cancel button to dismiss the screen without saving it.
27
Figure 4-4
4.2 Modifying a Severity Level

To modify a severity level, click its Edit icon ( ) on the Severity Levels screen. This will open the Severity Level Edit screen, through which the severity levels attributes (other than its integer value) can be modified. To save the changes, click the Save button, or click the Cancel button to discard the changes and dismiss the screen. Clicking the Reset button will discard the changes, but keep the Severity Level Edit screen displayed. Note: Any changes made to a severity level will be visible on any alerts that have a severity level, and all instances of those alerts.
28
Chapter 4: Managing Severity Levels
4.3 Deleting a Severity Level

Severity levels can be deleted, provided that: a.) they are not one of the four built-in severity levels shown in Figure 4-1, and b.) no existing alerts are using them as their severity level. The numbers of alerts that are using each severity level are shown in the Alerts column on the Severity Levels screen. To delete a severity level, click its Delete icon ( ) on the Severity Levels screen. If it is not a built-in severity level, and there are no alerts using it, it will be deleted immediately (without confirmation); otherwise, the operation will fail with a warning message.
29
Notification Email Settings
The iDashboards Alerts Server is capable of sending emails in response to certain events. The three types of emails sent are: Alert Notifications An alert can be configured so that an email is sent to its recipients when the alert is fired. Server Event Notifications These emails are sent to a predefined list of email addresses (which presumably belong to server administrators) when certain routine (non-error) server events occur, such as the startup or shutdown of the server. Server Error Notifications These emails are sent when certain types of errors occur on the server, such as a database error during an alert check. They are sent to the same email addresses that receive server event notifications.
5.1 Email Configuration Roadmap

For the alerts server to send email notifications, it must first be properly configured. The overall steps to accomplish this are: Configure the SMTP (Simple Mail Transfer Protocol) Settings Notification emails are sent through an external SMTP service, such as UNIX Sendmail or Microsoft Exchange Server. The Alerts Server must be configured with enough information to connect to, and if necessary, authenticate itself to the SMTP service. Configure the Notification Email Settings These settings include information such as the name and email address used in the from header of outgoing emails, the list of email addresses that will receive server event notifications, and the information that is included in the subject lines of notification emails. Configure the Email Templates This is an optional step that provides a great deal of control over the information included in the bodies of notification emails. Using email templates, notification emails can be sent in both HTML format (including images) and plain text. If this step is omitted, emails will be sent as plain text and include only a minimal amount of default information.
The following sections describe the above steps in greater detail.
5.2 Configuring the SMTP Settings

As mentioned previously, the iDashboards Alerts Server uses an external SMTP service to send emails. The settings needed to connect to the SMTP service are entered through the system settings screen. To access this screen, select SYSTEM from the application menu as shown in Figure 5-1:
30
Chapter 5: Notification Email Settings
Figure 5-1
On the system settings screen, select SMTP Settings from the Setting Category dropdown as shown in Figure 5-2:
Figure 5-2
On the SMTP Settings screen (see Figure 5-3), enter the following settings: SMTP Host This is the hostname or IP address of the machine on which the SMTP service is running. SMTP Port This is the number of the TCP/IP port on which the SMTP service is listening. (The standard SMTP port number is 25.) SMTP Service Requires Authentication Set this to Yes if the SMTP service requires authentication or incoming connections, or to No if it does not. SMTP Service User If the SMTP service requires authentication, this setting must contain the username of the user that will be used to connect to it, otherwise it should be left blank. SMTP Service Password If the SMTP service requires authentication, this setting must contain the password that will be used to connect to it, otherwise it should be left blank.
iDashboards Alerts Manual SMTP Encryption This setting determines the type of encryption (if any) used to secure the connection with the remote mail server. The options are None, SSL (Secure Socket Layer) and TLS (Transport Layer Security).
31
Figure 5-3
5.3 Configuring the Notification Email Settings

The settings for notification emails are entered through the System Settings screen. To configure the settings select Notification Email Settings from the Setting Category dropdown (see Figure 5-4):
Figure 5-4
On the Notification Email Settings screen (see Figure 5-5), enter the following settings:
32
Chapter 5: Notification Email Settings Notification Email Enabled If this setting is No, then all email notifications, for alerts and server event notifications, will be disabled. If it is Yes, then the settings in the SMTP Settings category must be properly configured to connect to the SMTP Service. Notification Email "From" Address This setting must be a valid email address that will appear in the "From" header of notification email messages, for example "alerts@mycompany.com". This setting is required if email notifications are enabled. Notification Email "From" Name This optional setting is the name that will appear before the email address in the "From" header of notification email messages, for example "iDashboards Alerts". Alert Notification Subject This optional setting is a string that will be used to build the subject line for alert notification emails. Mail macros can be used in this setting; See Section 5.5, Mail Macros for information on mail macros. Server Events Notification Threshold This setting determines what types of server events will generate emails to the addresses listed in the Server Events Notification List setting. The higher in the list a selection is, the fewer notification emails will be sent. Selecting "Disabled" will turn off all email notification of server events. Since a selection represents a threshold, each selection implicitly includes the ones above it. Server Events Notification List This setting is a list of email addresses that will receive notifications of server events, both error and non-error. Each email address should be on a separate line. Email addresses may be in plain format, for example: jsmith@company.com or in any RFC822-compliant format, for example: "Jane C. Smith" <jsmith@company.com> The combined length for all email addresses, including end-of-line characters, must not exceed 500 characters. Server Event Subject This optional setting is a string that will be used to build the subject line for non-error server event notification emails. Mail macros can be used in this setting; See Section 5.5, Mail Macros for information on mail macros. Server Error Subject This optional setting is a string that will be used to build the subject line for error-level server event notification emails. Mail macros can be used in this setting; See Section 5.5, Mail Macros for information on mail macros.
33
Figure 5-5
5.4 Configuring the Email Templates

Email templates are text files that can be used to control the content and layout of notification emails. Through the use of email templates, notification emails can be sent in HTML format (with images), plain text, or a combination of both. 5.4.1 Template Directories When the alerts server sends a notification email it will look in the template directory corresponding to the type of notification it is sending, and if the directory exists and contains a template file, it will use that template file to construct the email. Template directories are located within the directory <IVIZGROUP HOME>/templates/idbalerts. The name of a template directory determines the type of notification email it is associated with. The three possible template directories are: <IVIZGROUP HOME>/templates/idbalerts/alerts This directory holds the template files for alert notification emails-the emails sent to an alerts recipients when the alert fires. <IVIZGROUP HOME>/templates/idbalerts/events The template files in this directory are used for the emails sent to notify administrators of normal (non-error) server events, such as server startup and shutdown.
34
Chapter 5: Notification Email Settings <IVIZGROUP HOME>/templates/idbalerts/errors The template files in this directory are used for the emails sent to notify administrators of errors that occur on the server.
The template directories are not created as part of the regular install process; rather they must be created manually on the server. The location of the <IVIZGROUP HOME> directory is displayed on the home screen of the Alerts Server Console:
Figure 5-6
5.4.2 Template Files Once the template directories have been created, the template files can be prepared and placed inside them. One or both of the following files may be used: template.txt This is the template file used for plain text email messages. It should contain the text of the corresponding notification email in plain-text format, including line breaks where appropriate. template.html This is the template file used for HTML email messages. It should contain the text of the corresponding notification email in HTML format.
It is the presence or absence of these template files that determines what type of email is sent: If neither template file is present, emails will be sent in plain-text format using the default content. If only template.txt is present in a template directory, emails will be sent in plain-text format, using content defined in template.txt. If only template.html is present in a template directory, then emails will be sent only in HTML format, using content defined in template.html. If both template.txt and template.html are present in a template directory, emails will be sent as multipart/alternative MIME messages that include both the plain text and HTML messages, and mail readers can choose which to display based on their capabilities.
Sample template files are included on the distribution CD-ROM, in the file templates.zip, which is located in the templates directory. To install these sample templates, unzip the
iDashboards Alerts Manual templates.zip file in the <IVIZGROUP HOME> directory, making sure that the directory structure inside the templates.zip file is preserved. Information specific to a particular alert, event or error can be included in a notification email through the use of mail macros, which are explained in Section 5.5, Mail Macros. 5.4.3 HTML Supporting Files As previously mentioned, HTML messages may include images, as well as other supporting files such as cascading stylesheets. To include these within an HTML message, place them into the appropriate template directory, and they will be included with the notification email as attachments. The following table lists the types of files that may be included:
Filename Extension(s) .gif .jpg, .jpeg .png .css MIME type image/gif image/jpeg image/x-png text/css Figure 5-7 File Type Image Image Image Cascading Stylesheet
35
Within an HTML template, URLs that reference attachments should consist of the bare filename of the attachment, for example:
<img href="logo.gif"> <link rel="stylesheet" type="text/css" href="styles.css"> div.banner {background-image:url(banner.gif); background-repeat:no-repeat;}
HTML messages may also display images that are not attached to the message, but rather loaded from a remote server, for example:
<img href="http://www.mycompany.com/images/logo.gif">
It should be noted that many email readers restrict the display of images in HTML messages as a security precaution.
5.5 Mail Macros

Mail macros are used to include information about a particular alert or event in a notification email pertaining to that alert or event. A mail macro is a special string of characters that begins with ${ followed by a specific keyword, and ends with }. An example of a mail macro is:
${ALERT_NAME}
When the alerts server sends a notification email based on a template file, it will first scan the contents of the template file for mail macros, and replace each one it finds with what is
36
referred to as its expanded value. In the case of the ${ALERT_NAME} macro, the expanded value would be the name of the alert to which the notification email pertains. The subject lines of notification emails, as configured in the System Settings screen, are also scanned for the presence of mail macros, and any that are found are expanded appropriately. Not every macro has an expanded value for every type of email. For instance, the ${ALERT_NAME} macro would not be available in an email notifying an administrator that the server is shutting down, since no specific alert would be associated with that event. When a macro has no actual expanded value, it is replaced with a zero-length string. Mail macros are case-insensitive, so ${alert_name} would be equivalent to ${ALERT_NAME} in template files or subject lines. The suggested convention, however, is to use all uppercase letters for mail macros to make them more visible. In the remainder of this section, the various mail macros that may be used in template files are described. 5.5.1 Alert Macros Alert macros can be used to include information about an alert in its notification emails. This information is also available in error notification emails, when an error is related to a particular alert; therefore alert macros should also be used in error notification templates.
${ALERT_ID} ${ALERT_NAME} ${ALERT_MESSAGE} ${ALERT_DESCR} ${SCHEDULED_CHECK_TIME} ${ACTUAL_CHECK_TIME} ${ALERT_VISIBILITY} ${SEVERITY} ${SEVERITY_NAME} ${SEVERITY_RGB} ${SEVERITY_RGB_INVERT} Alert ID. Alert name. Alert message. Alert description. The time at which the alert was scheduled to be checked. The time at which the alert was actually checked. The alerts visibility (Public for non-private alerts, or Private for private alerts.) The alerts severity level (the numeric value.) The name given to the alerts severity level. The severity color, in HEX RGB format, suitable for use in HTML emails. An example would be FF0000. The bit-wise inverse of the alert's severity color, in HEX RGB format. In many cases, this is suitable for use as a foreground or background color in contrast with the severity color.
5.5.2 Chart Macros Chart macros can be used to include information about an alerts associated chart in its notification emails. This information is also available in error notification emails, when an error is related to a particular alert.
${CHART_ID} Chart ID.

${CHART_TITLE} ${CHART_NAME} ${CHART_CATEGORY} Chart title. Chart name (what is displayed for the chart in the Chart Open dialog.) Name of the chart's category.
37
5.5.3 Event Macros Event macros can be used in any email sent by the iDashboards Alerts Server to notify administrators of a server event, either a normal event (such as the server starting) or an error event.
${EVENT_ID} ${EVENT_SUBJECT} ${EVENT_MESSAGE} ${EVENT_LEVEL} ${EVENT_QUEUE_ID} This is the ID used to identify this type of event. This value appears in the Event ID column on the Server Status screen. A short phrase describing the type of event. This appears in the Subject column of the Server Status screen. A message specific to this individual event. This appears in the Message column of the Server Events screen. The "Level" of the event, either INFO, WARNING or ERROR. This is a string consisting of the Event ID, possibly followed by additional characters that more specifically identify the type of event. This string is used internally by iDashboards and is generally not useful to administrators or end users. This is the maximum number of emails that will be sent for events with a particular Event Queue ID. A value of 0 or below indicates there is no limit, and an email will be sent for each occurrence of the event with the given Event Queue ID. This is used to prevent an administrator from receiving numerous identical emails related to a server error that occurs over and over again. This is the date and time when the event occurred.
${EVENT_MAX_EMAILS}
${EVENT_TIMESTAMP}
5.5.4 Error Macros Error macros can be used in any error notification email.
${ERROR_MESSAGE} ${EXCEPTION_NAME} This is the error message constructed by the iDashboards Alerts server. If the error was the result of a Java "exception", this is the name of the exception class. This information is useful to iDashboards support personnel when troubleshooting a server error. This is the error message provided by the Java exception, if one exists. This is the "stacktrace" of the Java exception, which shows the exact point in the server code where the error occurred. This information is useful to iDashboards support personnel when troubleshooting a server error. If this macro is included in an HTML template file. It should be placed between <pre></pre> tags to make it more readable.
${EXCEPTION_MESSAGE} ${EXCEPTION_STACKTRACE}
38
5.5.5 Miscellaneous Macros These macros can be used in any email sent by the iDashboards Alerts Server.
${SERVER_NAME} ${TEMPLATE_DIRECTORY} ${DOLLAR} The hostname of the machine on which the iDashboards Alerts Server is running. The path to the directory where the template file used to construct the notification email is located. This macro always expands to a dollar sign. It can be used when an email needs to contain the literal string ${".
39
Server Operation
Within the regular iDashboards Server, nothing much happens unless a user or administrator does something in a browser that causes a request to be sent to the server. Otherwise, it sits idle, waiting for user input. The Alerts Server is different. Even when there are no administrators logged in, the server can be busy, checking alerts, creating alert instances, sending notification emails, etc. If an error occurs on the regular iDashboards Server, it is usually in response to some user action, and is immediately noticed by the user. Within the Alerts Server, however, an error can occur at any time and go unnoticed, and as a result, alerts might fail to fire when they should. The Alerts Server provides a window through which its inner workings can be observed. This window is the Server Status screen of the Alerts Server console. To access it, click Server Status in the application menu, as shown in Figure 6-1. This screen will show a list of server events (see Figure 6-2).
Figure 6-1
Figure 6-2
40
Chapter 6: Server Operation
6.1 Pausing and Restarting the Server

At any given moment, the Alerts Server will be in one of two possible states: Running In this state, the Alerts Server is performing all of its normal activities, such as alert checks, sending notification emails, etc. Paused In this state, the Alerts Server does not perform activities such as alert checks or sending notification emails, however, the Alerts Server console is still fully functional.
In its default configuration, the Alerts Server enters the running state when it is started. 7 When it is in the running state, the Server Status screen will display the line, Current State: RUNNING, and the rightmost button (referred to herein as the toggle button) will be labeled Pause Server. A running server can be paused by clicking the toggle button. When the Alerts Server is in the paused state, the Server Status screen will display Current Status: PAUSED and the label on the toggle button will say Start Server. It can be placed back into the running state by clicking the toggle button. Normally, the Alerts Server should be left in the running state. The paused state is generally only useful when performing troubleshooting or certain configuration changes.
6.2 Understanding Server Events

The most prominent feature of the Server Status screen (shown in Figure 6-2) is the list of server events. A server event can be any type of noteworthy occurrence, such as the server being paused or a database error. A server event has the following attributes: 6.2.1 Event ID Each server event is assigned a code referred to as the event ID, which identifies the type of event that it is. And event ID consists of an event category, such as MONITOR, and a number, separated by a hyphen. The event category is used to identify approximately where in the system the event occurred. For example, the MONITOR category is for events that occur on the monitor thread, which is the main thread that runs continually inside the server, checking alerts and performing other tasks. The number portion of the event ID uniquely identifies the type of event within an event category. For example, MONITOR-7 is the event ID used to indicate that a routine alert check occurred.
The initial state can also be set to paused through the Server Startup State system setting. See section 3.3, Alert Settings, for more information.
iDashboards Alerts Manual 6.2.2 Level Each server event has one of the following three levels: INFO This level is used for routine events. INFO-level events are displayed in green text in the event list. WARNING This level is for events that occur during normal operation, but should be noted by a server administrator. WARNING-level events are displayed in the yellow text in the event list. ERROR This level is used for abnormal, unexpected events such as a database error that occurs during an alert check. ERROR-level events are displayed in red text in the event list.
41
6.2.3 Timestamp The event timestamp is the date and time at which the event occurred. 6.2.4 Subject The event subject is a short phrase describing the event. 6.2.5 Message The event message is a short sentence that contains information about the event.
6.3 Refreshing the Event List

To refresh the event list and display the events that have occurred since the screen was loaded or was last refreshed, click the button labeled Refresh. The event list can also be made to automatically refresh at a specific interval, by selecting the interval from the dropdown labeled Autorefresh Rate. The freshness of the event list is indicated by the timestamp labeled Last Refresh. This timestamp represents the servers system time when the event list was last refreshed.
6.4 Filtering the Event List

The event list can be filtered to only display events of certain, selected levels. This is accomplished by checking or unchecking the checkboxes for the different event levels that appear just above the event list, as shown in Figure 6-3.
Figure 6-3
42
6.5 Troubleshooting Error Events

In some cases, an ERROR-level event displayed in the event list may contain hyperlinks to other screens that display additional information about the error or the alert it is associated with. For example, if the events level code, ERROR, is followed by (!) (Figure 6-4) the exclamation mark can be clicked on to display the Java stacktrace that was generated by the error.
Figure 6-4
Although stacktraces appear undecipherable to almost anyone other than Java developers, they usually provide clues as to the cause of an error. For example, the stacktrace shown in Figure 6-5 says Connection timed out, indicating that the Alerts Server was unable to connect to the SMTP service to send notification emails. A stacktrace can also be copied and pasted into an email to support@idashboards.com to assist iDashboards support staff in troubleshooting errors.
Figure 6-5
When an error is associated with a specific alert, the event message in the event list may be followed by (View Alert)., as shown in Figure 6-6. This is a hyperlink that can be clicked to open the administrative screen for the errant alert, through which the alert can be temporarily disabled or permanently deleted.
Figure 6-6
43
6.6 Event Retention

During normal operation, the Alerts Server is frequently recording new events in the event list. Because of this, one would expect that over time, the event list would grow extremely large, yet it does not. This is because only a certain number of events with a given event ID are retained in the event list. This number is referred to as the retention depth for that event ID. When the number of events with a particular event ID exceeds the retention depth for that ID, the oldest ones are removed from the list and discarded, keeping the entire event list at a manageable size. The retention depth for an event ID is normally not of concern to an Alerts Server administrator. It can be viewed, however, by holding the mouse cursor over the event ID in the events list. This will produce a tool tip, similar to the one shown in Figure 6-7, displaying the retention depth for the event ID.
Figure 6-7
6.6.1 Qualified Event Retention For some error events, the retention depth is not applied to the event ID alone, but rather to the event ID combined with some hidden qualifying information. For example, if the error event is related to a particular alert, that alerts ID number might be used as the qualifying information. So, if the event ID is MONITOR-9 and the alert ID is 714, the hidden, qualified event ID to which the retention depth would apply would effectively (if not actually) be MONITOR-9-714. And if the retention depth for MONITOR-9 events is 1, that really means that one MONITOR-9 event related to alert #714 will be retained in the list, but at the same time a MONITOR-9 related to alert #905 might be retained in the list as well. This keeps important events from being pushed out of the event list before they can be viewed by an administrator. If a retention depth applies to a qualified event ID as described above, it will be followed by an asterisk (*) in the event ID tool tip, as shown in Figure 6-8.
Figure 6-8
44
6.7 Email Events

Certain event types are designated as email events. When an email event occurs, a notification email will be sent to the designated Alerts Server administrators, provided that: 1. The Alerts Server is properly configured to send event notification emails. 2. The level of the event (INFO, WARNING, or ERROR) is at or above the configured threshold at which the event notification emails are sent. To determine whether or not an event in the list is an email event, hold the mouse cursor over its event ID until the tool tip appears. It will include the line Email: true for email events (Figure 6-8), and Email: false for non-email events (Figure 6-7).
45
Alert Administration
Alerts are normally created and maintained through the iDashboards User Application as described in Chapter 8, User Application: Creating Alerts in Charts. The Alerts Server console, however, provides screens through which limited modifications can be made to existing alerts, specifically: Alerts can be enabled or disabled. When disabled, an alert is not checked by the Alerts Server. Email notifications can be enabled or disabled for individual alerts. Alerts can be deleted.
Administrative access to alerts is independent of the iDashboards security framework. An administrator can perform the above modifications on any alert in the system, regardless of the category to which the alerts chart belongs, or whether the alert is public or private. The alert administration screens are accessed by clicking ALERTS in the application menu, as shown in Figure 7-1. This will display the Alerts Search screen, shown in Figure 7-2.
Figure 7-1
Figure 7-2
46
Chapter 7: Alert Administration
7.1 Retrieving an Alert

Before an alert can be modified, it must first be retrieved from the repository. If the alert's ID number is known, it can be retrieved directly. If the ID number of the alerts associated chart is known, the alert can be selected from a list of alerts associated with that chart. If neither the alert ID nor chart ID is known, then the alert can be browsed for. 7.1.1 Searching by Alert ID The alert ID is the number that uniquely identifies an alert in the iDashboards repository. In the iDashboards User Application, the alert ID is visible on both the summary panel of the alert configuration dialog (Figure 7-3), and in the alert panel of the alerts dashboard (Figure 7-4) when an instance of the alert is being viewed. To retrieve an alert with its alert ID, enter the ID in the appropriate text box on the Alerts Search screen and click the button labeled "Search by Alert ID". If the alert with the given ID exists in the repository, it will be displayed on the Alert Administration screen, shown in Figure 7-7.
Figure 7-3
Figure 7-4
iDashboards Alerts Manual 7.1.2 Searching by Chart ID The Chart ID is the number that uniquely identifies a chart in the iDashboards repository. In the iDashboards User Application, it is visible near the top of the Chart Properties window, under the Features tab for a given chart (see Figure 7-5). Enter the Chart ID in the appropriate text box on the Alerts Search screen and click the button labeled "Search by Chart ID". If the chart exists and has one or more alerts configured, the Chart Alerts screen will be displayed, showing a list of all the alerts configured for that chart, as shown in Figure 7-6.
47
Figure 7-5
Figure 7-6
When an alert appears on the Chart Alerts screen, it can be displayed in the Alert Administration screen by clicking its Edit icon ( Chart Alerts screen by clicking its Delete icon ( confirmation dialog that appears. ). An alert can also be deleted from the ) and then clicking the OK button on the
NOTE: The Alert ID and the Chart ID can also be included in an alert notification email. See Section 5.5, Mail Macros for more information.
48
Chapter 7: Alert Administration
7.1.3 Browsing for an Alert To browse for an alert, click the button labeled Browse Categories on the Alerts Search screen. This will display a list of categories in the iDashboards system that has charts with alerts, along with the total number of alerts for each category. Clicking the View Charts link for a category will display a list of the charts within that category that have alerts, along with the number of alerts for each chart. Clicking the View Alerts link for a chart in the list will display the Chart Alerts screen (Figure 7-6) for that chart.
7.2 Modifying an Alert

Administrative modifications can be made to an alert through the Alert Administration screen, shown in Figure 7-7. To enable or disable the alert or its email notifications, check or uncheck the checkboxes labeled "Enabled" or "Email" appropriately, and click the Save button. To delete the alert, and all of its active instances, click the button labeled "Delete Alert" and click the OK button on the confirmation dialog that appears.
Figure 7-7
7.3 Importing and Exporting Charts with Alerts

Charts and dashboards can be exported from one iDashboards repository and imported into another iDashboards repository. This process is only performed through the iDashboards Administrator Application and is detailed in the iDashboards Administrators Manual. Charts that contain alerts will retain their alerts when exported if the alerts are not private. Private alerts will not be exported. Also, specific group notifications will not be preserved as iDashboards will not reconcile groups. The user will have to edit the alert after it has been imported and decide which groups will be notified
49
User Application: Creating Alerts in Charts
To recap, Alerts are functionality in iDashboards that notify you when certain conditions arise in your data. You utilize the alerting capabilities to set the conditions to monitor for, and it notifies you when they occur. iDashboards Alerts provides the following capabilities: Near/Real-time monitoring of changing data values. Highly flexible monitoring criteria, based on easily-defined rules. Robust scheduling for monitoring by month, day, hour and minute. Seamless integration into the dashboard/chart framework. Flexible notification options, sending on-screen and email messages to individuals or groups.
You can add an alert to any chart that has dynamic data connectivity and does not have a filtering constraint. Every alert includes: One or more rules, describing the data values to watch for. A schedule, describing when to check the data values, and how often. A list of groups, defining the users who will be notified when the rules are satisfied. An alert category, or severity, defining the urgency of the alerts conditions.
There are two parts to iDashboards Alerts: the Configure a Chart Alert window and the Active Alert Notification window. The first allows you to define the rules and schedule the conditions you need to monitor. The second notifies you when those conditions are met. When you create an alert on a chart, iDashboards follows the alerts schedule. At the selected dates and times, it checks your data against the alerts rules. If the rules are satisfied, the alert triggers, and iDashboards notifies you (or any other users you choose) with an on-screen message and an optional email message. To manage the on-screen notifications, iDashboards uses a special alerts dashboard. It looks similar to the dashboards youre used to seeing, but instead of charts, it displays a list of all the alert notifications youve received. In the alerts dashboard, you can sort, select and delete notifications; expand them for more information; and even display the charts that triggered them. The following sections describe how to configure alerts, and how to handle alert notifications.
50
Chapter 8: User Application: Creating Alerts in Charts
8.1 Configuring Alerts

Every alert is associated with a single chart, but not all charts can have alerts. For instance, a chart with static data has no need for an alert, as its data never changes. If you try to create an alert on a chart with static data, an error message will display (see Figure 8-1).
Figure 8-1
Alerts have the same requirements for access, creation and modification as charts. In general, if you can modify a chart, then you can also create alerts on it or edit its existing ones. Further, even if you do not have Save access on a charts category, you can still create an alert on the chart, although it must be a private alert. That is, it can notify only you and not any other user(s) who have access to the same chart. 8.1.1 Configure Alerts Menu Option To see or edit a charts alerts, or to create a new one, select Configure Alerts from the Chart Menu or the charts right-click menu (see Figure 8-2 and Figure 8-3). The Alerts dialog will open, and display the names of all the alerts associated with this chart (see Figure 8-4). From this dialog, you can create a new alert, or edit or delete an existing one.
51
Figure 8-2 Figure 8-3
Figure 8-4
Note: Some of the alerts listed in this dialog may be marked with a stylized letter P. These are private alerts, meaning that when their conditions are satisfied, they notify only you. You can make any alert private. Any chart in your Personal category can have only private alerts. There are a few other criteria regarding private alerts, described in Section 8.1.3, Alert Notifications.
52
If you select an existing alert and click the Delete button, youll be warned that deleted alerts cannot be retrieved (see Figure 8-5). If you choose to continue, the selected alert will be deleted.
Figure 8-5
When you click on the New button, or select an alert and click the Edit button, the Configure a Chart Alert dialog opens. This is where you set up an alert to meet your requirements, and is described in the following sections. 8.1.2 Alert Configuration The Configure a Chart Alert dialog box gives you access to all aspects of a single alert (see Figure 8-6). Depending on the alert, the dialog will have three or four main editing tabs, and one summary tab. The four editing tabs are Properties, Rules, Schedule, and Users. (If the alert is necessarily a private alertfor example, if it is on a chart in your Personal categorythen the Users tab is not present.) The Summary tab is always available to provide a textual description of the alerts current definition.
53
Figure 8-6
Each tab has certain requirements for validity, and will inform you if they are not met. For example, every alert needs a name. If the space for it on the Properties tab is empty, then the label of that tab, Properties appears in red, as does the label on Name box (see Figure 8-7). If all the requirements for a tab are satisfied, the tabs label appears in black. If all tabs are satisfied, you can save the alert. Otherwise, you can correct the conditions that made the alert invalid, or cancel the dialog box. Proceed to other tabs by clicking the Continue button or by clicking on the individual tabs.
Figure 8-7
54
The following sections give more information on the individual tabs. 8.1.2.1 The Properties Tab The Properties tab (see Figure 8-8) has places for the alerts name, description and a few other details. They are: Name (required): Up to 100 characters. This is the name by which the alert appears in the Alerts dialog. Description: Up to 150 characters. This is a brief description of the alert, for your convenience. Message to Display (required): Up to 500 characters. This is the message that will appear, when the alerts conditions are satisfied, in both the on-screen and email notifications. Severity: The category of this alert. Each severity level is associated with a color. By default, Crisis is associated with red, Caution is associated with yellow, Good is associated with blue, and Excellent is associated with Green but your iDashboards Administrator can set up a number of categories from which you can choose. This color will display as part of the chart notification. Action: Describes what happens when the alerts conditions are satisfied. Display an Alert Message is always selected, and you may also select Send Email. Any email messages are sent to the user defined in the User Settings dialog (see Section 8.1.2.4, The Users Tab) by the iDashboards Administrator. The email address for each user is configured by the iDashboards Administrator as part of the user creation process. See Chapter 7 Managing Users in the iDashboards Admin Manual for more information. Temporarily disable this alert: When this option is selected, iDashboards stops checking the alerts conditions. Any existing notification messages from this alert are unaffected. If you deselect this option, iDashboards resumes checking the alerts conditions according to its schedule.
55
Figure 8-8
8.1.2.2 The Rules Tab Rules are at the core of every alert. They describe the conditions that trigger the alert, and cause it to notify you that they have been satisfied. On the Rules tab (see Figure 8-9), you create, modify, and arrange rules so that they accurately describe the conditions youre interested in. Each rule, as presented in the Rules tab, looks like the example in Figure 8-10, and consists of several components.
56
Figure 8-9
Figure 8-10
From left to right, these are: Handle: A blue sphere you can use to move the rule up and down the list for higher or lower precedence. Click and drag the handle to move the rule to a new location relative to the other rules. Column Name (required): The name of one of the columns in the alerts chart. When the alert is checked, the rule compares the value in the selected column to the specified Value. Comparison Operator (required): This controls the comparison between the column value and the specified value. The choices are Less Than (<), Less Than or Equal (<=), Equal (=), Not Equal (<>), Greater Than or Equal (>=) and Greater Than (>).
iDashboards Alerts Manual Value (required): This is the number or text value to which the column value is compared. Comparing text values makes most sense for the Equal and Not Equal operators. Using the other operators on text values is not prohibited, but the results may not be what you expect. If the comparison is successful, the alert is triggered. If no value is specified, the space displays * Enter value *, in red, and the rule is invalid, making the whole Rules tab incomplete. Add Rule Button: Clicking this button creates a new empty rule just below the one clicked, with an and relation between them. Remove Rule Button: Clicking this button deletes the rule in which the button appears. If there is only one rule present, the Remove button is not present.
57
Figure 8-11
An alert can have as many rules as you wish to create. Each time the alert is checked, iDashboards evaluates all of its rules to determine if the alert will be triggered. Between any two adjacent rules is a relation, either and or Or. When iDashboards checks an alert, it evaluates all the rules, and then combines the results logically, according to the relations, to arrive at a result.
58
The and relation takes precedence over the Or relation. You can see this, and how rules are logically combined, by looking at the example in Figure 8-11. When iDashboards checks this alert, it evaluates all four rules. Then it combines the results of the top two rules with a logical AND, and does the same with the results of the bottom two. Finally, it combines the results of those two operations with a logical OR to arrive at a result, which determines whether or not the alert is triggered. To change the order in which iDashboards evaluates and combines the rules arrange them by clicking their handles and dragging them around. You can also drag the Or relations: dragging an Or and dropping it between two rules that have an and relation replaces that relation with the Or. Likewise, dragging an Or away from between two rules leaves an and in its place. Note that the bottom of the list of rules is a grey Or relation. Its there to be used as needed. If you drag a rule below it, it becomes a real Or relation and a new grey Or appears at the bottom. Likewise, if you drag the grey Or between two rules, a new Or appears there, and the grey one remains at the bottom. 8.1.2.3 The Schedule' Tab After the rules, the most important part of an alert is its schedule. The rules tell the alert what to look for while the schedule tells it when to look and how often. Another part of the schedule, Reactivation, controls how soon iDashboards resumes checking the alert after its been triggered. Note: The flexibility of iDashboards Alerts scheduler makes it possible for an alert to be checked as infrequently as once per year, as frequently as once every minute, or anything in between. To prevent overloading the system, a private alertone that notifies only the user who created the alertcan be checked at most once per hour. iDashboards assigns the minute value to this alerts schedule. The user cannot change that value. The Schedule tab has either four or five sections: Months, Days of Week, Days of Month, Hours, and (possibly) Minutes, and a button for each section (see Figure 8-12). If the alert is private, the Minutes section is not available. Each section has one check box for each possible value in that section. Days of Week and Days of Month work together in selecting the days in which an alert is checked. It will be checked on any day that satisfies either section.
59
Figure 8-12
You can select as many boxes as you like in each section but in order for the schedule to be valid, at least one box in each section must be selected. There is an exception of Days of Week and Days of Month which needs at least one value to be selected in those two sections, taken together. To select or deselect all of the boxes in a section, you can use the Check All or Clear All buttons. 8.1.2.3.1 Reactivation An alert triggers when the data in your chart changes so that its values satisfy the alerts rules. After it triggers, the next time alert is checked, there is often a high likelihood that the rules will still be satisfied, triggering the alert again. If the alerts schedule has it checking fairly frequently, then this repeated triggering can put a burden on the system, and fill up your alerts dashboard with unnecessary notifications. To alleviate these problems, you can specify a reactivation schedule (see Figure 8-13). That is, you can tell iDashboards to stop checking an alert after it triggers, and resume checking some time later. By default, an alert has the simplest reactivation schedule: Immediately. That is, after the alert triggers its schedule continues uninterrupted. To give it
60
a different reactivation schedule, click the Reactivation button. This opens the Alert Reactivation dialog.
Figure 8-13
Besides immediate reactivation, an alert can resume checking after a fixed period of time, selectable in days, hours and minutes (see Figure 8-14). Or it can wait until a specific day and time. Several choices for this option are available (Figure 8-15). Or you can devise your own, more complex schedule (see Figure 8-16).
Figure 8-14
61
Figure 8-15
Figure 8-16
To do this, select the appropriate choice in the Alert Reactivation dialog, and then click on the Edit Complex Schedule button. This will open the Complex Reactivation Schedule dialog (see Figure 8-17), displaying the same schedule sections and check boxes as in the Schedule tab. You use them the same way, but keep in mind that this is setting the schedule for the alerts subsequent reactivation, not for initial checking.
62
Figure 8-17
8.1.2.4 The Users Tab The Users tab is where you specify who will be notified when the alert triggers (see Figure 8-18). You select the groups of users you want the alert to notify. Notification is by an onscreen message and, if enabled on the alerts Properties tab, by email.
Figure 8-18
iDashboards Alerts Manual As mentioned above, charts in a users Personal category can have only private alerts. That is, all alerts on that chart are necessarily private, and the Configure a Chart Alert dialog will not display its Users tab. The other conditions that cause the Users tab to be hidden are: Unprivileged Account: If youre logged into iDashboards using an account with Guest, Viewer, or User privileges. Unsaved Chart: If youre creating a new chart, and have not yet saved it to any category. Unprivileged Category: If the chart is in a category to which you do not have Save privileges you can still create alerts on it but only private alerts. Filter-On-User: If the chart has a filter set on its data and the filter uses the {$user} macro, then the chart can only support private alerts.
63
If none of these conditions apply, then the Users tab is available. On the left side of the Users tab (see Figure 8-18) there are three choices concerning the people it will notify. On the right is a list of all the user groups that have access to the specific charts category. The first choice, Only me (private alert), as it says, causes the alert to notify only you when it triggers and makes the alert private. The second choice, All groups with access to this charts category, will make the alert notify every user who has access to the category that the alerts chart is in. When the third choice, Only groups selected at right, is selected, the list of user groups becomes enabled allowing you to choose which groups members should be notified. You can select as many groups as you wish, but at least one must be selected. 8.1.2.5 The Summary Tab The Summary tab is quite simple. It contains a textual description of all aspects of the alert, as defined on the other tabs (see Figure 8-19). You can review the alert summary and if desired, select its text and copy and paste it into another document. But its quite useful nonetheless, as it provides a complete description of the alert all in one place. Its a good practice when creating or editing an alert to read over the summary before saving it. This way you can make sure the alert is set up exactly as you want it.
64
Figure 8-19
8.1.3 Alert Notifications When an alert triggers, the iDashboards sends you an on-screen notification, and possibly an email message. If you are logged in to iDashboards when the alert triggers, youll see the notification within one minute. Otherwise, youll see it as soon as you do log in. iDashboards provides a special dashboard for receiving, viewing and managing alert notifications, the Alerts Dashboard. 8.1.3.1 The Alerts Dashboard If there are any new alert notifications waiting for you when you log in to iDashboards the Alerts Dashboard opens automatically. If not, or if you close the alerts dashboard and wish to re-open it, you can use the alerts icon at the bottom of the iDashboards screen (see Figure 8-20) to open the alerts dashboard.
Figure 8-20
iDashboards Alerts Manual This icon appears in one of four states: Off: If there are no active alert notifications, the icon appears as a grey exclamation point. On: If there are active alert notifications, and all of them have been opened (see Section 8.1.3.2, Opened Notifications), the icon appears as a red exclamation point. Flashing: If there are active alert notifications, and one or more of them have not been opened, the icon appears as a red exclamation point with a flashing yellow background. Disabled: If your iDashboards Administrator has disabled Browser Alert Checks, then the icon appears as a red exclamation point covered with a large red X.
65
If the icon is in any state other than Disabled, clicking on it opens the alerts dashboard or, if its already open, brings it to the foreground. The alerts dashboard (see Figure 8-21) is somewhat different from other dashboards. The dashboard itself is always red, regardless of the current skin setting. It always contains three frames. The top frame contains the list of active alert notifications. Each notification occupies one line, displaying its severity, message, and the date and time it was triggered. In addition, the entry has two buttons, labeled Show Chart and Delete. The lower two frames are utilized to display the details about a specific alert when you select a particular alert in the upper frame.
Figure 8-21
66
8.1.3.2 Opened Notifications iDashboards keeps track of which alert notifications you have opened, that is, which ones have been selected singly so that its details appear in the lower left frame. Once a notification has been opened, its line in the list appears in grey. iDashboards remembers which notifications have been opened between log-ins. As long as you log in on the same computer, the notifications that you previously opened will appear in grey. If you move to another computer, however, that information will not move with you. 8.1.3.3 Show Chart When you click on a notification line, or select it with the arrow keys, the notification opens showing more of its information in the lower-left frame. This includes the alerts name, message and ID number, when it was triggered and when it is next scheduled to be checked. Theres also another Show Chart button. The button provides the exact same functionality as the Show Chart button displayed on the upper frame for the alert. When you click either of the two Show Chart buttons, two things happen. Information about the alerts chart appears in the bottom of the lower-left frame, including name and chart ID. Also, the chart itself opens in the lower-right frame. This chart acts just like it would in any other dashboard, and you can do with it all things you would otherwise. Note: The alerts dashboard is not a regular dashboard. You cannot open an arbitrary chart in the lower right frame. The only way to show a chart there is through one of the Show Chart buttons.
8.2 Charts with Alerts

A chart on which an alert is defined changes in a few ways. Alerts depend on the charts data definition remaining unchanged. For this reason, certain dialogswhich you could otherwise use to modify the charts data definitionare disabled for a chart that has one or more alerts. You can still open these dialogs, and use them to inspect the charts current data definition, but they cannot change it. The affected dialogs are all accessed through the Chart Data selection in the Chart Menu, or the charts popup menu. When you open that dialog on a chart with alerts, you will find changes to some of the buttons: Edit Axis Labels is replaced with Show Axis Labels. Change Chart Data Source is replaced with Show Data Source. Modify Chart Data Columns is replaced with Show Chart Data Columns. Modify SQL Query is replaced with Show SQL Query.
Clicking one of these buttons opens the same dialog as on a chart with no alerts, but none of the dialogs controls are active. If it is necessary to change a charts data definition, you must first delete all alerts defined on the chart.
67
8.3 Alert Notification Settings

Several of the items in the User Settings dialog (see Figure 8-22) pertain to your interaction with Alerts. If you want iDashboards to check for alert notifications as soon as you log in, and at regular intervals afterward, select Periodically check for new alerts. Then you can also set the frequency with which iDashboards looks for new notifications, from once per minute to once per hour. Note that this is not the same thing as checking an individual alert to see if it will trigger. This check is for new notifications from any alert which has triggered since the last check. The last two items in this dialog let you choose to receive alert notifications by emailif an alert is set to send themand the email address to receive them.
Figure 8-22
68
69
Appendix A Deploying the Alerts Server to Tomcat

In Apache Tomcat, Web applications are deployed through the Tomcat Web Application Manager screen, shown in Figure A-1.
Figure A-1
The URL to access the Web Application Manager screen is http://hostname/manager/html with the appropriate substitution for "hostname" in the URL. A login dialog will be presented, use "admin" as the username and the administrative password that was provided during the Tomcat installation process. (Note: These are not the login credentials of the iDashboards admin user account.)
70
Appendix A:Deploying the Alerts Server to Tomcat
In the section near the bottom labeled WAR file to upload, click the Browse button. In the file selection dialog that appears, navigate to the location of the idbalerts.war file and select it for upload. Then click the Deploy button to upload the WAR file to Tomcat. If the WAR file deploys properly, you will see OK in the Message window at the top of the Manager screen. You will also see /idbalerts in the list of applications. This will be a hyperlink that will open the Alerts Server console login screen.
i.
Alternate Installation Process
The WAR file can also be deployed by copying it into the webapps directory that is in the Tomcat installation directory.
71
Appendix B Log Configuration

At runtime, the Alerts Server will log system errors and other events in a log file. The name of the log file is idbalerts.log, and it will be created in the <IVIZGROUP HOME>\logs directory. Certain parameters can be set in the ivizgroup.properties file to determine the maximum size a log file will be allowed to grow to, the number of backups that will be kept, and the verbosity of the logging output. Note that these settings can be changed while the server is running through the System Logs screen, described in Chapter 3, however such changes will not persist across a server restart. log.directory This property can be used to indicate a directory other than <IVIZGROUP HOME>\logs where log files should be written. It must exist and be writable by the iDashboards application server process. Forward slashes (/) should be used instead of backslashes (\) as a path separator. log.maxFileSize This property indicates the maximum size, in bytes, that a log file will grow to before it is "rolled over", that is, renamed with a ".1" extension so that a new idbalerts.log file can be created. This property must be an integer from 0 to 9,223,372,036,854,775,808. (Do not include commas.) The suffixes "KB", "MB", or "GB" can be appended to indicate the value is kilobytes, megabytes or gigabytes, respectively. If no value is given, the default used is "10MB". log.maxBackupIndex When logs are rolled over, the current idbalerts.log file is renamed to idbalerts.log.1, an existing log file with a ".1" extension is renamed with a ".2" extension, one with a ".2" extension is renamed with a ".3" extension, and so on up to the value of the log.maxBackupIndex property. If a log file already has an extension equal to log.maxBackupIndex, it is discarded when the log files are rolled over. If log.maxBackupIndex is zero, there will be no backup files, and the log will be truncated when its size grows to the maximum size. log.level This value must be one of the following: ERROR, WARN, INFO or DEBUG. (The default is INFO). DEBUG will produce the most verbose output, and ERROR will produce the least. Normally, DEBUG should only be used when troubleshooting.
72
Appendix B:Log Configuration
73
Index
A
Alert Checks, 9 browser check interval, 21 Alert Configuration, 52 Alert Instances, 9 maximum displayed, 21 retention, 21 Alert Notifications, 64 Alerts, 8, 49 administering, 45 browsing for, 48 deleting, 47, 48 described, 8 enabling/disabling, 48 firing, 9 modifying, 48 retrieving, 46 system settings, 21 alerts dashboard, 49 Alerts Dashboard, 21 Alerts Server console, 12, 15 console login screen. See Login Screen events. See Server Events Installation, 12 logging in, 17 pausing, 40 restarting from a paused state, 40 Apache Tomcat, 11, 17 deploying the Alerts Server to, 6970 Application Server, 7, 11, 12, 13, 14, 16 deploying the Alerts Server to, 1617, 6970 Context Root, 1718
D
Dashboards, 11 db.driverClass, 15 db.jndiName, 14 db.maxConnections, 15 db.password, 15 db.password.encrypted, 15 db.url, 15 db.user, 15 db.validateConnections, 15 Delete, 52 Deployment, Application, 1617 disabled functionality, 66 drivers directory, 13
E
Edit, 52 Email configuration, 2938 macros. See Mail Macros notification email settings, 20, 29, 3133 notification emails, 7, 2938, 40, 42, 44, 45, 47, 48 template files, 3335 ERROR events. See Server Events error message, 50 Events. See Server Events Exchange Server, Microsoft, 7, 29
F B
Browser Alert Checks, 24 Firing. See Alerts
G C
Charts with Alerts, 66 Checks. See Alert Checks Classpath, Java, 16 Color, Severity. See Severity Color config directory, 13, 14 Configure Alerts, 50 Configuring Alerts, 50 Connection Pool iDashboards-managed, 14 server-managed, 14 General Level Log Setting, 22 groups, 49
H
HTTP request logging, enabling, 23
I
iDashboards Repository, 7, 8, 11, 12, 13, 14, 16, 21, 47
74
connection pool, configuring, 14 database password, 15 database user, 15 idashboards.lic. See License File idashboards.license, Java system property, 16 idb_encrypt tool, 15 idbalerts.log file, 23, 24, 71 idbalerts.war, 11, 12, 16, 17 Importing and Exporting Charts with Alerts, 48 INFO events. See Server Events Installation, 12 Instances. See Alert Instances Interval, browser alert check, 21 ivizgroup home directory, 12 <IVIZGROUP HOME> explained, 13 creating, 1213 ivizgroup.home, Java System Property, 13 ivizgroup.properties, 12, 13, 14, 15, 16, 22, 71 configuring, 13
Index
Login Screen, 17 URL for, 17 logs directory, 13
M
Macros. See Mail Macros Mail Macros, 3538 alert macros, 36 chart macros, 3637 error macros, 37 event macros, 37 miscellaneous macros, 38
N
New, 52 notification, 65 Notification, 62 Notification Emails. See Email
J
J2EE, 11 Java Development Kit, 11 Java Runtime Environment, 11 Java System Properties, 13 idashboards.license, 16 ivizgroup.home, 13 ivizgroup.properties, 13 JDBC Drivers, 7, 11, 13 JDK. See Java Development Kit
O
Opened Notifications, 66
P
Password, 15 repository database, 15 Port Number, 17 private alerts, 51 Properties Tab, 54
L
License File, 12 installing, 16 Log Files active log file, 23 downloading, 23 maximum number of backups, 23 maximum size, 23 sending to iDashboards technical support, 23 Log Settings, 2224, 71 at server startup, 22 configuring in ivizgroup.properties, 71 general level, 22 HTTP request logging, enabling, 23 maximum file size, 23 maximum number of backup files, 23 XML logging, enabling, 23 log.directory, 71 log.level, 71 log.maxBackupIndex, 71 log.maxFileSize, 71
R
Reactivation, 58, 59 reactivation schedule, 59 red highlight, 53 Repository Database. See iDashboards Repository Retention, 21 rules, 49 rules components, 55 rules relation, 57 Rules Tab, 55
S
schedule, 49 Schedule tab, 58 Sendmail, 7, 29 Server. See Alerts Server Server Events, 4044 ERROR events, 41 INFO events, 41

WARNING events, 41 Server Status Screen, 39, 40 Setting Categories, 19 severity, 49 Severity Color, 25, 2627 editing, 26 including in notification emails, 36 Severity Levels, 8, 19 adding, 2627 built-in, 25 deleting, 28 including in notification emails, 36 managing, 2528 modifying, 27 Show Chart, 66 Show Chart button, 65 SMTP service, 7, 29 settings, 20, 2931 Stacktraces including in event notification emails, 37 viewing for error events, 42 Summary, 63 System Requirements, 11 System Settings, 1921 modifying, 20
75
T
Template files. See Email The Alerts Configuration Dialog, 50 The Alerts Dashboard, 64 Tomcat. See Apache Tomcat
U
Username, 15 Users, 54, 62
W
WAR File, 7, 11, 16, 17 WARNING events. See Server Events
X
XML logging, enabling, 23
76
Index

Alerts Manual

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Alerts Manual

Uploaded by

Copyright:

Available Formats

iDashboards Alerts Manual

iDashboards Alerts Manual Version 7.5

Copyright 2004 - 2011 iDashboards. All rights reserved.

Web site: http://www.iDashboards.com

iDashboards Alerts Manual

DEPLOYING THE ALERTS SERVER TO TOMCAT ............................................. 69

ALTERNATE INSTALLATION PROCESS ...................................................................................... 70 LOG CONFIGURATION ......................................................................................... 71

iDashboards Alerts Manual

1.1 About this Manual

1.2 System Overview

iDashboards Repository (RDBMS)

Alerts Server Console Browser (IE, Firefox)

HTML/XML over HTTP

External Data Sources

1.3 What is an Alert?

1.4 Terminology Used in This Manual

This page intentionally left blank.

iDashboards Alerts Manual

2.1 System Requirements

2.2 Installation Roadmap

2.3 Creating the ivizgroup home directory

2.4 Configuring ivizgroup.properties

An example entry might look like:

iDashboards Alerts Manual

Additonally, three optional properties may be specified:

2.5 Installing the License File

2.6 Deploying the Application

2.7 Logging into the Alerts Server Console

iDashboards Alerts Manual

3.1 System Settings

Chapter 3: System Configuration

3.2 Modifying a System Setting

iDashboards Alerts Manual

3.3 Alert Settings

Chapter 3: System Configuration

3.4 Log Settings

3.5 Downloading Log Files

3.6 Sending Log Files to iDashboards Technical Support

3.7 Browser Alert Checks Enabled

iDashboards Alerts Manual

Managing Severity Levels

Chapter 4: Managing Severity Levels

4.1 Adding a Severity Level

4.2 Modifying a Severity Level

Chapter 4: Managing Severity Levels

4.3 Deleting a Severity Level

iDashboards Alerts Manual

Notification Email Settings

5.1 Email Configuration Roadmap

The following sections describe the above steps in greater detail.

5.2 Configuring the SMTP Settings

Chapter 5: Notification Email Settings

5.3 Configuring the Notification Email Settings

iDashboards Alerts Manual

5.4 Configuring the Email Templates

5.5 Mail Macros

Chapter 5: Notification Email Settings

iDashboards Alerts Manual

Chapter 5: Notification Email Settings

iDashboards Alerts Manual

Chapter 6: Server Operation

6.1 Pausing and Restarting the Server

6.2 Understanding Server Events