In the above example the counter with a count of 5 will be reduced every twelve minutes rather than every six. This is a variant of the Token Bucket algorithm in which the counter is reduced more slowly as it becomes lower. The trigger will thus be pulled when the average rate that messages are received persistently remains at over ten per hour. If with this procedure the counter returns to zero the event will be deleted. And every six minutes the counter will be reduced by one – regardless of whether a message has been received or not. Every subsequent message will increment this count by one. If an applicable message is received, an event in the counting phase will be generated and its count set to ‘1’. Let us assume that ten messages per hour have been configured. This algorithm does not work with fixed time periods, rather it implements a procedure that is often used for Trafficshaping in networks. If however the count limit is reached before the time period has expired, then the event will be opened immediately (triggering any possibly configured action). Should the defined time period expire before the defined count limit is reached the event will be silently deleted.
An event in the counting phase will be generated. The timing interval begins when the first applicable message is received. Since there is no single solution for this Checkmk provides three differentĭefinitions of what “ten messages per hour” should actually mean: Algorithm Incidentally, the ID will still be retained even if in the meantime the rule itself no longer exists. Clicking on the ID will directly open the rule’s details. The ID of the rule which created this event. In such a case the Host alias, Host contacts and Host icons fields are filled out and the host appears in the same style as in the active monitoring. If a host with this name really exists in the monitoring, the EC automatically establishes a connection. It is not essential that the host be one that is actively monitored by Checkmk. The name of the host that sent the message. The event’s actual content: A text message. There are however situations in which an OK-Event can make sense. Events with an OK status are rather uncommon, since the EC has really been conceived to only filter out problems. I would like to briefly touch on the most important fields here: FieldĪs mentioned in the introduction, every event is classified as OK, WARN, CRIT or UNKNOWN. As can be seen, an event has many data fields whose functions will be explained
0 kommentar(er)
