jtprogru/sitemon

Простая система мониторинга доступности веб-сервисов работающих по HTTP(S)

sitemon

Мониторинг сайтов с уведомлением

Основано на статье с Habr:

• Мониторинг демон на Asyncio + Dependency Injector — руководство по применению dependency injection

Каналы уведомлений:

• Telegram
• Email
• etc

Пример конфигурационного файла config.yml:

log:
  level: "DEBUG"
  format: "[%(asctime)s] [%(levelname)s] [%(name)s]: %(message)s"

sentry:
  dsn: "https://[email protected]/5383803"

telegram:
  token: "123456789:qwertyuiopasdfghjkzxcvbnm"
  chat: "-12123123123"

monitors:
  jtprog:
    method: "GET"
    url: "https://jtprog.ru"
    timeout: 15
    check_every: 60

  httpbin:
    method: "GET"
    url: "https://httpbin.org/get"
    timeout: 5
    check_every: 90

Задачи

Вводные: В качестве вводных данных имеется исключительно вышеупомянутый конфиг.

Необходимо реализовать:

• автоматическое перечитываение конфига (по таймеру, по триггеру ФС, по команде боту в телеграм, any way);
• автоматический парсинг объектов мониторинга – секция monitors – объекты должны именоваться так же как в конфиге, иметь те же поля и настройки;
• etc

sitemon's Issues

Цели

Общие цели (development)

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

• #2
• #3
• #9
• #10
• Добавление нового сайта сводится к добавлению новой записи в конфиг
• Обновление конфига происходит по SIGUSR1
• Graceful shutdown

Общие цели (operations)

Второстепенные задачи непосредственно для запуска приложения:

• Докеризовать приложение
• Multistage build для уменьшения целевого образа
• #5
• #6
• #7

Схема с описанием внутренних структур, а так же процессы их взаимодействия

Нарисовать схему в draw.io и прикрепить в общую документацию в WIKI

Добавить домашний сервер с k8s

Добавить self-hosted runner

Документация

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

Документацию разработчика можно автоматически создавать на базе комментариев в коде. Комментированию подлежат:

• Структуры данных с описанием полей;
• Интерфейсы, описывающие функционал структур;
• Все функции;

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

• Описание всех переменных окружения;
• Пошаговое описание (с указанием всех команд) процесса локального запуска проекта в режиме разработки;
• Весь внешний функционал, с которым конечный пользователь может взаимодействовать;
• Контакты разработчика(ов) на которые можно выслать фидбэк (оценить качество работы, предложить недостающий функционал или улучшение текущего), сообщить об ошибке (ссылка на Issues репозитория как один из вариантов контактов);
• Пошаговое описание (с указанием всех команд) процесса формирования bug-report'a;

Сайт считается доступным, если после цепочки редиректов (максимальное количество редиректов должно быть ограничено 10 (десятью), но предусмотреть возможность расширения через конфиг) отдает НЕ двухсотый http код

Все настройки только в конфиге

Реализовать функционал считывания YAML-файла с конфигурацией. Пример файла указан в README.md.

Основные составляющие конфигурационного файла

Настройка уровня логирования и формата логов:

log:
  level: "DEBUG"
  format: "[%(asctime)s] [%(levelname)s] [%(name)s]: %(message)s"

Интеграция в Sentry:

sentry:
  dsn: "https://[email protected]/5383803"

Интеграция с Telegram:

telegram:
  token: "123456789:qwertyuiopasdfghjkzxcvbnm"
  chat: "-12123123123"

Список объектов для мониторинга:

monitors:
  jtprog:
    method: "GET"
    url: "https://jtprog.ru"
    timeout: 15
    check_every: 60

  httpbin:
    method: "GET"
    url: "https://httpbin.org/get"
    timeout: 5
    check_every: 90

На что стоит обращать внимание

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

Среди переменных окружения стоит хранить следующие данные/значения:

