sayat.pro
Обсудить задачу
· 7 мин чтения

Мониторинг сервисов: как узнавать о сбоях раньше клиентов

Мониторинг сервисов нужен, чтобы о падении сайта, почты или 1С вы узнавали из сообщения в мессенджере, а не от клиента или директора. Минимальный набор: внешняя проверка доступности по HTTP, контроль срока SSL-сертификата и домена, наблюдение за диском и памятью на сервере, оповещение в Telegram или на почту. Всё это настраивается за день, а стоит порой очень дёшево или вообще бесплатно.

Начинаем с вопроса «что должно работать всегда»

Прежде чем выбирать инструмент, составьте короткий список сервисов, остановка которых напрямую бьёт по деньгам или репутации. Не пытайтесь мониторить всё подряд, иначе получите шум, и на него перестанут реагировать.

Обычно в список попадают:

  • публичный сайт и форма заявки;
  • оплата на сайте и страница возврата после платежа;
  • 1С и обмен 1С с сайтом;
  • деловая почта;
  • сервер или виртуальная машина, где всё это живёт;
  • телефония или Telegram-бот, если через них идут обращения.

Для каждого пункта запишите, что считается сбоем. «Главная страница отдаёт 200» это не то же самое, что «заявка уходит менеджеру».

Три уровня проверок

Я делю проверки на три уровня, чтобы ничего не упустить.

Доступность снаружи

Внешний сервис периодически делает запрос к вашему адресу и сообщает, ответил ли он. Это ловит самый частый класс проблем: сайт недоступен, сертификат истёк, DNS не отвечает. Важно, чтобы проверка шла не из той же сети, где стоит сервер. Если сервер потерял интернет, внутренняя проверка этого не покажет.

Работоспособность сценария

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

Состояние ресурсов

Диск заполнился, память исчерпана, процессор в 100% уже час, сертификат закончится через неделю, резервное копирование последний раз выполнялось давно. Эти сигналы позволяют вмешаться до аварии. Многие инциденты, которые выглядят внезапными, на деле начинались с переполненного диска или истёкшего срока.

Чем мониторить: варианты по сложности

Выбор зависит от размера инфраструктуры и от того, кто будет всё это поддерживать.

  1. Сервисы внешней проверки доступности: настраиваются через веб-интерфейс, присылают оповещения на почту и в мессенджеры. Для сайта и нескольких адресов этого часто достаточно.
  2. Самостоятельно развёрнутый мониторинг (например, популярные системы с открытым кодом для сбора метрик и панелей): гибко, но нужно уметь его обслуживать.
  3. Простые скрипты по расписанию на сервере, отправляющие сообщение при отклонении: годится для малых задач и как временная мера.

Условия тарифов и возможности сервисов меняются, поэтому сравнивайте актуальные предложения самостоятельно. Я не буду называть цены и лимиты, чтобы не вводить в заблуждение.

Пример: простая проверка и уведомление в Telegram

Для небольших случаев удобен скрипт, который запускается раз в несколько минут и пишет в чат, если адрес не отвечает. Токен бота и идентификатор чата хранятся в переменных окружения, не в коде.

#!/bin/bash
URL="https://example.kz/health"
CODE=$(curl -s -o /dev/null -m 10 -w "%{http_code}" "$URL")

if [ "$CODE" != "200" ]; then
  curl -s "https://api.telegram.org/bot${TG_TOKEN}/sendMessage" \
    -d "chat_id=${TG_CHAT}" \
    --data-urlencode "text=Сервис недоступен: $URL, код $CODE"
fi

У такого скрипта есть слабость: если упадёт сам сервер, на котором он работает, никто ничего не узнает. Поэтому внешнюю проверку лучше иметь всегда, а скрипты оставить для внутренних метрик.

Как настроить оповещения, чтобы им верили

Мониторинг бесполезен, если оповещения игнорируют. Несколько правил, которые помогают.

  • Уведомлять нужно тех, кто может действовать, а не всех подряд. Определите дежурного или хотя бы порядок: кому писать первому, кому, если нет ответа.
  • Разделяйте срочное и информационное. Падение оплаты должно звучать иначе, чем «диск заполнен на 80%».
  • Включайте повторную проверку перед тревогой: два-три неудачных ответа подряд, а не одна ошибка сети.
  • Присылайте сообщение о восстановлении, чтобы было видно, что проблема ушла.
  • В тексте оповещения указывайте, что случилось, где и что проверить в первую очередь.

И обязательно проверяйте сам мониторинг: раз в квартал имитируйте сбой и убедитесь, что сообщение дошло до нужного человека.

Что мониторить именно на сайте с оплатой

Для интернет-магазина или сервиса с платежами я бы добавил проверки, которые не очевидны с первого взгляда.

  • Доступность адреса, на который платёжная система присылает уведомления (webhook). Если он недоступен, оплата прошла, а заказ не обновился.
  • Рост числа заказов в статусе «ожидает оплаты» дольше обычного.
  • Ошибки в журнале приложения, связанные с подписью запросов и обращением к платёжному API.
  • Срок действия сертификатов, в том числе клиентских, если провайдер их требует.

О том, как защитить такие точки и вести журнал, рассказано в статье про безопасность платежей на сайте, а о проблемах, из-за которых оплата проходит, а заказ нет, поможет понять материал про повторные уведомления платёжных систем.

Чего не хватает большинству небольших компаний

Чаще всего я вижу не отсутствие дорогих систем, а три простые дыры:

  1. Никто не следит за сроком домена и сертификата, и сайт «неожиданно» перестаёт открываться.
  2. Нет единого списка сервисов и ответственных, поэтому при сбое теряется время на поиски.
  3. Мониторинг есть, но оповещения приходят одному человеку, который в отпуске.

Закрыть всё это можно без больших инвестиций. Общую картину состояния инфраструктуры помогает собрать аудит ИТ-инфраструктуры по чек-листу.

Как реагировать на оповещение

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

После каждого серьёзного инцидента стоит потратить полчаса на разбор: что случилось, как заметили, сколько длился сбой, что изменить, чтобы не повторилось. Без поиска виноватых, только факты и действия. Через несколько таких разборов становится видно, какие проверки вы упускали, и мониторинг растёт вместе с реальными проблемами, а не за счёт абстрактных идей.

Мониторинг и безопасность

Данные мониторинга сами по себе чувствительны: адреса внутренних сервисов, версии программ, состояние систем. Панели и каналы оповещений нужно защищать так же, как рабочие системы: отдельные учётные записи, двухфакторная защита, закрытый доступ. Токены ботов для уведомлений не должны попадать в публичные репозитории и в общие чаты.

С какого минимального набора начать на этой неделе

Если времени мало, сделайте три вещи. Заведите внешнюю проверку главной страницы и страницы заявки с оповещением в Telegram. Добавьте напоминания о сроке домена и сертификата за месяц и за неделю до окончания. Выберите ответственного и запишите его контакты в общий документ вместе со списком сервисов. Это занимает несколько часов и закрывает самые частые причины неожиданных простоев. Остальное добавляйте по мере того, как будете видеть реальные проблемы.

Частые вопросы

Достаточно ли одного бесплатного сервиса проверки доступности?

Для небольшого сайта часто да, как первый шаг. Но он не замечает внутренних проблем: заполненный диск, остановленную службу, сломанный обмен. Для критичных систем нужен хотя бы минимальный контроль ресурсов сервера.

Как часто проверять доступность?

Чем критичнее сервис, тем чаще, но слишком частые проверки создают ложные срабатывания и лишнюю нагрузку. Для большинства бизнес-сайтов подходит интервал в несколько минут. Подбирайте по допустимому времени простоя.

Нужно ли мониторить резервные копии?

Да, но не только факт их создания. Важно периодически проверять, что копию можно восстановить. Это отдельная тема, и за неё обычно отвечает администратор инфраструктуры.

Что делать, если оповещений слишком много?

Пересмотрите пороги, добавьте повторную проверку и разделите уровни важности. Если сообщение не требует действия, оно, скорее всего, не должно быть тревогой.

Если хотите наладить наблюдение за сайтом, 1С и серверами, посмотрите страницу об ИТ-инфраструктуре и проектах или напишите мне в Telegram.

← Все заметкиОбсудить задачу