- Install Promonitor
Deadlocks can significantly reduce the performance of the applications and the response time for the users. This is usually reflecting a blocking situation which can last a long time. It is therefore very important to detect deadlocks and act rapidly to resolve them if necessary.
Surveillance table: This is a table of rules that you can use to configure and customize the configuration. Each line of the table will define a rule of monitoring. You can combine multiple rules to cover different cases. Within a rule, you can configure a threshold for the number of deadlocks to reach before sending an alert
Max dead locks: Use the multi-threshold syntax to set multiple threshold/severity associations: G2W:1 W2M:5 (Green To Warning, Warning To Major, etc…). An alarm of the corresponding severity will be sent if the number of deadlocks is reaching the threshold. Set 0 in the field if unused
This monitor will look for deadlocks that occurred since the last check. It will cope with server restart up to a period of 2 hours of down time.
|Active||If checked, the rule is enabled and will be processed|
|Max dead locks||The threshold for the maximum number of deadlocks. You must use the multi-threshold syntax (G2W:1 W2M:5 etc…)|
|Auto clear||If set, the generated alarms will be automatically cleared from the console if the alarm condition is not fulfilled anymore|
|Alarm tag||This field allows to add custom text within the alarm message. %MSG% variable will contain the actual generated message and can be used such as: “my_prefix %MSG% my_suffix”. By default, tag will be used as prefix.|
|Alarm||Defines if the alerting is active for this rule.|
|Metric||Defines if the metric generation is active for this rule.|
|Report||If checked, this rule will be used for showing threshold and severity in the daily report|
|Active||Max messages||Auto clear||Alarm tag||Alarm||Metric||Report|
Effect : A MAJOR alarm is sent if a deadlock is found since the last check