• SITEMON_LOGLEVEL – переменная окружения определяет уровень логирования;
• SITEMON_SENTRYDSN – переменная окружения определяет DSN для сервиса Sentry (куда будут отправляться все ошибки приложения);
• SITEMON_TGTOKEN – переменная окружения определяет токен для Telegram-бота;
• SITEMON_TGCHAT – переменная окружения определяет ID Telegram-чата куда будут отправляться сообщения;

Все переменные окружения должны начинаться с префикса SITEMON_.

Мониторинг сайтов из списка конфигов

Реализовать чекер сайтов:

• На входе url, timeout, на выходе error
• Покрыть тестами
• Используем только стандартную библиотеку

Пример входных данных:

  jtprog:  # Имя объекта в рамках конфига, должно отображаться в алертах
    method: "GET"  # HTTP метод для осуществления запроса
    url: "https://jtprog.ru"  # URL начинающийся со схемы
    timeout: 15  # Таймаут на получение ответа от сервера
    check_every: 60  # Раз в сколько секунд выполнять проверку данного ресурса

URL для проверки может быть задан в нескольких форматах:

• url: "https://jtprog.ru" – с указанием схемы (указана схема и порт для подключения берется дефолтный для данной схемы);
• url: "http://jtprog.ru" – с указанием схемы (указана схема и порт для подключения берется дефолтный для данной схемы);
• url: "https://jtprog.ru:8443" – с указанием схемы и порта;
• url: "http://jtprog.ru:8080" – с указанием схемы и порта;
• url: "jtprog.ru" – без указания схемы и порта (должны использоваться дефолтные схема HTTP и порт 80);

Сайт считается доступным, если:

• После цепочки редиректов отдает НЕ http код 200 OK
• Максимальное количество редиректов должно быть ограничено 10 (десятью), но предусмотреть возможность расширения через конфиг

Расширенные проверки

Дополнительные типы проверок:

• WHOIS – проверка "протухания" домена
• DNS – проверка наличия DNS записи
• WebSocket – проверка доступности веб-сокетов (including Socket.io)
• HTTP/S – проверка наличия строки на загружаемой странице (Content Matching)
• HTTP/S Advanced – POST-запросы с подготовленными данными, JSON/XML, изменением заголовков запроса, etc
• SSL Certificates – валидация SSL-сертификатов (валиден или нет, срок жизни)
• SSH – проверка доступности SSH с валидацией ответа
• FTP with file availability – проверка доступности FTP с проверкой доступности файлов
• PING – отправка ICMP запросов (стандартный PING) на указанный хост с получением ответов (из коробки Golang не умеет слать ICMP запросы)
• SMTP – проверка доступности SMTP сервиса
• POP3 – проверка доступности POP3 сервиса
• IMAP4 – проверка доступности IMAP4 сервиса
• NTP – мониторинг NTP

Алерты о каждом этапе в Telegram chat/channel

Сделать Алерты о каждом этапе работы GHA в Telegram (есть у меня канал/чат для такого мусора)

Добавить базовые типы проверок

Базовые типы проверок для запуска MVP:

• TCP Port Connect – проверка доступности TCP-порта;
• HTTP/S – мониторинг сайтов описанный в #2

Прикрутить GitHub Actions для этапов:

GHA должны выполнять:

• Запуск линтеров на каждый commit
• Сборка, если линтеры отработали без ошибок
• Тестирование готовой сборки
• Создание draft release
• Деплой в K8s если опубликованного релиза

Очередь проверок

У всех проверок должны задаваться интервалы, через которые стоит выполнять данную проверку. Это должно говорить о том, что может случиться шторм запросов (10k проверок раз в 5 минут – пять минут тишины, а потом начинается шквал запросов). Следовательно стоит предусмотреть взаимодействие с очередями задач.

Уведомления в Telegram

Реализовать модуль уведомления в Telegram

• На входе - текст уведомления, адресат, на выходе - error
• Покрыть тестами