In the Operations Center console, alarm summaries display in the pane title bar for all views except , using the format: 200 open alarms, 50 critical, 100 major, 50 minor. When an element contains only one alarm, the summary displays the actual alarm.
Use the alwaysShowAlarmCounts parameter to use the alarm summary format for single alarms instead of displaying the actual alarm.
Table 9-13 describes <param> tags for alarm summary counts.
Table 9-12 param tags for Performance Data
|
param Name |
Type |
Description |
|---|---|---|
|
alwaysShowAlarmCounts |
Required |
If true or yes, calculates summary information for an alarm. Note that alwaysShowAlarmCounts overrides <param name=”notesAsLastMessage”>. |
To view summary information for a single alarm in the format: 1 open alarm, 1 critical, use the following <param> tag:
<param name="alwaysShowAlarmCounts" value="true"/>
Elements created from <generator> tag can have performance data attached to them using a few <param> tags. The <param> tags define how to read the performance data from a database. After the performance data is attached to the element, performance charts can be created using the usual methods.
The following requirements must exist to populate the performance chart with database information:
Performance data exists in a relational database which can be accessed from the Operations Center server.
The database has a JDBC driver which is listed the formula.db.jdbc.drivers property within the /OperationsCenter_install_path/config/Formula.properties file.
IData is returned from a SQL query with a time stamp in the first column and the remaining columns numeric. The data must be in ascending order by time stamp.
Table 9-13 describes <param> tags for performance data.
Table 9-13 param tags for Performance Data
|
param Name |
Type |
Description |
|---|---|---|
|
Performance.Label |
Required |
The series name of the performance data. |
|
Performance.Metrics |
Required |
A semi-colon delimited list of database column names. These are the names of the data that appears in Operations Center and must match a column names in the query. |
|
Performance.Query |
Required |
The SQL query retrieving the desired data with a time stamp in the first column and integers or floats in remaining columns. With the exception of the time stamp column, the alias of each data column must match a name in the Performance.Metrics list or it will not be chartable. Data must be returned in ascending order by time stamp. |
|
Performance.Database |
Optional |
Full URL of database to query, including the machine name, port and database name. This defaults to the setting of formula.db.jdbc.url in the Formula.properties file. |
|
Performance.User |
Optional |
The user name for the database login. This defaults to the setting of formula.db.user in Formula.properties. |
|
Performance.Password |
Optional |
The password for the database user account. This defaults to the setting of formula.db.password in the Formula.properties file. |
Dynamic values from the alarms and generated can be inserted into param values to customize the series name, column names and SQL query for each element and alarm. These dynamic values are:
{element.name} Name of element being generated.
{query.from}, {query.to} Starting and ending time stamps specified by user when creating performance chart. These should be formatted in the query to correspond to the time stamp format used by the given database.
{alarm.field} The value of any defined field of the alarm generating the element. For example, {alarm.source} would be the source of the alarm while {alarm.hostname} would be the hostname of the machine that raised the alarm. The names of fields available for an alarm depend on the adapter.
Use the following requirements and best practices when using params for performance data:
Each param value must be on a single line with no line breaks.
All single quotes must be doubled in the SQL query.
Do not use greater than and less than symbols. Instead use > and <.
Time stamps must be formatted using the syntax above, but might need a different format string depending on the database type. The formatting syntax is documented in the java.text package. See the online Java documentation at http://java.sun.com/j2se/1.3/docs/api/index.html.
The MODL file can generate matches to target elements using structure or source values in the Service Configuration Manager (SCM).
Table 9-14 describes <param> tags for SCM data.
Table 9-14 Parameters Used to Mine Values from the SCM
|
Param Name |
Description |
|---|---|
|
match.n.type |
Type of match to perform. Set to on of the following: FIXED, REGEXP, LDAP, CLASS |
|
match.n.expr |
Used to create the variable portion of a match expression or static DName using template expansion. If no source elements are provided, this expression uses the element generated as the element for template expansion. |
|
match.n.root |
If no source elements are provided, the root element is used for generating the location of expression root in the resulting matcher, or for the fixed portion of the static match generated. As an example, if the root is specified for a REGEXP matcher, the resulting final match expression concatenates the expression value with the root value. |
In the following example, a element is created with the class of . Then, using param declarations, child elements are matched when an element is found that has a grandparent with gen-device class and
<group name="Switch" class="telcom_switch">
<param name="match.0.type" value="FIXED" />
<param name="match.0.expr" value="gen_device=${formula.util.encodeURL($parent.parent.name)}" />
<param name="match.0.root" value="gen_container=Switches/demo=SNMP+Manager/root=Elements" />
</group>
For a more extensive example using SCM matching parameters, see Section 9.9, Example: SCM Matching.