Чтобы дистанционно следить за работоспособностью серверов, профессионалы используют специальные программные комплексы, вроде Zabbix или Icinga. Но, если вы начинающий владелец или администратор одного-двух веб-сайтов с небольшой нагрузкой, то нет нужды в больших системах мониторинга. Главный параметр — быстро ли сайт обслуживает пользователей. Поэтому следить за работой сайта можно с помощью простой программы, с любого компьютера, подключённого к интернету.



Давайте сейчас напишем такой скрипт — простейшего мониторинга доступности и скорости работы сайта. Эту программу можно запустить на домашнем компьютере, смартфоне и так далее. Программа имеет всего две функции:

• показывает на экране время, за которое ваш сайт выдаёт пользователям страницы,
• при медленных ответах сайта или ошибках программа записывает данные в файл («журнал», или лог-файл). Эти данные стоит время от времени проверять, чтобы исправлять проблемы, когда они только начинаются. Поэтому мы позаботимся о том, чтобы записывать эти логи в наглядной, удобной для быстрого просмотра форме.

Я буду описывать каждый шаг довольно подробно, чтобы даже новичок, лишь немного знакомый с написанием командных файлов (bat и cmd в системах DOS и Windows, sh в системах типа UNIX-а), разобрался без особых проблем и смог приспособить скрипт ко своим нуждам. Но прошу не использовать этот скрипт бездумно, ибо при неверном применении он может не давать должных результатов и, вдобавок, сожрать много трафика.

Опишу скрипт для операционной системы типа «Линукс» и его использование на домашнем компьютере. По тем же принципам, такое можно сделать и на других платформах. А тем, кто лишь присматривается к возможностям Линукса, может быть интересен ещё один пример, каким простым и мощным средством являются его скрипты.

1. Организация прежде всего

Заведём отдельную папку для этой программы и создадим в ней 3 файла. Например, у меня это папка /home/me/Progs/iNet/monitor (здесь me — имя моего пользователя, Progs/iNet — моя папка для программ, связанных с интернетом, и monitor — название этой программы, от слова мониторить, то есть, наблюдать. Поскольку я единственный пользователь этого компьютера, то держу такие файлы среди личных папок (/home), в отдельном разделе диска, что позволяет сохранять их при переустановке системы). В этой папке будут файлы:

• README.txt — здесь описание (на случай склероза): что за программа, справочная информация к ней и т.д.
• mon.sh — здесь будет программа, опрашивающая сайт.
• server.log — сюда она будет записывать показатели состояния сайта. В нашем случае это просто дата, время и длительность отклика сайта (плюс дополнительная информация, если на наш запрос сервер отвечает ошибкой).

(Для удобства правки и, если что, восстановления файлов, можно включить эту папку в систему контроля версий Git; здесь я не буду этого описывать).

2. Настойчиво и расслабленно

Файл mon.sh мы будем запускать с регулярным небольшим интервалом, например, 60 секунд. Я использовал для этого стандартное средство, предоставляемое операционной системой (точнее, средой рабочего стола).

Моя среда Рабочего стола — Xfce. Это один из самых популярных вариантов для Линукса. Xfce нравится мне тем, что позволяет практически полностью настраивать всё окружение — именно так, как тебе удобно. При этом Xfce несколько компактнее и быстрее двух других известных систем — Gnome и KDE. (Интересны и другие варианты — например, среда LXDE ещё быстрее и легче, чем Xfce, но пока не так богата по возможностям).

Нужное нам средство, в случае Xfce — это плагин для рабочей панели «Монитор общего назначения» (Generic Monitor). Обычно он уже установлен, но, если нет, Установщик легко найдёт его: «Genmon» (описание: xfce4-genmon-plugin). Это плагин, который можно добавить на панель и задать ему в настройках: (1) выполняемую команду и (2) периодичность её выполнения в секундах. В моём случае, команда:

/home/me/Progs/iNet/monitor/mon.sh

(или, что то же самое, ~/Progs/iNet/monitor/mon.sh).

3. Когда программы ещё нет, ошибки уже есть

Если вы проделали сейчас все эти шаги — создали файлы и запустили плагин на панели — то видите там результат запуска нашей программы (сообщение об ошибке: файл mon.sh не является программой). Тогда, чтобы сделать файл исполняемым, зайдём в нашу папку и поставим ему разрешение на запуск —

• или файловым менеджером: Свойства — Разрешения — Разрешить выполняться как программа (Properties — Permissions — Allow this file to run as a program);
• или командой с терминала: chmod 755 mon.sh

И в самом файле напишем такие первые строки:

#!/bin/bash
# Monitor server responses (run this every 60 seconds):
#
info=$(curl -I -o /dev/stdout -w '%{time_total}эяю' --url https://example.ru/ -m 9 -s)
errr=$(echo $?)

Вместо «example.ru» подставьте название вашего сайта, за состоянием которого вы будете наблюдать. И, если он работает по http, поставьте http вместо https. Строка #!/bin/bash означает, что это скрипт для запуска программой Баш (bash — наверное, самой распространённой для выполнения скриптов на Линуксе). Для работы посредством другого командного интерпретатора его указывают вместо Баша. Остальные строки с диезом в начале — комментарии. Первая собственно строка кода — info=$() и в этих скобках команда curl с параметрами. Такая конструкция — нечто=$(что-то) — означает «выполнить команду в скобках и присвоить результат переменной слева». В данном случае, я назвал переменную «info». Эта команда в скобках — curl (на жаргоне именуемая некоторыми «Курл») — посылает запрос в сети по заданному адресу и возвращает нам ответ сервера. (Мой знакомый сказал, объясняя: «Как журавлик курлыкает — и получает ответ от какого-то другого журавля в небе»). Рассмотрим параметры:

curl -I -o /dev/stdout -w '%{time_total}эяю' --url https://example.ru/ -m 9 -s

-I значит, что мы запрашиваем не всю страницу, а только её «заголовки HTTP». Нам не нужен каждый раз текст страницы целиком, чтобы убедиться в работоспособности сайта. Поскольку мы будем проверять сайт часто, важно сделать размер передаваемых данных как можно меньше. Это экономит и трафик, и электричество, и нагрузку на сервер — и на живую природу.

Кстати, обратите внимание, сколько у вас запасного трафика (не используется за месяц) на хостинге. Ниже увидите, какой объём данных передаётся и сможете посчитать, хватит ли вам запасов; если что, период проверки сайта можно увеличить до 5, 10, или даже 30-60 минут. Хотя в этом случае картина будет не такой полной — и мелкие перебои могут остаться незамеченными; но, в целом, при мониторинге сайта важнее обнаруживать длительные проблемы, чем однократные перебои. Также, какой трафик вы можете себе позволить на вызывающем компьютере? В моём случае — настольный ПК с безлимитным трафиком — это не так важно; но для мобильного устройства или тарифа с лимитами стоит посчитать и, возможно, увеличить интервалы проверки.

4. Шаг следует за шагом, кроме первого шага

Поехали дальше: -o /dev/stdout значит «ответ, полученный Курлом от сервера, направить в такой-то файл». И в данном случае это не файл на диске, а /dev/stdout — Стандартное устройство вывода. Обычно «Стандартное устройство вывода» — это наш экран, где мы можем видеть итоги работы программы. Но в скрипте мы часто направляем этот «стандартный вывод» на дальнейшую обработку (сейчас — сохраняем в переменную info). И дальше мы будем, чаще всего, либо направлять итоги команд в переменные, либо передавать их следующим командам по цепочке. Для создания цепочек из команд служит оператор pipe («Труба»), изображаемый как вертикальная черта ("|").

-w '%{time_total}эяю': здесь -w значит «сформатировать и выдать на стандартное устройство вывода такую-то дополнительную информацию». А конкретно, нас интересует time_total — сколько всего времени заняла передача запрос-ответа между нами и сервером. Вы, наверное, знаете, что есть более простая команда, ping («Пинг»), чтобы быстро запросить сервер и получить от него ответ, «понг». Но Пинг только проверяет, что сервер хостинга жив, и сигнал туда-обратно идёт столько-то времени. Это показывает предельную скорость доступа, но ещё ничего не говорит нам о том, как быстро сайт выдаёт реальное содержимое. Пинг может работать быстро, и при этом сайт может тормозить или вообще не работать — из-за высокой нагрузки или каких-то внутренних проблем. Поэтому мы используем именно Курла и получаем действительное время выдачи сервером нашего содержимого.

(И по этому параметру можно судить, достаточно ли сервер производительно работает для ваших задач, удобно ли пользователям его типичное время отклика. Не возникает ли проблем — например, мои сайты на многих хостингах с течением времени замедлялись, и приходилось искать другой хостинг).

Вы заметили странные буквочки «эяю» после {time_total}? Я добавил их как уникальную метку, которой наверняка не будет в отправленных нам с сервера заголовках (хотя делать предположения, что будет и чего не будет у пользователей ваших программ — дурной тон и дорога в бездну. Не делайте так!.. Или, когда делаете, пусть вам хотя бы будет стыдно). По этой метке (надеюсь) мы потом сможем легко вытащить нужный нам кусочек информации из целой кучи строк в переменной info. Итак, curl -w '%{time_total}эяю' (при правильных остальных параметрах) выдаст нам что-то вроде:

0.215238эяю

Это количество секунд, которое заняло обращение к сайту, плюс наша метка. (Кроме этого параметра, в переменной info нас будет интересовать, главным образом, «Status code» — код состояния, или, по-простому, код ответа сервера. Обычно, когда сервер выдаёт запрошенный файл, код «200». Когда страница не найдена, это знаменитое 404. Когда на сервере ошибки, это, чаще всего, 500 с чем-то).

5. Творческий подход — отец самопроверки

Остальные параметры у нашего curl-а таковы:

--url https://example.ru/ -m 9 -s

что значит: запросить такой-то адрес; максимальное время ожидания ответа 9 секунд (можно ставить меньше, потому что редкий пользователь будет ждать ответа от сайта так долго, он быстрее сочтёт сайт не работающим). И "-s" означает silent, то есть, curl не будет сообщать нам лишних подробностей.

Кстати, на панели рабочего стола обычно места немного, поэтому для отладки скрипта лучше запускать его с терминала (в его папке, командой ./mon.sh). А у нашего плагина панели поставим пока большую паузу между запусками команды — скажем, 3600 секунд.

Для отладки мы можем запустить этот curl без обрамляющих скобочек и посмотреть, что он выдаст. (Из этого и рассчитать расход трафика). Мы увидим, в основном, набор заголовков HTTP, типа:

HTTP/1.1 302 Found
Server: QRATOR
Date: Sun, 11 Feb 2019 08:06:57 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=15
X-Powered-By: PHP/7.2.14-1+ubuntu16.04.1+deb.sury.org+1
Location: https://habr.com/ru/
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Cache-Status: HIT

0.033113эяю

Первой строкой здесь мы видим «HTTP/1.1 302 Found» — что значит: используется протокол передачи данных «HTTP/1.1», код ответа сервера — «302 Found». При запросе другой страницы это может быть код «301 Moved Permanently» и т.п. В дальнейшем примере, нормальный ответ моего сервера — «HTTP/2 200». Если же ваш сервер в норме отвечает по-другому, подставьте этот его ответ вместо «HTTP/2 200» в этом скрипте.

Последней строкой, как мы видим, Курл выдаёт, за сколько секунд мы получили ответ сервера, с нашей приписанной меткой.

Интересно: мы можем так настроить сайт, чтобы он сообщал по этим нашим запросам (и только по ним!) дополнительную информацию о своём состоянии — например, в «самодельном» заголовке HTTP. Скажем, какова нагрузка на процессоры сайта, сколько у него свободной памяти и места на диске, быстро ли работает база данных. (Конечно, для этого сайт должен быть динамическим, то есть, запросы должны обрабатываться программой — на PHP, Node.JS или т.п. Ещё вариант — использовать на сервере специальные программное обеспечение). Но, возможно, эти подробности нам пока не очень нужны. Цель этого скрипта — просто регулярно следить за общей работоспособностью сайта. Во случае проблем — мы уже будем разбираться с диагностикой другими средствами. Поэтому сейчас мы пишем самый простой скрипт, который будет работать для любого сайта, даже статического, и без дополнительных настроек на сервере. В дальнейшем, при желании, можно будет расширить возможности скрипта; а пока сделаем основу.

Строка errr=$(echo $?) означает: записать в переменную errr результат команды «echo $?». Команда echo означает вывести некий текст на Стандартное устройство вывода (stdout), а символы "$?" — это текущий код ошибки (оставшийся от выполнения предыдущей команды). Так что, если наш curl вдруг не сможет достучаться до сервера, то выдаст ненулевой код ошибки, и мы узнаем об этом, проверив переменную errr.

6. Целесообразность

Здесь я хочу сделать небольшое отступление от технических материй, чтобы читать текст было интереснее. (Если не согласны, пропустите три абзаца). Скажу так, что всякая человеческая деятельность по-своему целесообразна. Даже когда человек намеренно бьётся лбом об стену (или об пол… об клавиатуру...), в этом есть своя целесообразность. Например, он даёт выход эмоциональной энергии — может, не «лучшим» способом, но уж как умеет. (Да и само понятие «лучший» бессмысленно с точки зрения этого мгновения в этом месте — потому что лучшее и худшее возможно лишь по сравнению с чем-то ещё).

Я сейчас пишу этот текст, вместо, казалось бы, более важных для меня дел — почему? Во-первых, чтобы подвести итоги, пересмотреть и внутренне разложить по полочкам то, чему за эти два дня научился в написании скриптов… Вынести из оперативной памяти и уложить на хранение. Во-вторых, я таким способом немножко отдыхаю… В-третьих, надеюсь, что это разжёванное объяснение пригодится кому-то ещё (и мне самому, возможно, когда-нибудь). Как, не важно, лучшая ли, но внятная напоминалка по теме скриптов и запросов на сервер.

Кто-то, может, поправит меня в чём-то, и итог станет ещё лучше. Кто-то получит кусочек полезной информации. Целесообразно ли это? Пожалуй… это то, что я могу сейчас сделать и делаю. Завтра, может быть, я просплюсь и проведу переоценку нынешних действий… но и эта переоценка даст что-то небесполезное для дальнейшей жизни.

Итак, по выполнении запроса, у нас два кусочка данных:

• основной блок информации от сервера (если, конечно, ответ сервера пришёл), мы записали его в переменную info;
• код ошибки команды curl (0, если без ошибок) — записан в переменную errr.

Именно потому, что понадобятся оба итога — и info, и код ошибки — я и записал их в переменные, а не сразу передал итоги Курла другим командам через Трубу. Но теперь в этом скрипте пора полазить и по трубам:

code=$(echo "$info" | grep HTTP | grep -v 'HTTP/2 200')
date=$(echo "$info" | grep -i 'date:')
dlay=$(echo "$info" | grep эяю | sed -e 's/эяю//')

В каждой из этих строк мы записываем очередную переменную — сохраняем итоги выполнения команд. И в каждом случае это не одна команда, а цепочка; первое звено везде одинаково: echo "$info" — выдаёт в поток Стандартного устройства вывода (stdout) тот самый блок информации, что мы сохранили, получив от curl-а. Дальше по трубе этот поток передаётся команде grep («Греп»). Греп выбирает изо всех строк только те, в которых находит соответствие шаблону. (Параметр -i означает «не учитывать регистр»). Как видите, в первом случае мы выбираем строку, содержащую «HTTP». Эта строка, вытащенная из кучи остальных, передаётся по трубе дальше, команде grep -v 'HTTP/2 200'. Здесь параметр -v — противоположность параметру -e, он отфильтровывает строки, где найден такой-то шаблон. Итого, в переменной code окажется строка с кодом ответа сервера (типа «HTTP/1.1 302 Found»), но только если это не 'HTTP/2 200'. Так я отфильтровываю строки, которые мой сайт посылает в нормальном случае, и сохраняю лишь «аномальные» ответы. (Если у вас нормальный ответ сервера иной, подставьте его туда).

Аналогично, в переменную date мы записываем строку, в которой сервер выдал его текущие дату и время. Это что-то вроде "date: Sun, 11 Feb 2019 08:06:57 GMT" (как правило, в часовом поясе GMT, он же UTC). Нам надо записывать дату (но лишь один раз в сутки!) в наш лог-файл («журнал состояния сервера») — server.log. А заодно выведем это время на экран. Можно было бы записать в лог дату-время и со своего компьютера, но для удобства возьмём эти, раз уж всё равно сервер их прислал.

Похоже и с нашей третьей переменной, dlay (от английского слова дилей — задержка). Выбираем по нашей нежной метке «эяю» строку, в которой сохранили длительность ожиданияния ответа от сервера. Удаляем эту метку, уже не нужную, с помощью команды sed — и сохраняем результат.

Теперь, если мы для проверки напечатаем эти переменные — например, добавив в наш скрипт строки:

printf 'errr: %s\n' "$errr"
printf 'code: %s\n' "$code"
printf '%s\n' "$date"
printf 'dlay: %s\n' "$dlay"

должно получиться что-то вроде:

errr: 0
code: 
date: Mon, 11 Feb 2019 12:46:18 GMT
dlay: 0.236549

Итого: код ошибки curl-а — ноль (значит, отработал нормально). Код состояния сервера — не записан (так как был нормальным). Дата и время. Длительность ответа. Осталось правильно вывести, что нужно, на экран и, если нужно, записать в файл.

Это самое интересное: что, при каких условиях и как записывать?

7. Хитрые выводы

Чтобы не утомлять вас больше подробностями, расскажу кратко (а хороших справочников по всем этим командам в интернете достаточно). Кстати, краткость — одна из главных целей, которых мы будем добиваться при записи в этот лог. Тогда он будет и удобен для просмотра, и никогда не займёт много места на диске (в отличие от иных логов, что растут мегабайтами в день).

Первое: позаботимся о том, чтобы записывать дату в лог лишь по одному разу, а не в каждой строке. Для этого выделим из нашей переменной date по отдельности текущую дату (curr) и время (time):

curr=$(echo "$date" | sed -e 's/\(20[0-9][0-9]\).*$/\1/')
time=$(echo "$date" | sed -e 's/^.*\ \([0-9][0-9]:.*\)\ GMT\r$/\1/')

А также считаем из лог-файла строки с датами и возьмём последнюю дату (prev):

prev=$(cat /home/me/Progs/iNet/monitor/site.log | grep -e 'date:' | tail -1)

Если наша текущая дата (curr) не равна предыдущей (из файла, prev) — то наступил новый день (или, скажем, файл логов был пуст); тогда пишем новую дату в файл:

if [[ $curr != $prev ]]; then
  printf '%s\n' "$curr" >>/home/me/Progs/iNet/monitor/site.log
  printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log

… и заодно записываем текущую информацию: время, задержка получения ответа с сайта, код ответа сайта (если не обычный):

  printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log

Это поможет ориентироваться: такой-то день начался с такой-то скорости работы сайта. В остальных случаях давайте не загромождать файл лишними записями. Безусловно, запишем, если получили необычный код состояния сервера:

elif [[ -n $code ]]; then
  printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log

А также пишем, если время ответа сервера больше обычного. У меня сайт отвечал обычно за 0.23-0.25 секунд, поэтому я фиксирую ответы, которые заняли дольше 0.3 секунд:

elif (( $(echo "$dlay > 0.3" | bc -l) )); then
  printf '%s %s\n' "$time" "$dlay" >>/home/me/Progs/iNet/monitor/site.log

Наконец, раз в час я просто записываю время, полученное от сервера — как знак, что он жив, и заодно как своеобразную разметку файла:

else
  echo "$time" | grep -e :00: | cat >>/home/me/Progs/iNet/monitor/site.log
fi

Получаем такое содержание файла, где разметка ежечасными записями помогает визуально, не вчитываясь, видеть, когда нагрузка выше или ниже (больше число записей в час):

19:42:28 0.461214
19:53:29 0.443956
20:00:29
20:09:30 2.156462
20:10:29 0.358294
20:45:29 0.313378
20:51:30 0.563886
20:54:30 0.307219
21:00:30 0.722343
21:01:30 0.310284
21:09:30 0.379662
21:10:31 1.305779
21:12:35 5.799455
21:23:31 1.054537
21:24:31 1.230391
21:40:31 0.461266
21:42:37 7.140093
22:00:31
22:12:37 5.724768
22:14:31 0.303500
22:42:37 5.735173
23:00:32
23:10:32 0.318207
date: Mon, 11 Feb 2019
00:00:34 0.235298
00:01:33 0.315093
01:00:34
01:37:41 5.741847
02:00:36
02:48:37 0.343234
02:56:37 0.647698
02:57:38 1.670538
02:58:39 2.327980
02:59:37 0.663547
03:00:37
03:40:38 0.331613
04:00:38
04:11:38 0.217022
04:50:39 0.313566
04:55:45 5.719911
05:00:39

И, наконец, выводим информацию на экран. А также, если curl сработал с ошибкой, выводим и записываем сообщение об этом (и заодно запускаем Пинг и логируем — проверить, жив ли сервер вообще):

printf '%s\n%s\n%s' "$time" "$dlay" "$code"
if (( $errr != 0 )); then
  date >>/home/me/Progs/iNet/monitor/site.log
  date
  printf 'CURL Request failed. Error: %s\n' "$errr" >>/home/me/Progs/iNet/monitor/site.log
  printf 'CURL Request failed. Error: %s\n' "$errr"
  pung=$(ping -c 1 178.248.237.68)
  printf 'Ping: %s\n----\n' "$pung" >>/home/me/Progs/iNet/monitor/site.log
  printf 'Ping: %s\n' "$pung"
fi

Замените адрес IP во строке ping-а на реальный адрес IP вашего сайта.

8. Послесловие

Итог трудов:



Слева на панельке видно время в UTC и текущая отзывчивость сайта. Справа — лог: видно слёту, даже при беглом прокручивании, в какие часы нагрузка была больше или меньше. Можно заметить и аномально медленные ответы (пики; хотя пока непонятно, откуда они берутся).

Вот и всё. Скрипт получился простой, дубовый, и его можно совершенствовать: работать над оптимизацией, переносимостью, улучшением оповещений и отображений, с учётом прокси и кеша…

Но уже в этом виде программы она, наверное, может дать представление о состоянии вашего сайта. И пусть это будет сайт мудро целесообразный, полезный для людей и всех существ!



PS. По итогам обсуждения (на 12.02.2019):

Как я и надеялся, знатоки написали много интересных комментариев.

Обдумав, могу ответить на вопрос rsashka, в чём преимущество этого скрипта.

Другие средства, вроде NetData (спасибо tchspprt за наводку!), дают большой массив данных, которые не будут долго храниться. NetData хорошее средство, когда ты каждый день работаешь, обслуживаешь сайты профессионально. Хорошо подходит для диагностики текущих проблем.

А скрипт вроде моего — это чтобы присматривать вполглаза, занимаясь другими делами. Скрипт не требует особого изучения и настроек. Это неплохо для непрофессионалов. А его логи занимают так мало места, что их можно вообще не стирать. Они могут накапливаться годами, и лет через N+1 можно будет посмотреть: «Ого, в 2019 году у меня время отклика было в полтора раза ниже!..»

То есть, своя ниша у такого решения есть — в основном, для не занимающихся сисадминством постоянно. (Как говорит tchspprt: «Примерно как соседского кота покормить на время отпуска»).

andreymal посоветовал интересный способ учитывать и потом просматривать нагрузку сайта, без дополнительных средств, просто через логи доступа на сайте. И можно по ним строить красивые графики. Я, наверное, попробую этот вариант и выложу на Гитхабе, что получилось.

unnforgiven посоветовал ещё интересное решение — наверное, несложное (prometheus, blackbox и alermanager установить через docker composer). На моём простом, дешёвом VPS не хватит для этого памяти; и Linux со старым ядром — Докер не запустится. Но за вариант спасибо!

Ещё совет tchspprt: Graphite + Prometheus + Grafana. Или снабдить скрипт красивой графикой (gnuplot или rrdtool).

Mcalexvrn советует простое средство: uptimerobot. Спасибо!

Благодарю всех за такой массив информации! Пусть это пригодится людям…