This page last changed on Apr 18, 2010 by mmcgarry.

Topics marked with * relate to HQ Enterprise-only features.

The HQ Server Settings page allows an HQ user with Super User role to configure a variety of HQ Server behaviors. Most changes take effect upon HQ Server restart.

Feedback is welcome. Click Add Comment at the bottom of the page.

HQ Server settings have a fundamental and wide-ranging impact on the functionality and behavior of your HQ deployment. Edit with extreme caution.

HQ Email Configuration Properties

In the notification that HQ sends for a fired alert, the "From" address and the URL to the Alert Detail page are formed using the properties defined in the "HQ Email" section of the HQ Server Settings page.

  • Base URL - Specifies the address:port where HQ Server listens for web application requests. The initial value of Base URL is the web application listen port configured when HQ Server was installed. For example:
http://Dorcas-Parmentiers-MacBook-Pro-15.local:7080/

The Base URL forms the prefix of an URL to any HQ appends the remainder of the URL that points to the Alert Detail page for the fired alert. For example:

http://Dorcas-Parmentiers-MacBook-Pro-15.local:7080/alerts/Alerts.do?mode=viewAlert&eid=5:10611&a=16431
  • From Email Address - The email address listed as the sender of the alert emails.

Hyperic IQ Properties*

In HQ Enterprise 4.1 and later, the Hyperic IQ Server URL property identifies the URL of a Hyperic IQ installation. You must specify the IQ server to enable users to view IQ reports in the Hyperic IQ Reports dashboard portlet. The URL is:

http://IQ_host:9080/arc

where IQ_host is the address of the IQ server.

HQ Announcement Properties

  • HQ Version and Security Announcements - Controls what security and version announcements will be sent to HQ Administrators: All, Major, or None.
  • Context-Sensitive Help - Defines the location from which help pages will be served when an HQ user clicks Help. When set to "Remote", help pages will be served from the Hyperic documentation wiki. When set to "Internal", the help pages that are embedded in the HQ Server will be served.

Note:  Although you can modify embedded help pages, modified help pages will be over-written when you upgrade the HQ Server to a new version.

Maintenance Properties

This section appears in the HQ Server Settings page in versions of HQ prior to 4.2.

In those versions of HQ, the Alerts Enabled setting can be used to disable or enable all alert definitions for all resources.

  1. Enable or disable alert definitions:
    • Click No to disable all alert definitions.
    • Click Yes to re-enable alert definitions.
  2. Restart the HQ Server.

In HQ 4.2 and later, this setting is in the Global Alert Properties section of the page.

Data Manager Configuration Properties

These properties control how HQ condenses and purges the contents of the HQ database. Regardless of these settings HQ will retain two years of compressed metric history, but you can control how long detailed metric data is retained. Retaining fewer days of detailed metric data and deleting alerts and other events on a timely basis can improve HQ performance.

  • Run Database Maintenance Every - Controls how frequently HQ compresses and archives detailed metric data that is older than the age specified by the following property. By default, HQ does database maintenance every hour.
  • Delete Detailed Metric Data Older Than - Controls how many days of detailed metric data HQ retains before compressing it into hourly averages with highs and lows and archiving those values. The default setting is 2 days. HQ does not support a value greater than 7 days.
  • Reindex Metric Data Tables Nightly - Controls whether HQ reindexes metric data tables every night. When set to Yes, HQ re-indexes the tables around midnight.
  • Delete Alerts Older Than - Controls how long HQ stores alert event data. The default value is 31 days.
  • Delete Events and Logs Older Than - Controls how long HQ stores other HQ event and log data. The default value is 31 days.
Warning: Data Management Changes Require Server Restart
Any changes made in this section require the HQ Server to be restarted before they take effect.

Global Alert Properties

As of HQ 4.2, these properties enable immediate and global control of alert processing.

  • Alerts - Disable or enable all alert definitions for all resources immediately. OFF stops any alerts from firing; notifications defined in escalations that are currently in progress will be completed.
  • Alert Notifications - Disable or enable alert notifications for all resources immediately. OFF stops all notifications, include those for alerts with escalations currently in progress.
  • Hierarchical Alerting * - As of HQ Enterprise 4.2, this setting controls whether alerts are evaluated using the hierarchical alerting method. When hierarchical alerting is enabled, before firing an alert for a resource, HQ considers the availability and alert status of the resource's parent. The purpose of hierarchical alerting is to avoid firing alerts for every resource affected by a single root cause. For more information, see Understanding Hierarchical Alerting.

Note: You can extend the effect of hierarchical alerting in HQ Enterprise 4.2 and later by configuring the relationship between a network device or virtual host and the platforms that depend on it using the Network and Host Dependency Manager available in the "Plugins" section of the Administration tab. For more information see Configure Network Host Dependencies for Hierarchical Alerting.

