If you have not read Indexes 101 Jump There Now then read this.
Currently notifications are facilitated via email and we do support sms via email. Unified Logging uses a list of email to text to email address, which can be accessed on the portal while creating an index, to determine if a shorter sms message should be sent as a notification. We are planning to offer a post notification in the future. Please use notifications responsibly and do not add email addresses to an Index Notification that should not be notified as this creates spam and a possible security risk to your account as there is a quick link in the notification to view online.
Notification Conditions is perhaps the most powerful feature of Unified Logging. Indexes can have three different notification conditions, Notify Immediately, Notify Once if Matched in X Minutes, Notify if Matched X Times in Y Minutes.
Notify Immediately (Deprecated – Use Notify Once if Matched in 1 Minute Notification Condition): This is pretty self explanatory, when the index is matched notify immediately. You should have at least one of these as your lowest priority notification as a fall through if other notification indexes are not matched.
Notify Once if Matched in X Minutes: This condition is what we call the fire hose condition and will most likely get application support engineers hugging you. If and index is matched many times in, let’s say, 30 minutes you will receive one notification instead of the possible thousands.
Notify if Matched X Times in Y Minutes: This condition is helpful if you want to know if something happened X times in Y minutes, say a nightly batch process to pay customers; you would want to know if that was run twice.
Index Priority Order
The index priority order only applies to indexes that have a notification. The way this works is the highest priority index matched is the one that triggers the notification. If the notification is matched but the notification condition is not satisfied the index is still considered a match and no further notification processing takes place. This may be best illustrated with a scenario.
Text sent in: “really bad error”
We have three indexes for notifications:
Index 1: Matches “really bad error” – Condition: Notify Once if matched in 30 minutes
Index 2: Matches “bad error” – Condition: Notify Once if matched in 15 minutes
Index 3: Matches “error” – Condition: Notify Immediately
Message 1 “really bad error” sent in -> Matches and Notifies via Index 1
Message 2 “bad error” sent in -> Matches and Notifies via Index 2
Message 3 “error” sent in -> Matches and Notifies via Index 3
Message 4 “bad error” sent in 1 minute later -> Matches Index 2 but no notification sent because it is 1 minute past last message that matched Index 2.
Message 5 “some other error” sent in -> Matches Index 3 and notifies; this is a fall through case.
Structuring your indexes correctly is important to receive the right information without a lot of noise. The fall through case is very important because this will catch things unknown.