#Autopurge incident define full
#Autopurge incident define plus

Currently the EC does not support repeated notification when an event has not been acknowledged.įor events that are counted, this is the time of the latest occurrence of a message associated with the event. This is fixed to 1, so no escalation is possible in this case, likewise for when multiple consecutive events of the same kind happen independently from each other. If this field is empty, Event Console will be entered. This is the content of the event’s Application field. We have just described how the host’s data is determined.ĮC notifications are always considered to be Service messages.

In the process the typical data fields for a notification are filled as effectively as possible. In order for notifications from the EC to pass through the active monitoring’s notification system, the EC must be adapted to to conform to its scheme. Thursday because - the start of the 'epoch', was on a Thursday.

#Autopurge incident define plus

You can specify a time zone offset from 0 to 47 here, referring to 00:00:00 UTC.Īt 00:00 on Thursday morning in the UTC time zone plus the offset, which you can output in hours.

#Autopurge incident define full

For example, if you are in the UTC+1 time zone yourself, specify UTC-11.Īt the beginning of a full hour. This also allows you to say that you expect a message between 12:00 and 12:00 the next day. The time period is always aligned exactly to defined positions.įor example, the interval hour always starts at minute and second zero.Įxactly at 00:00, but in a configurable time zone. Here, however, a completely different algorithm is used, which makes much more sense at this point. The overall effect of this is that notification rates just above the allowed rate will open an event (and thus be notified) much faster.Īs with counting, you need to specify a time period in which you expect the message(s) to appear. In the above example, if the counter was 5, it would only decrease every 12 minutes instead of every 6 minutes. This is a variant of the Token Bucket algorithm, where the smaller the counter is at any given time, the slower it decreases. So the trigger is fired when the rate of messages on average is permanently above 10 per hour. If the counter drops to 0 again, the event is deleted. And every 6 minutes, the counter is decreased by 1 again - regardless of whether a message has come or not. For each subsequent message, this is increased by 1. The first time a matching message is received, an event is generated in the counting phase and the count is set to 1. That’s an average of one every 6 minutes. Suppose you have configured 10 messages per hour. This algorithm does not work with fixed time intervals, but implements a method that is often used in networks for traffic shaping. However, if the count is reached before the time expires, the event is opened immediately (and any configured actions are triggered). If the specified time elapses before the count is reached, the event is silently deleted. An event in the counting phase is generated. Since there is no single solution to this problem, Checkmk provides three different definitions of exactly what '10 messages per hour' should mean: AlgorithmĬounting interval starts at the first incoming matching message.