Notification Throttling Configuration Properties*

Starting in HQ Enterprise 4.2, you can use notification throttling to limit the number of alert email actions (notifications sent by email for a fired alert) that HQ will issue in a 15 second interval. When the threshold you specify is reached, HQ stops sending email alert notifications and instead sends a summary of alert activity every ten minutes to the recipients you specify.

After startoing to throttle, HQ re-evaluates notification volume for fired alerts every 10 minutes; when it determines that the per interval volume of individual notifications that fired alerts would generate is less than the configured threshold, HQ resumes sending individual notifications.

To enable notification throttling:

  1. Click the Notification Throttling ON control.
  2. In the "Threshold" field, enter the maximum number of notifications you want sent in a 15 second interval.
  3. Enter one or more email addresses in the "Notification Email(s) field".

For related information, see Controlling Alert and Notification Volume.

Automatic Baseline Configuration Properties *

In HQ Enterprise, these properties control the HQ baselining process and the accuracy of the baseline.

  • Baseline Frequency - The frequency with which HQ calculates a baseline for each metric. By default, every 3 days.
  • Baseline Dataset - The time range of metric data used in calculating the baseline. By default, 7 days of data.
  • Baseline Minimum Data Points - The minimum number of data points used in calculating a baseline. By default, 40.
  • Track Out-of-Bounds Metrics - Controls whether or not HQ tracks OOB metrics.

LDAP Configuration Properties *

By default Hyperic HQ uses its database for storing information about users and authenticating those users. HQ can be configured to use an external LDAP directory for authenticating users in addition to its own database.

In HQ Enterprise, these properties configure HQ to use an external LDAP directory — in addition to HQ's own database — for authenticating users.

  • URL - The LDAP URL the HQ Server will use to access the LDAP directory
  • SSL - Indicates whether the LDAP directory requires SSL connections.
  • Username and Password - Used if the LDAP directory does not allow anonymous searching, as is common in secure environments. The username must be an LDAP user with sufficient privileges to view at least the sections of the directory containing the information for HQ users.
  • Search Base -  Also known as the suffix. Required for an LDAP connection. If unsure of this setting, check with the LDAP administrator.
  • Search Filter - Limits the users in LDAP to a subset of the entire directory
  • Login Property - The LDAP property that HQ will use as the username. Very important. Examples of common login properties are "cn" and "uid".

After LDAP authentication has been successfully configured, users will be able to log into HQ with their LDAP password (using the value specified as the Login Property as their username). The first time LDAP users log in to HQ, they will be asked to provide some identifying information before they can continue: their first and last name, email address, phone number, etc. This is for display purposes and alert notification purposes.Note:  LDAP Users Need HQ Roles, Too
As with all new users in HQ, LDAP users are not assigned to any roles by default and therefore they will not be able to see any resources in HQ until they are added to a role. HQ administrators will need to assign the appropriate role or roles to the user in HQ. (On the HQ Administration page, click List Users, select the user, and click Add to List in the "Roles Assigned To" section of the page.)

Kerberos Configuration Properties*

In HQ Enterprise, these properties configure HQ to use Kerberos authentication.

  • Realm - Identifies the Kerberos realm.
  • KDC - Identifies the Kerberos kdc
  • Debug - Enables debug logging.

SNMP Server Configuration Properties (4.2 and earlier) *

This section lists the properties for configuring HQ Enterprise for an SNMP server, which can be used for alert notification once SNMP traps are enabled. The display of configuration properties depends on the selected SNMP Protocol Version (if any).

For version 3:

  • Trap OID
  • Auth Protocol
  • Auth Passphrase
  • Privacy Protocol
  • Privacy Passphrase
  • Target Context Name
  • Security Name
  • Engine Id

For version 2c:

  • Trap OID
  • Community

For version 1:

  • Trap OID
  • Community
  • Generic ID
  • Specific ID
  • Enterprise ID
  • Agent Address

SNMP Server Configuration Properties (4.3 Beta) *

Describes HQ 4.3 Beta feature

If you configure HQ Enterprise to send SNMP messages to your NMS, you can use SNMP notifications in alert actions or as a step in an escalation.

