Let's create some load
Right, so we configured sending email. But it's not very interesting until we actually receive some notifications. Let's increase the load on our test system. In the console, launch the following:
$ cat /dev/urandom | md5sum
This grabs a pseudo random, never-ending character stream and calculates its MD5 checksum, so system load should increase as a result. You can observe the outcome as a graph—navigate to Monitoring | Latest data and click on Graph for our single item again.
Notice how the system load has climbed. If your test system can cope with such a process really well, it might not be enough—in such a case, you can try running multiple such MD5 checksum calculation processes simultaneously.
Allow 3 minutes to pass and there should be a popup in the upper-right corner, accompanied by a sound alert:
The third link leads to the event details, displaying more information about this particular occurrence.
The window itself can be repositioned vertically, but not horizontally—just drag it by the title bar. At the top of the window, there are three buttons.
These buttons also have tooltips to remind us what they do, as follows:
- The snooze button silences the alarm sound that is currently being played.
- The mute/unmute button allows you to disable/enable all sounds.
- The clear button clears the currently visible messages. A problem that is cleared this way will not show up later unless it is resolved and then happens again.
Frontend messaging is useful as it provides the following:
- Notifications of new and resolved problems when you aren't explicitly looking at a list of current issues
- Sound alarms
- Quick access to problem details
Now is a good time to revisit the configuration options of these frontend messages. Open the profile again by clicking on the link in the upper-right corner, and switch to the Messaging tab:
Previously, when configuring frontend messaging, we set the message timeout to 180 seconds. The only reason was to give us enough time to explore the popup when it first appeared; it is not a requirement for using this feature.
Now, let's open Monitoring | Problems?and select Recent Problems?for? show,?and?A test hosts?for Hosts.?We should see the CPU load too high on A test host for last 3 minutes trigger visible with red, flashing PROBLEM text in the Status column.
However, if you have a new email notification, you should already be aware of this state change before opening Monitoring | Triggers. If all went as expected, you should have received an email informing you about the problem, so check your email client if you haven't yet. There should be a message with the subject PROBLEM: CPU load too high on A test host for last 3 minutes.
Did the email fail to arrive? This is most often caused by some misconfiguration in the mail delivery chain preventing the message from passing. If possible, check your email server's log files as well as network connectivity and spam filters. Going to Reports | Action log might reveal a helpful error message.
You can stop all MD5 checksum calculation processes now with a simple Ctrl + C. The trigger should then change status to OK, though you should allow at least the configured item interval of 30 seconds to pass.
Again, check your email: there should be another message, this time informing you that it's alright now, having the subject OK: CPU load too high on A test host for last 3 minutes.
Another place where we can see our trigger is on the dashboard in the Problems widget.? We see that stat status is RESOLVED, and at the end, we will be able to see?an arrow?in red under Actions if something has failed. When we move our mouse over the arrow, we will see three actions: the first one was the email that was sent; the second icon is the calendar with the V in it, when the problem was resolved; and the third is the calendar with the exclamation mark inside, when the problem happened. After the envelope, you will see the reason why the email was not sent: