Alerting on web scenarios

Let's create a trigger that warns us when any one of the steps in the scenario fails. As discovered previously, the failed step item holds 0 when all is good. Anything else is a sequential number of the step that failed. As a web scenario stops at any failure, a failed step number of 3 means that the first two steps were executed successfully, and then the third step failed. If there were any further steps, we don't know their state—they were not processed.

To create a trigger, we always need an item key. We could try to find it in the item list. Go to Configuration | Hosts and click on Items next to the OpenStreetMap host, no items. The reason is that these items are special—they are items that are internal to Zabbix web scenarios (not to be confused with the internal monitoring items, discussed in Chapter 20, Zabbix Maintenance), and thus are not available for manual configuration. We should be able to select them when creating a trigger, though. Click on Triggers in the navigation header, and then click on Create trigger.

In the trigger-editing form, enter these values:

  • Name: {HOST.NAME} website problem.
  • Expression: Click on Add, then click on Select next to the Item field in the resulting popup. Select Web pages in the Group drop-down and OpenStreetMap in the Host drop-down.
  • Then, click on Failed step of scenario Main page in the Name column. We have to find out when this item is not returning zero.
  • In the Function drop-down, choose last() - Last (most recent T value).
  • For Result, choose <> and 0.

The final trigger expression should be as follows:

{OpenStreetMap:web.test.fail[Main page].last()}<>0 

When you are done, click on the Add button at the bottom. We can see how the web.test.fail[Main page] item key was used, thus, web scenario items are very much like normal items. They have names and keys, even though they can't be seen in the item configuration view. This way, we can create triggers for all web scenario items, such as response time and download speed, to also spot performance issues, or for return codes so that we can spot exact at what step it has failed. The same items are available for custom graphs, too.

The trigger we created would alert upon the first failure in this web scenario. You might want to make this monitoring less sensitive, and there are at least two ways to achieve that:

  • Set Attempts in the scenario properties to a larger value.
  • Check item values over a longer period of time. We discussed such a strategy in Chapter 6, Detecting Problems with Triggers.
The count function could be a good candidate here as we could count the number of values over a certain period of time that are over a value, for example, count(10m,0,gt) would count the values for the last 10 minutes that are over 0.

If a web-monitoring step fails, Zabbix stops and does not proceed to the next step. If the website you are monitoring has multiple sections that can work independently of one another, you should create a separate scenario for each.

When web monitoring fails, it could be very useful to know what exactly we received from the web server. Unfortunately, Zabbix does not store retrieved content anywhere by default. We'll discuss a way to temporarily view all the retrieved web pages in the Controlling running daemons section of Appendix A, Troubleshooting.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset