Escolar Documentos
Profissional Documentos
Cultura Documentos
Version 7.5
V7.5
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
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.
APPENDIX B
Introduction
Chapter 1: Introduction
Server Side
External User Authentication Service (MS Active Directory, Novell eDirectory, etc.)
Client Side
LDAP
SMTP Service
SMTP
J2EE Application Server (Tomcat, Weblogic, WebSphere, JBoss, etc.) iDashboards Alerts Server (J2EE Web Application)
HTML/Javascript Pages
JDBC
JDBC
JDBC
RDBMS
Data Mart
Data Warehouse
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
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.
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.
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
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>
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:
15
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
Chapter 2: Installation
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.
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
18
Chapter 2: Installation
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
20
Figure 3-2
21
Figure 3-3
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
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.
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.
Figure 3-5
25
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
Figure 4-2
Figure 4-3
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
28
29
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.
30
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
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
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.
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.
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
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.
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.
Figure 6-3
42
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
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
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
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
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.
Figure 7-7
49
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
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-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.
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
Figure 8-22
68
69
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
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.
The WAR file can also be deployed by copying it into the webapps directory that is in the Tomcat installation directory.
71
72
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
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