Как проверить доступность сайта в zabbix

Zabbix Monitoring a Website

On the dashboard screen, access the Configuration menu and select the Host option. On the Host properties screen, access the Applications tab. On the top right part of the screen, click on the Create application button and name the application according to the website you want to monitor, e.g. INSTAR Forum Website Monitor :

Back on the Application Screen on the top right, click on the Web Scenarios link and then the Create Web Scenario button. On the web scenario screen, you need to configure the following items:

• Name: Enter a website identification.
• Application: Choose the application you created before, e.g. INSTAR Forum Website Monitor .
• Update interval: 1 Minute
• Agent: Zabbix
• Enabled: Yes

Access the Steps tab to add a new step and configure the following items:

• Name: Enter an identification.
• URL: Enter the website URL
• Follow redirects: Yes
• Retrieve mode: Headers
• Require status code: 200

Click on the Add button to finish the web scenario configuration and wait 5 minutes. In order to test your configuration, access the Monitoring menu, click on the Latest data and filter for your server and application:

Login Check​

Frontend Login​

Go to Configuration → Hosts, pick a host and click on Web in the row of that host. Then click on Create web scenario.

In the new scenario form we will name the scenario as Zabbix Login and create a new Zabbix Login application for it. Note that we will also create two variables: and .

Now we can define steps for the scenario. Click on Add button in the Steps tab to add individual steps. We start by checking that the first page responds correctly, returns with HTTP response code 200 and contains text Zabbix SIA :

When done configuring the step, click on Add. You can check if the service is running and receiving the correct HTTP response code:

We continue by logging in to the Zabbix frontend, and we do so by reusing the variables we defined on the scenario level — and . Take note also of how we are getting the content of the variable (session ID) using a variable syntax with regular expression regex:name="csrf-token" content="([0-9a-z]<16>)" :

Verifying that Content is available​

Being logged in, we should now verify a string, that is only visible when logged in, is available to our user — for example, Reports . We can do this by adding another step to our scenario:

Now that we have verified that frontend is accessible and we can log in and retrieve logged-in content, we should also log out — otherwise Zabbix database will become polluted with lots and lots of open session records:

We can also check that we successfully logged out by looking for the Username string:

A complete configuration of web scenario steps should look like this:

To view web scenario information go to Monitoring → Hosts, locate the host in the list and click on the Web hyperlink in the last column:

Triggers and Notifications​

Create alarm triggers​

A trigger is the event that triggers email notifications. Triggers are built using an expression. Select Configuration > Hosts > Host Name > Triggers and click Create trigger:

In this example, since you are using a web scenario, you want to create a trigger for when the web scenario code is anything other than a success based on the HTTP status code. Use the following expression:

Realworld Scenarios​

Discourse Forum​

You can test for the Health Check URL URL/srv/status . This URL will return a ok when your Discourse installation is happy:

Elasticsearch Cluster​

You can test for the Health Check URL URL/_cluster/health . Or use a search query that will return a guaranteed answer — for example you can check if the request did not time-out "timed_out":false :

Gitlab C/I Server​

GitLab provides liveness and readiness probes to indicate service health and reachability to required services. These probes report on the status of the database connection, Redis connection, and access to the filesystem. To control access to those endpoints via IP whitelisting, you can add single hosts or use IP ranges:

Как проверить доступность сайта в zabbix

I continue my series of articles on setting up a monitoring system based on a popular free product, which has been the subject of heated debate on social media these days, provoked by The Marketing Heaven. This time we will setting up a web site monitoring with zabbix server. As an example, take some third-party resource and check on it the standard functionality.

Introduction

To monitor the web site, we will use the standard zabbix functionality. Here are the parameters for which we will observe:

• Availability.
• Response time in milliseconds.
• Access speed.
• Work authorization on the site.

To do this, we will perform the following sequence of actions:

• Create a template for monitoring sites.
• Configure Web scenarios.
• Create graphs.
• Add triggers to check the availability and download speed of the site.

We proceed to setting up monitoring. We will use only the standard functionality available after installation. There will be no additional user parameters or scripts. If you do not have your own monitoring server, I recommend post on this site – install and configure zabbix.

Adding a web site to the monitoring

The easiest way to connect a site to monitoring is to add its check on an already existing host. In this case there is one big disadvantage – if you want to enable this monitoring from another host, or simply transfer to another server, then it will be difficult to do so. It is much more easy to monitor sites and everything connected with it, set up in a separate template. So go to the section Configuration -> Templates and create a new template.

A standard form for creating a template opens. Enter the name of the template, where the settings for monitoring sites will be, and add it to some group.

Open this template. Go to the Web Scenarios tab and add a new web scenario to monitor the site.

Fill in the basic parameters of the script. As a name, I usually specify the address of the site. In my example it will be github.com. Set the name of the application for monitoring sites for easy sorting of items related to the sites, the interval of testing and the number of connection attempts.

After that, go to the Steps tab and add the verification step.

Then I specify the parameters of the step.

Let me explain each parameter:

• Name – the name of the step. In this case, the main page of the site will be checked, therefore I call the step index. This is not important, but I recommend giving names meaningful, so that later it would be convenient to operate with names, for example, in triggers.
• URL – the address of the page to be checked.
• Required string – the string on the page that zabbix will look for. I took the string from the footer site. If zabbix find it on the page, it will assume that the site is all right. If not, it will bee an error.
• Required status codes – the required response code. I specify 200. If zabbix receives some other code in response from the web server, the check has failed.

After filling in all the parameters, click Add to add a step and then Add again to add the verification script itself. It should turn out like this.

The simplest site availability check is done. Next we need to attach this template to some host, so that the actual checks start. I will attach the template to the zabbix server itself. To do this, go to Configuration -> Hosts, select Zabbix Server and attach the template created earlier to it.

We wait a few minutes and go to the section Monitoring -> Web to watch the results of monitoring the site github.com.

The response code 200, the search string was found, which confirms Status OK. Here is graphics site download speed and response time. For more information about monitoring the specified site can be found in Latest Data.

The value of the parameter Failed step of scenario “github.com” equal to 0 means that all steps to check the site were completed without errors. If you have several steps and one of them is finished with an error, there will be a number of this step. That is, in general, all that is not 0, these are some problems. Later we will use it in the trigger. In the meantime, add a couple of graphs to the template, which can then be used in dashboards.

Setting up web site monitoring graphs

We return to our template and go to the Graphs section. Create a new graph.

Add a graph of the download speed for the main page of the site.

Similarly, you can add a site response time. I once added both of these graphics to Screen. It should turn out like this.

For more usefull visualizations, it is better to use Dashboards. Now we will configure monitoring of the site with authorization.

Website monitoring with authorization

Let’s complicate the task a bit. Let’s try to authorize the site and monitor both the authorization itself and the closed page behind it. For example, I will take the forum centos.org/forums/, log in to it, and after logging in I will check the page with the personal information of a specific user.

In order to set up a monitoring site with authorization in zabbix, you need to correctly prepare a post request. To do this, I go to the page with authorization. In this case, it is https://www.centos.org/forums/ucp.php?mode=login, open DevTools in Сhrome, tab Network. I fill in the fields of the authorization form with knowingly incorrect data so that the authorization ends with an error. After this error, I look at the headers of the post request.

I click on the view source in the Form Data section and copy the resulting string. In my case, it was this:

From here you can precisely remove the redirect parameter. As a result, I save the following line:

Now I’m going to a template for monitoring sites and adding a new site – centos.org. I create the first step with authorization, call it auth. In it I specify post request for authorization.

Do not forget to change the password to the correct one. After successful authorization, you will see the main page of the forum, where there will be a link to private forum messages. This link is available only after authorization.

The next step is to check the Private messages line on the main forum page.

Steps are performed sequentially. In the first step, we only log in, in the second we check the page that is available after authorization. Go to Latest Data and see the result.

Both steps completed successfully, no errors. Let’s look at the section Monitoring -> Web.

Everything is all right. It is clearly seen that the authorization process is much longer and slower than the loading of the main page.

Site unavailability alert

Let’s set up notifications about problems on the site. I offer 2 types of alerts:

• Low site access speed.
• The site availability.

We go, as usual in the original template, on the Triggers tab and add a new one.

I propose such a trigger condition to determine the inaccessibility of the site. If the average value of the last 3 checks is greater than or equal to one, then the site unavailability warning is triggered.

When 0 goes in all checks, everything is in order. The trigger will work only if all 3 last checks are not zero. In my example, Failed step can be either 0 or 1, where 1 is the number of the failed step. If you have several steps, then the second step or the third step may be a failure. That is, the value can be greater than 1. But in any case, if the last 3 values in a row are strictly not 0, then the trigger is triggered. The recovery operation is very simple. If the last check without error, that is, the code is 0, then we consider that the site is already working.

To test the trigger, it is enough to add a line to the /etc/hosts file on the zabbix server:

and wait 3 minutes to get 3 unsuccessful checks. After that, you should have been sent a notification about the inaccessibility of the site. I got this:

Next, we check the server response time. Here everyone is free to tune in as it seems to him more correct and convenient. I use such a scheme. I take the average response time of the site and multiply it by 3. Then I look at the last 7 checks. If in 5 checks among these seven there were values ​​higher than the tripled average response time, then I consider that the site slows down and it is necessary to send a notification. It is a bit confusing, but in practice such a scheme I have recommended myself well without false positives. However, if there are real problems, I see them. We make the trigger.

Condition recovery – in the last three requests, two or more were faster than the tripled average access time. Expression text to copy:

Here 1.5 is the response time in seconds. You can check it in Latest Data.

In conclusion, I leave my template that I created for writing the article. You can copy and edit to adapt it for your sites. It is faster than being from scratch. Template exported from zabbix version 4.0 – sites_monitoring.xml

That’s all, web site monitoring works, authorization is checked, the site unavailability notification is configured. For completeness, you can create a Screen or Dashboard with the output of all the necessary parameters on one screen. Its settings will already depend on the specific situation and the data that you have. For example, if you have configured web server monitoring, then you can place a number of graphs of its download and parameters of access to the site. There you can also add the load of the server itself on the processor and memory and display a graph of the use of the network interface.

Zabbix is very flexible and allows you to customize everything for every taste and under any requirements.

Conclusion

I will add a few words on how this web site monitoring can be used. I had two hosting and wanted to choose one faster. The load of the server itself for the hardware was so low that it could not be taken at all into account. The more important parameter was the response time of the server and the speed of access to it. I launched the site on both servers and set up monitoring. By its parameters chose a faster server.

Of course, here you need to understand that the data of such monitoring is very conditional and depends on where the zabbix server itself is located. It is possible that the monitoring of all sites will show approximately the same numbers due to the limitations of the monitoring server itself. You need to have this in mind. Still quite often when checking the response time of the site, there are big dips in time to 5-10-15 seconds. This greatly affects the average access time. These failures occur due to temporary network problems not necessarily on the site itself. This also needs to be taken into account when analyzing the obtained data.

In any case, you need to approach the analysis of the site monitoring data. In most cases, not the values ​​themselves are important, but the general trends of their changes in comparison with other hosts. Consider it. I have it all.

Zabbix мониторинг вэб-сайта

Для мониторинга веб сайта будем использовать стандартный функционал zabbix. Следим за доступностью сайта, временем ответа сайта в миллисекундах, скоростью доступа к сайту. Используется только стандартный функционал, скриптов не будет.

Идем в Настройка -> Узлы и жмем Создать узел сети

В списке хостов появился новый trakrd.ru

Дальше настроим мониторинг сайта. На странице со списком хостов, в строке trakrd.ru нажимаем на ссылку Web

В разделе web сценариев у нас пусто, создаем новый сценарий проверки, нажав на Создать вэб сценарий

Переходим на вкладку Шаги и нажимаем Добавить. Откроется форма, заполняем ее

9. Веб-мониторинг

Для выполнения веб-мониторинга Zabbix сервер должен быть изначально сконфигурирован с поддержкой cURL (libcurl).

Для активации веб-мониторинга вам необходимо определить веб-сценарии. Веб-сценарий состоит из одного или нескольких запросов HTTP или «шагов». Шаги периодически выполняются Zabbix сервером в предопределенном порядке. Если узел сети наблюдается через прокси, тогда шаги выполняются на этом прокси.

Начиная с Zabbix 2.2 веб-сценарии привязываются к узлам сети/шаблонам тем же образом как элементы данных, триггеры и т.д. Это означает, что веб-сценарии можно создавать не уровне шаблона и далее применять к нескольким узлам сети одним движением.

Каждым веб-сценарием собирается следующая информация:

• средняя скорость загрузки в секунду для всех шагов для всего сценария
• номер шага, который завершился с ошибкой
• последнее сообщение об ошибке

На каждом шаге веб-сценария собирается следующая информация:

