From the Entry Editor, click on the Alerts Tab, click on Syslog Tab
Syslog Alert Configuration
Send alerts to a Syslog daemon containing message information based on the results of an monitored entry.If you are familiar with Syslog, you may find this notification option quite handy. If you do not use Syslog, or you don't run a Syslog Daemon, or don't know what Syslog is, you can find an abundance of information by searching the web for "Syslog" or "syslogd".
Simply put, a Syslog daemon accepts and logs incoming messages from a remote (or local) machine/device. You can trap and filter these messages and perform specific tasks, or just let them pile up in a log file depending on the functionality implemented on the system on which the Syslog daemon is running.
Please see the How-To section for additional information on various configurations.Syslogd IP
Enter the IP Address of the machine on which the Syslog daemon is running. ipSentry will send a Syslog formatted message to this IP Address based on the alert settings and schedule.Port
The default port for Syslog is 514. If you have modified Syslog to listen on an alternate port, enter that here instead.Facility
Syslog makes use of a Facility:Priority combinations when receiving messages. These settings are used for log division, and trigger options on the Syslog server. Configure these settings to taste based on your Syslog daemon configuration.
Based on its configuration, syslogd can perform a given action for messages with a specified priority (or higher) and facility. By using the facility, messages generated by different system components can be logged with different priorities.
The following facilities are supported:
Facility
Description
auth
Used by authorization systems (login)
cron
Used for the cron and at systems
daemon
System/network daemons
kern
Produced by kernel messages
lpr
Printing system
Mail system
mark
Internally used for time stamps
news
Reserved for the news system
user
Default facility, used for any program
uucp
Reserved for the UUCP system
Priority
Syslog makes use of a Facility:Priority combinations when receiving messages. These settings are used for log division, and trigger options on the Syslog server. Configure these settings to taste based on your Syslog daemon configuration.
Based on its configuration, syslogd can perform a given action for messages with a specified priority (or higher) and facility. By using the facility, messages generated by different system components can be logged with different priorities.
Priority
Description
debug
Normally used for debugging
info
Informational messages
notice
Conditions that may require attention
warning
Any warnings
err
Any errors
crit
Critical conditions like hardware problems
alert
Any condition that demand immediate attention
emerg
Any emergency condition
Message
Enter the text of the message that should be sent to the Syslog daemon. All ipSentry Key Words used in this field will be translated and proper use of these key words in association with the facility and priority settings can provide you with a means for the syslogd server to react to the given message.
For more information on Syslog, see the documentation and man pages regarding your implementation of syslogd and it's capabilities.
Alert Status
This group represents the status of the selected alert for the device.
Enabled
When this option is selected, the configuration details for the alert are active and specific to this entry. Other entries may reference this entry.Disabled
When this option is selected, no alerting of this type will be performed by the selected entry when a CRITICAL result is encounteredUse From
When this option is selected, the alert configuration defined in the selected entry (named in the field next to this selected) will be utilized. You will use this option when you wish to utilize a group or template reference for alerting configurations. By clicking on the browse button (...), you will be presented with a list of entries from which you may use their configuration for the specified alert.
When selecting this option, all detail entry fields will be disabled.Trigger on recovery count
When this option is selected, the alert specified will also be triggered when the system recovers from a critical state. The most common uses for this option are in email messaging and pager/cell/SMS messaging where you specify the %%mach.state%% keyword in the alert messages. This way, if a system fails and then recovers, the recipient of the notification would be alerted to this fact.The value that you enter after this option is the number of successful (OK) results that must occur after a failure before the entry is deemed 'recovered'. If you enter a value of say three (3) in this field, ipSentry will need to monitor this item at least 3 times, with three successful results before any recovery alert would be generated. This helps avoid constant UP/DOWN/UP/DOWN notifications.
For add-in alerts, this option will be specific and specified within each add-in configuration entry.Alert Schedule
The alert schedule provides you with the ability to define the failure count requirements and alert/notification quantities that will be generated. For example, you may want to be alerted immediately upon failure of a device, but from that point on, if the device is still failing, you may only want to be alerted every 5 failures and receive no more than 6 alerts during any constantly failed duration. This is exactly where you specify this information.
For add-in alerts, this option will be specific and specified within each add-in configuration entry.
First After
This field represents how many failures (sequential) must occur before any failure notifications are triggered. A value of 1 will cause immediate notification upon the first failure. A value of 2 or more will require that number of failures before the first alert is generated. In the example scenario above, you would enter a 1 in this field.Then Every
This field represents the number of failures that must occur before further alert/notification actions are taken once the first notification has been processed. In the example scenario above, you would enter a 10 in this field.No More Than...
This field represents that maximum number of times that the alert will be triggered during a failure. If you set this value to -1, there is no maximum. If you set this value to zero - you might as well just disable the alert. In the example scenario above, you would enter a 6 in this field so that no more than the alert will be triggered no more than 6 times during a failure.
Load From
Click this button to load the alert configuration data from another entry in the ipSentry system. This function comes in handy when you have an alert configured that needs only minor changes for the current configuration. Once you select a device from which to copy the alert, the configuration of that alert will be populated into the appropriate fields.Copy To
Click this button to copy the current alert configuration being modified to one or more existing entries. This allows for the bulk duplication of alert configurations via entry selection. You will be presented with a list of entries to which you wish to apply this alert configuration.Test Alert
Click this button to test your alert configuration settings and insure that the basic configuration is correct.You will be presented with a dialogue requesting whether you wish to test as critical or as a recovery type alert.
After selecting to test as Critical or Recover, you will be presented with an active display during the test.
Note that when testing alerts, many of the keyword will not contain accurate data since there will be no monitoring data available. For example, if use the %%mach.trimres_fxxxx%% keyword, the result will either be empty or contain the results of the last live monitoring of the current item.
When testing alerts to insure that keyword structures are correct, the result text should not contain the keyword. The data will either be replaced with nothing (if no data is available) or it will be replaced with the correct data.
For example: If you enter the keyword %%mach.nameX%%, this is an invalid keyword so it will not be replaced and will be included as it is entered. However, if you enter %%mach.name%%, this will be replaced. Similarly, if you use a keyword such as %%mach.drive.minfree%% and have the alert tied to a service monitor, the value will be unknown since service monitoring does not use this value - but the keyword will NOT exist in the resulting message data.