> -----Original Message-----
> From: Mcdaid, Paul (GAL:IE319)
> Sent: Thursday, August 28, 2008 11:07 AM
>
> Laurentiu wrote:
> >I tried to display "Description" and "Recommendations"
> columns in the table, but this makes the table too wide.
> >So I am proposing to make the "Alarm code" clickable to open
> a new page which contains "Description" and
> >"Recommendations" of the alarm and also the "Enable Email" check-box.
> >Is it ok?
> I think Carolyn was saying that the current Description field
> is really the Alarm ID field (in the sipXalarms-config.xml
> which shouldn't be displayed to the user. Carolyn, should we
> display the text that is going to be displayed when the user
> gets notified of the alarm? In that case, we need to put a
> maximum text size on this as we don't want this table getting too big.
>
> Laurentiu,
> I think what we're looking for is a table with the following:
>
> | Alarm Id | Alarm Description | Severity | email
> notification tickbox
> | |
>
>
I am currently sitting on an update to add a "Short title" field (to use
in email subject headers, but it will also help here), which could go on
the main screen beside the alarm code. I am waiting to submit this
because it will conflict with another patch I have submitted but which
has not been accepted yet. I've attached xml files which contain this
field.
The Description as captured in the xml files may contain placeholders
for run-time parameters. It might not be useful to display this at all
on the config screen. I think we just need the short title (which is
coming) on the configuration screen. The recommendations could be
displayed from the Alarm History screen, when we get to that. In this
case, the config screen would only have a table more like what Paul
suggested, except with short title instead of description.
| Alarm Code | Alarm Title | Severity | Email tickbox
If the <shorttitle> is missing in the current language
(sipXalarms-strings_xx.xml), then the default should be English
(sipXalarms-strings.xml); and if it's missing there, it should be the
internal ID (which is where you started). Having said that, I don't
think we plan to have any translations for this release so the language
could be left as a TODO.
Note that the alarm server config is designed to allow us to drop in
"packs" of alarms. The code does not care about the name of the config
or strings files: it loads all of them in the proper directory. Will
the config code do the same thing? Currently there is only one "pack"
(sipXalarms).
Carolyn
<?xml version="1.0" encoding="utf-8" ?>
<!-- INSTRUCTIONS FOR DESIGNERS WISHING TO ADD AN ALARM
Each alarm is defined in the etc/sipXalarms-config.xml file, and identified by its
unique id, which is an internal (not customer-visible) string.
Strings containing the alarm description, a short title for the alarm,
and suggested actions to resolve it, must be added in this file.
These strings can be localized for different languages.
Parameters provided at runtime can be inserted into the description string using placeholders
of the form {n}.
-->
<alarm_server xmlns="http://www.sipfoundry.org/sipX/schema/xml/alarm-00-00";>
<definitions>
<alarm id="SERVTEST_FAILURE">
<shorttitle>sipx-servtest failed</shorttitle>
<description>sipx-servtest test {0} failed with msg '{1}'.</description>
<resolution></resolution>
</alarm>
<alarm id="PROCESS_RESTARTED">
<shorttitle>Restarting process</shorttitle>
<description>Process {0} was found in a non-running state. Attempting to restart the process.</description>
<resolution>No action required.</resolution>
</alarm>
<alarm id="PROCESS_FAILED_RESTART">
<shorttitle>Failed to restart process</shorttitle>
<description>Process {0} was found in a non-running state. Process failed restart.</description>
<resolution>The system will retry several times.</resolution>
</alarm>
<alarm id="PROCESS_FAILED">
<shorttitle>Process cannot be restarted!</shorttitle>
<description>Process {0} was found in a non-running state, and failed MAX restarts. Process cannot be restarted!</description>
<resolution>If the process is required, check logs for more details.</resolution>
</alarm>
<alarm id="LOGIN_FAILED">
<shorttitle>Login failed</shorttitle>
<description>Login attempt as '{0}' failed several times in a short period.</description>
<resolution>If condition recurs, may indicate an attempt to break in. </resolution>
</alarm>
<alarm id="THRESH_CPUUTIL_EXCEEDED">
<shorttitle>CPU threshold exceeded</shorttitle>
<description>The threshold for CPU load on {0} has been exceeded. The threshold is {1}%. The current value is {2}%.</description>
<resolution>If condition persists, check for runaway processes.</resolution>
</alarm>
<alarm id="THRESH_CPUUTIL_OK">
<shorttitle>CPU threshold recovered</shorttitle>
<description>CPU load on {0} has recovered back to {2}%. The threshold is {1}%.</description>
<resolution>No action is required.</resolution>
</alarm>
<alarm id="THRESH_DISK_EXCEEDED">
<shorttitle>Disk usage threshold exceeded</shorttitle>
<description>The threshold for disk usage on {0} has been exceeded. The threshold is {1}%. The current value is {2}%.</description>
<resolution>If condition persists, clean out log and temporary directories. Remove old voice mails.
Reduce log levels.</resolution>
</alarm>
<alarm id="THRESH_DISK_OK">
<shorttitle>Disk usage threshold recovered</shorttitle>
<description>Disk usage on {0} has recovered back to {2}%. The threshold is {1}%.</description>
<resolution>No action is required.</resolution>
</alarm>
<alarm id="THRESH_MEM_EXCEEDED">
<shorttitle>Memory usage threshold exceeded</shorttitle>
<description>The threshold for memory usage on {0} has been exceeded. The threshold is {1}%. The current value is {2}%.</description>
<resolution>If condition persists, check for runaway or orphaned processes. Consider restarting the system.</resolution>
</alarm>
<alarm id="THRESH_MEM_OK">
<shorttitle>Memory usage threshold recovered</shorttitle>
<description>Memory usage on {0} has recovered back to {2}%. The threshold is {1}%.</description>
<resolution>No action is required.</resolution>
</alarm>
<!-- Add new alarms above this line.
Notes:
Make sure the block begins with the 'alarm' tag and ends with '/alarm'.
'id=' must match definition in etc/sipXalarms-config.xml
'shorttitle' contains a short title to be used in email subject headers.
'description' contains text to be sent in alarm notifications. Parameters may be
inserted at runtime by using placeholders of the format {0}, {1}, etc.
XML reserved characters (<, >, &) should be escaped as in
this example.
'resolution' contains text to be sent in alarm notifications. It should provide any
steps the customer could follow to solve or debug the problem.
-->
</definitions>
</alarm_server>
<?xml version="1.0"?>
<!-- INSTRUCTIONS FOR DESIGNERS WISHING TO ADD AN ALARM
Each sipX alarm is defined in the definitions section below.
Each alarm should have a unique id, which is an internal (not customer-visible) string.
Each alarm also has a unique code, which is customer-visible, and should be of the form
SPXnnnnn where nnn is a sequential number. Add new alarms at the end of the file.
The severity, component, and actions for each alarm are specified here.
Current action are log and email, and the default for both is "true" if not specified.
Strings containing the alarm description, and suggested actions to resolve it, must
be added in the meta/alarms/sipXalarms-strings.xml file. These strings could be localized for
different languages.
-->
<alarm_server xmlns="http://www.sipfoundry.org/sipX/schema/xml/alarm-00-00";>
<!-- Per-alarm definitions. Only the action are (or could be) configurable. -->
<definitions>
<alarm id="SERVTEST_FAILURE">
<code>SPX00001</code>
<severity>warning</severity>
<component>sipxserv-test</component>
<action log="true"
email="true"
/>
</alarm>
<alarm id="PROCESS_RESTARTED">
<code>SPX00002</code>
<severity>warning</severity>
<component>sipXsupervisor</component>
<action log="true"
email="false"
/>
</alarm>
<alarm id="PROCESS_FAILED_RESTART">
<code>SPX00003</code>
<severity>error</severity>
<component>sipXsupervisor</component>
<action log="true"
email="true"
/>
</alarm>
<alarm id="PROCESS_FAILED">
<code>SPX00004</code>
<severity>crit</severity>
<component>sipXsupervisor</component>
<action log="true"
email="true"
/>
</alarm>
<alarm id="LOGIN_FAILED">
<code>SPX00005</code>
<severity>warning</severity>
<component>sipXconfig</component>
<action log="true"
email="true"
/>
<filter min_threshold="3"
/>
</alarm>
<alarm id="THRESH_CPUUTIL_EXCEEDED">
<code>SPX00006</code>
<severity>warning</severity>
<component>mrtg</component>
</alarm>
<alarm id="THRESH_CPUUTIL_OK">
<code>SPX00007</code>
<severity>info</severity>
<component>mrtg</component>
</alarm>
<alarm id="THRESH_DISK_EXCEEDED">
<code>SPX00008</code>
<severity>warning</severity>
<component>mrtg</component>
</alarm>
<alarm id="THRESH_DISK_OK">
<code>SPX00009</code>
<severity>info</severity>
<component>mrtg</component>
</alarm>
<alarm id="THRESH_MEM_EXCEEDED">
<code>SPX00010</code>
<severity>warning</severity>
<component>mrtg</component>
</alarm>
<alarm id="THRESH_MEM_OK">
<code>SPX00011</code>
<severity>info</severity>
<component>mrtg</component>
</alarm>
<!-- Add new alarms above this line.
Remember to add strings into meta/alarms/sipXalarms-strings.xml also.
Notes:
Make sure the block begins with the 'alarm' tag and ends with '/alarm'.
'id=' the id can be any unique string (no spaces). This is how the alarm is raised
by application code.
'code' should be unique, and of the form SPXnnnnn, incremented for each new alarm
'severity' is one of debug, info, notice, warning, err, crit
'component' as appropriate (e.g. sipXconfig, sipXregistrar, etc)
'action' is optional. Default for all notifiers is "true".
'filter' specifies optional rudimentary thresholds:
'min_threshold' means the alarm should only be reported after this many occurrences
in a short time. Default is 0 (i.e. report always).
'max_reports' means the alarm should only be reported this many times
in a short time. Default is INT_MAX (i.e. report always).
-->
</definitions>
</alarm_server>
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