• скорость загрузки в секунду
• время ответа
• код ответа

Для получения более детальных сведений смотрите элементы данных веб мониторинга.

Собранные данные с выполненных веб-сценариев хранятся в базе данных. Эти данные автоматически используются для графиков, триггеров и оповещений.

Zabbix может также проверять содержит ли полученная HTML страница заданную строку. Он может выполнить эмуляцию входа и следовать пути, эмулируя нажатия мышкой на странице.

Веб-мониторинг в Zabbix поддерживает и HTTP, и HTTPS. При выполнении веб-сценария, Zabbix сервер будет следовать перенаправлениям (смотрите опцию Следовать перенаправлениям ниже). Максимальное количество перенаправлений жестко задано в исходном коде и равняется 10 (используется cURL опция CURLOPT_MAXREDIRS). Все cookies запоминаются на протяжении выполнения одного сценария.

Смотрите также известные проблемы по веб-мониторингу при использовании HTTPS протокола.

Настройка сценария

Для настройки веб-сценария:

• Перейдите: Настройка → Узлы сети (или Шаблоны)
• Нажмите на Веб в строке с узлом сети/шаблоном
• Нажмите на Создать сценарий в верхнем правом углу (или на имени сценария для редактирования существующего сценария)
• Введите в диалоге параметры сценария

Вкладка Сценарий позволяет вам настроить общие параметры веб-сценария.

Все обязательные поля ввода отмечены красной звёздочкой.

Обратите внимание, что при редактировании существующего сценария, в диалоге будут доступны две дополнительные кнопки:

	Создание другого сценария на основе свойств существующего.
	Удаление у сценария данных истории и динамики изменений. Эта опция заставит сервер выполнить сценарий сразу после удаления данных.

Если поле HTTP прокси оставить пустым, можно воспользоваться другим способом указать HTTP прокси, для этого необходимо задать переменные окружения.

Для HTTP проверок — укажите переменную окружения http_proxy для пользователя Zabbix сервера. Например, //http_proxy=http:%%//%%proxy_ip:proxy_port//.

Для HTTPS проверок — укажите переменную окружения HTTPS_PROXY. Например, //HTTPS_PROXY=http:%%//%%proxy_ip:proxy_port//. Более подробную информацию можно получить, выполнив в shell команду # man curl.

Вкладка Шаги позволит вам настроить шаги веб-сценария. Чтобы добавить шаг веб-сценария, нажмите на Добавить в блоке Шаги.

Настройка шагов

Любые изменения в шагах веб-сценариев будут сохранены только, если сам сценарий был также сохранен.

Смотрите также пример из реальной жизни, о том как можно настроить шаги веб-мониторинга.

Настройка аутентификации

Вкладка Аутентификация позволяет вам настроить опции аутентификации сценария.

[1] Zabbix поддерживает файлы сертификатов и приватных ключей только в PEM формате. В случае, если у вас имеются данные сертификата и приватного ключа в формате файла PKCS #12 (обычно используется с расширением *.p12 или *.pfx), вы можете сгенерировать из них PEM файл, используя следующие команды:

Zabbix сервер подхватывает изменения в сертификатах без перезапуска.

Если сертификат клиента и приватный ключ находятся в одном файле, просто укажите его в поле «Файл SSL сертификата» и оставьте поле «Файл SSL ключа» пустым. Сертификат и ключ все еще должны быть в формате PEM. Очень просто объединить сертификат и ключ:

Просмотр

Для просмотра детальных данных добавленных веб-сценариев, перейдите в Мониторинг → Веб или в Последние данные. Нажмите на имя сценария для просмотра подробной статистики.

Обзор сценариев веб-мониторинга можно найти в Мониторинг → ПАНЕЛЬ.

Расширенный мониторинг

Иногда необходимо записать в журнал полученное содержимое HTML страницы. Это крайне полезно, если некоторые шаги веб-сценария завершаются с ошибкой. Для этой цели служит уровень отладки 5 (трассировка). Этот уровень можно указать в файлах конфигурации сервера и прокси или использовать опции выполнения административных функций ( -R log_level_increase=»http poller,N» , где N является номером процесса). При условии, что уровень отладки 4 уже задан, расширенный мониторинг можно запустить так, как демонстрируется в следующих примерах:

Если расширенный мониторинг не требуется, его можно истановить, используя -R log_level_decrease опцию.