Right, so we configured e-mail sending. But it's not so interesting until we actually receive some notifications. Let's increase the load on our test system. In the console, launch this:
$ cat /dev/urandom | md5sum
This grabs a pseudorandom, 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:
There is one of the frontend messages we enabled earlier in our user profile. Let's look at what is shown in the message window:
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, which is as follows:
The frontend messaging is useful as it provides:
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:
Here is what these parameters mean:
no_sound
from the dropdown.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 | Triggers. We should see the CPU load too high on A test host for last 3 minutes
trigger visible with a red, flashing PROBLEM text in the STATUS column:
However, if you have a new e-mail notification, you should already be aware of this state change before opening Monitoring | Triggers. If all went as expected, you should have received an e-mail informing you about the problem, so check your e-mail 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 e-mail 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 e-mail 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 e-mail: 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.
Congratulations, you have set up all required configuration to receive alerts whenever something goes wrong as well as when things go back to normal. Let's recall what we did and learned:
18.220.43.134