Как один дашборд следит за здоровьем сразу нескольких проектов

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

На практике это означает, что о поломке узнают не в момент, когда она произошла, а в момент, когда кто-то случайно зашёл именно в этот проект и заметил неладное. Между поломкой и обнаружением может пройти час, а может — несколько дней.

Что именно нужно видеть в одном месте

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

Работает ли фоновый процесс — жив ли нужный systemd-сервис или таймер, не упал ли он тихо в фоне. Свежие ли данные — не устарели ли метрики конкретного проекта (например, если метрики не обновлялись час при ожидаемом интервале в минуту, это тревожный сигнал сам по себе, даже если сервис формально “запущен”). И дошло ли уведомление — если проект должен был прислать алерт о проблеме, действительно ли он это сделал, а не просто “процесс жив, но молчит”.

Важный нюанс: сам факт, что где-то есть файл состояния уведомлений, ещё не доказывает, что сообщение реально дошло до получателя. Дашборд должен явно различать “процесс жив, доставка не проверялась” и “доставка подтверждена” — иначе ложное чувство защищённости хуже, чем полное отсутствие мониторинга.

Как это выглядит на практике

Дашборд получает по каждому проекту три сигнала: жив ли systemd-юнит, свежий ли metrics.json, и есть ли сигнал об уведомлениях — и на основе этого показывает карточку по каждому продукту: OK, WARNING или ERROR, с коротким пояснением, что именно не так и что делать дальше.

Реестр проектов при этом собирается не автоматическим сканированием всего диска, а осознанным списком: каждый новый продукт добавляется в реестр вручную, с указанием, какой systemd-префикс у него искать, где лежит его metrics.json и какой интервал обновления считается нормальным. Это чуть больше ручной работы при добавлении нового проекта, зато исключает ложные срабатывания на системные процессы с похожими именами.

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

Разница между WARNING и ERROR — не формальность

Часто в мониторинге весь смысл сводится к бинарному “зелёный/красный”, и это создаёт две проблемы сразу: либо пропускаешь то, что вот-вот сломается, либо тонешь в тревогах, к половине которых со временем начинаешь относиться как к шуму.

Практичнее разделять три состояния по степени срочности. WARNING — метрики устарели сильнее ожидаемого, но сам процесс формально жив: это повод заглянуть в течение дня, не бросая текущую задачу. ERROR — метрики не обновлялись критично долго, или явно указана конкретная причина, требующая вмешательства прямо сейчас: например, у одного из проектов может не быть актуального файла с инструкциями для агента, который должен эту автоматизацию поддерживать, — формально процесс не упал, но фактически никто не может быстро разобраться, что чинить. И отдельная категория N/A — для проектов, у которых просто нет мониторинга, встроенного в эту схему: важно явно показывать их отдельно, а не молча пропускать, иначе создаётся ложное ощущение, что весь портфель уже под наблюдением.

Именно поэтому у каждой карточки на дашборде есть не только статус, но и короткая формулировка причины и, где возможно, прямая подсказка, что делать: не просто “ERROR”, а “metrics.json не обновлялся N минут — нужен агент в такой-то директории, поправь”. Разница на первый взгляд небольшая, но именно она определяет, откроешь ли ты нужный проект сразу или начнёшь с раздражённого гадания.

Почему это не про красивые графики

Соблазн при создании внутреннего дашборда — сделать его красивым: графики, тренды, проценты аптайма за месяц. На практике для соло-основателя куда важнее другое: дашборд должен за пять секунд ответить на вопрос “куда смотреть прямо сейчас”, а не превращаться в отдельный проект, который тоже требует поддержки.

Поэтому практичный минимум — это статус по каждому продукту (OK/WARNING/ERROR), краткое пояснение причины и, если возможно, прямая рекомендация, что чинить. Не сводная аналитика, а рабочий инструмент на каждый день.

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