You define SNMP options for HQ Server in the "SNMP Server Configuration Properties" section of the Administration > HQ Server Settings page. The properties you define specify the SNMP protocol version for communicating with the NMS (v1, v2c, or V3), the type of notification (v1 Trap, v2c Trap, or Inform), and the properties required for the SNMP version you use. After this configuration, you can select the SNMP notification type:

  • As an alert action - The notification sent when the alert fires will contain three variable bindings:
    • sysUptimeOID.0 - No configuration is required for this binding.
    • snmpTrapOID.0 - This binding is configured on the HQ Server settings page.
    • A variable binding for the alert data specified in the snmp_trap.gsp alert notification template - the alert definition name and the "short reason" for firing. Note that Alert templates may be customized, as described in Tailoring Alert Notification Templates.
  • As an escalation step - The behavior varies by version of HQ Enterprise:
    • In HQ Enterprise 4.2 and earlier - The notification sent will contain three variable bindings:
      • sysUptimeOID.0 - No configuration is required for this binding.
      • snmpTrapOID.0 - This binding is configured on the HQ Server settings page.
      • A variable binding for the alert data specified in the snmp_trap.gsp alert notification template - the alert definition name and the "short reason" for firing. Note that Alert templates may be customized, as described in Tailoring Alert Notification Templates.The notification has two varbinds - SysUpTime.0 and snmpTrapOID.0.
    • In HQ Enterprise 4.3 Beta and later - When you configure an SNMP notification as an escalation step, you can specify additional variable bindings. When the escalation step is performed, the trap will contain those variable bindings, along with SysUpTime.0, snmpTrapOID.0, and a variable binding for the alert data specified in the snmp_trap.gsp alert notification template.

Configure HQ Server for SNMP v1

Select "v1" from the  SNMP Protocol Version pulldown and supply values for the properties defined in the table below.

The table below defines the properties for configuring HQ Server for SNMP V1 communications with an NMS.

Configuration Option Description Allowable Values
SNMP Trap OID The OID of the notification to be sent. Supplies the value of snmpTrapOID.0 - the second varbind in a trap or inform that HQ Server generates. (The first varbind is SysUpTime.0.)


 
Default Notification Mechanism
Your selection governs the notification type that will appear as the default notification type option in the "Notification Mechanism" pulldown list that is presented in configuration dialogs when user configures an SNMP notification as an alert action, or as a step in an escalation.
For v1 of the SNMP protocol, choose V1 Trap. This is the only trap type you can generate for SNMP v1.
Enterprise OID
Enterprise OID.
 
Community The community name to be sent with the trap.
 
Generic ID
Single digit identifier of the trap type. 0 - coldStart
1 - warmStart
2 - linkDown
3 - linkUp
4 - authenticationFailure
5 - egpNeighborLoss
6 - enterpriseSpecific
Specific ID
The specific trap code for an enterprise-specific trap (when Generic ID is set to to 6).
 
Agent Address
Address of the managed object that generates the trap.
 

Configure HQ Server for SNMP v2c

Configuration Option Description Allowable Values
SNMP Trap OID The OID of the notification to be sent. Supplies the value of snmpTrapOID.0 - the second varbind in a trap or inform that HQ Server generates. (The first varbind is SysUpTime.0.)  
Default Notification Mechanism
Specifies the default notification type that will appear in configuration dialogs when an authorized user configures an SNMP notification as an alert action, or as a step in an escalation. This choice simply defines the default option - the user configuring an alert action or escalation can choose a different message type.
  • V1 Trap
  • V2c Trap
  • Inform
Community The community name to be sent with the trap.
 

Configure HQ Server for SNMP v3

This section lists the properties for enabling HQ Enterprise to sent SNMP notifications to an NMS. When HQ is so enabled, you can use SNMP notifications in alert definitions - as alert actions and escalation steps.

Configuration Option Description Allowable Values
SNMP Trap OID The OID of the notification to be sent. Supplies the value of snmpTrapOID.0 - the second varbind in a trap or inform that HQ Server generates. (The first varbind is SysUpTime.0.)  
Default Notification Mechanism
Specifies the default notification type that will appear in configuration dialogs when an authorized user configures an SNMP notification as an alert action, or as a step in an escalation. This choice simply defines the default option - the user configuring an alert action or escalation can choose a different message type.
  • V1 Trap
  • V2c Trap
  • Inform
Security Name The username HQ's SNMP agent should use when sending notifications to the NMS. 
Required.
Local Engine ID ID of HQ's SNMP agent; this value appears automatically, and is not user-configurable.

Auth Protocol The SNMP authentication protocol HQ Server should use for communications with the NMS.
  • none
  • MD5
  • SHA
Auth Passphrase
The SNMP authorization passphrase configured for use when communication with the NMS. 

Privacy Protocol The SNMP Privacy Protocol HQ Server should use for  communication with the NMS.
  • none
  • DES
  • 3DES
  • AES-128,
  • AES-192
  • AES-256
Privacy Passphrase The SNMP privacy passphrase configured for use when communication with the NMS.
Context Engine ID The EngineID of the NMS. This, along with Context Name, identifies the SNMP context for accessing management data. Required for v1 and v2c traps.  Do not supply for Inform.
Context Name
The name of the SNMP context that provides access to management information on the NMS.  A context is identified by the Context Name and Context Engine ID.
Document generated by Confluence on Apr 20, 2010 15:01