We will also configure the active checks, where checks are initiated by the check logic in the Nagios daemon by using the service definition to also monitor the critical/warning alarms reported by our cluster. ![]() In Nagios, the term for this is passive check, whereby Nagios does not attempt to determine whether or host/service is DOWN or UNREACHABLE. Both notification events can be used to signal our Nagios service, whether the cluster is actively having critical alarms or not. The notifications (or traps) are criticalAlarmNotification and criticalAlarmNotificationEnded. "Notification ended - Critical alarm is 0" "Notification if critical alarm is not 0"ĬriticalAlarmNotificationEnded NOTIFICATION-TYPE ![]() SNMP traps are the most frequently used alert messages sent from a remote SNMP-enabled device (an agent) to a central collector, the “SNMP manager.” In the case of ClusterControl, a trap could be an alert after the critical alarm for a cluster is not 0, indicating something bad is happening.Īs shown in the previous blog post, for the purpose of this proof-of-concept, we have two SNMP trap notifications definition: criticalAlarmNotification NOTIFICATION-TYPE ![]() In this blog post, we are going to focus on SNMP traps and alerting. This blog post is a continuation of the previous part 1, where we have covered the basics of SNMP integration with ClusterControl.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |