Простой Мониторинг Web-Сервисов И Status Page

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

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

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

Самый простой способ понять, что твой web-сервис доступен

Один из самых простых способов (в случае с web-сервисом, который доступен по http) - это использовать любой сервис, который “пингует” ваш сервис извне с определенным интервалом.

Очевидные плюсы данного подхода:

  • не нужно ничего менять в коде;
  • настраивается за минуты;
  • есть сотни компаний, которые предоставляют такие услуги за небольшое вознаграждение;
  • можно настроить “пинг” из разных локаций, если для вас это важно;
  • можно настроить уведомления для оперативного реагирования.

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

В комплекте с самим функционалом “пингования”, как правило, идет Status page, которая показывает, что сейчас происходит с вашим сервисом. Это очень клиентоориентированный подход, когда вы можете честно показать, когда ваш сервис был доступен.

Какие варианты есть?

В последнее время я делю сервисы на 2 категории:

  • SaaS;
  • Open source (self-hosted).

В случае с SaaS вообще не нужно морочиться с инфраструктурой, достаточно выбрать подходящий по вашим критериям сервис, тариф (бесплатных тоже много) и вперед.

В случае с Open-Source можно получить не менее качественный продукт, но уже полностью под своим контролем. Тут важная поправка, что утилита должна быть установлена на другой сервер/кластер, нежели чем проверяемый продукт. Ввиду того, что я много экспериментирую - это мой вариант, так как за железо уже уплачено.

Я приведу по 3 примера таких сервисов. На деле их множество и они легко гугляться.

SaaS - облачные варианты:

  • Better Uptime;
  • UptimeRobot;
  • StatusCake.

Open source (self-hosted):

  • Upptime;
  • Uptime Kuma;
  • Zabbix.

Остановлюсь чуть подробнее на self-hosted.

Upptime

Upptime

Этот сервис можно развернуть на мощностях Github абсолютно бесплатно. Раз в 5 минут будет создаваться Github-Action, который будет проверять доступность ваших сервисов.

Uptime Kuma

Uptime Kuma

Uptime Kuma написан на JS и вы можете его развернуть на своем VPS.

Я для себя выбрал именно его, так как:

  • можно пинговать сервисы каждые 30 секунд (можно и чаще);
  • можно настроить уведомление (в т.ч. и в telegram) о недоступности сервиса;
  • можно создавать отдельные Status page (вот пример - Econumo status page)
  • очень удобная и простая админка.

Вот вам docker-compose.yml

version: '3.3'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    volumes:
      - ./uptime-kuma-data:/app/data
    ports:
      - 8080:3001  # <Host Port>:<Container Port>
    restart: always

Zabbix

Zabbiz

Тяжеловес среди моей подборки. По Заббиксу есть тысячи страниц документации на любом языке. Эта утилита очень активно используется среди сисадминов unix-систем. Zabbix позволяет мониторить все, что угодно, но, к сожалению, требует глубокой конфигурации. Можно использовать как облачную версию, так и on-premise.

В заключение

Уважаемые разработчики, пожалуйста, когда разрабатываете новый продукт, подумайте сразу о том, как он будет мониторится. Начать отслеживать Uptime своего сервиса можно и нужно уже прямо сейчас.

open-sourcemanualmonitoringtools