Website Health Monitor
Сервис на Go, который круглосуточно проверяет, что мои проекты живы и действительно работают, — с веб-интерфейсом, API и историей в PostgreSQL.
- Роль
- Постановка, архитектура, разработка на Go с Claude Code
- Период
- 2026.01 → …
- Статус
- В работе
- Стек
- Go · PostgreSQL · Docker · GitHub Actions · Grafana
Интерфейс
01 / 05Задача
Ссылки на пет-проекты уходят работодателям, и нельзя, чтобы по ссылке открылся упавший сервис. Проекты живут на VPS и бесплатных хостингах — они засыпают, отвечают с холодным стартом, а бесплатная база Supabase замирает после недели без запросов. Узнавать о падении от рекрутера — поздно.
Решение
Монитор по расписанию проверяет каждую цель — не только код ответа, но и ключевое слово на странице, — пишет результат в PostgreSQL и показывает сводку «всё зелёное / что-то упало» с аптаймом за сутки. Цели добавляются, меняются и отключаются в веб-интерфейсе или через API и подхватываются без перезапуска.
Первую версию я написал в январе как учебный проект на Go. В октябре вернулся к нему с новой целью — следить за проектами из этого портфолио — провёл аудит, нашёл 10 проблем и составил план из 7 этапов. Код пишется в Claude Code по этому плану с журналом решений; три этапа готовы.
Цели
- 01Узнавать о падении раньше работодателя
- 02Проверять, что проект работает, а не просто отвечает
- 03Добавлять и отключать проекты без пересборки
- 04Держать бесплатные сервисы активными
Функции
Ключевые требования
| ID | Требование | Приоритет |
|---|---|---|
| FR-01 | Цель «жива», если ответ пришёл с ожидаемым кодом (по умолчанию любой 2xx после редиректов) и, если задано, содержит ключевое слово. | Must |
| FR-02 | Добавление, изменение и отключение цели применяются без перезапуска сервиса. | Must |
| FR-03 | Одна цель никогда не проверяется параллельно сама с собой. | Must |
| FR-04 | Интервал не меньше 30 с, таймаут не больше 120 с и меньше интервала. | Must |
| FR-05 | Уведомления в Telegram о падении и восстановлении — без спама. | Should |
| NFR-01 | Остановка или деплой сервиса не порождают ложных падений. | Must |
| NFR-02 | Интерфейс и API — только с паролем; /healthz открыт для внешнего мониторинга. | Must |
| NFR-03 | Схема БД меняется только новыми миграциями; старые данные переносятся. | Must |
Сценарии
- 01Проверка не нашла ключевое слово: страница отдала 200, но это заглушка с ошибкой
- 02Результат с причиной записывается в health_checks
- 03В интерфейсе цель поднимается наверх списка красной, сводка — «1 упал»
- 04После этапа 5 — сообщение в Telegram и ещё одно при восстановлении
- 01Добавляет цель в форме: адрес, ключевое слово, таймаут на холодный старт
- 02Сервер проверяет настройки и сохраняет цель
- 03Планировщик сразу запускает проверки — без перезапуска
Ход работы
- 2026.01Первая версияПроверки по списку в коде, PostgreSQL, Docker, CI с тестами, вывод в Grafana.
- 2026.10Этап 0: аудит и планНовая цель — мониторинг портфолио; 10 найденных проблем и план из 7 этапов.
- 2026.10Этапы 1–2: ядро и цели в БДЛогика статусов, таймауты, миграции, pgx, корректная остановка; таблица целей, ключевое слово, заголовки, подхват на лету.
- 2026.10Этап 3: интерфейс и APIВеб-интерфейс без JS-фреймворков, JSON API, валидация, Basic Auth, защита от CSRF, /healthz.
- ДалееЭтапы 4–7Grafana как код, уведомления в Telegram, качество и CI, деплой на VPS с внешним мониторингом самого чекера.
Сложности
Результат
Готовы три этапа из семи — около 3 200 строк Go вместе с 34 тестами, включая интеграционные на PostgreSQL. Сервис проверяет цели, применяет изменения на лету и показывает сводку с аптаймом.
Дальше — дашборд Grafana из репозитория, уведомления в Telegram и деплой на VPS рядом с проектами, за которыми он следит.