Всем привет! Меня, как и многих здесь, в какой-то момент достало. Достало логиниться по SSH, чтобы проверить htop. Достало запускать Termius на телефоне, чтобы сделать sudo reboot зависшему инстансу. Достало ставить тяжелые веб-панели, которые жрут ресурсы и открывают лишний порт, только ради того, чтобы посмотреть загрузку диска.
Я админю VPS. Мне нужен был инструмент, который:
Мгновенно даёт сводку по системе.
Работает легковесно, не отъедая ресурсы.
Безопасен (никаких "запусти_от_рута_в_один_пайп").
Надёжен, как швейцарские часы (и не спамит алертами).
Умеет в администрирование этих кастомных приложений.
Я перепробовал готовые решения. Веб-панели — оверинжиниринг и дыра в безопасности. Готовые боты — либо заброшены, либо требуют root-доступ по дефолту, либо умеют только uptime.
Поэтому я сел и написал своего. Встречайте — tgbotvpscp.

Чем он лучше аналогов? Фокус на безопасности и надёжности
Я сразу решил, что не буду делать "ещё одного" бота. Я делал инструмент для себя, а я параноик в плане безопасности и ненавижу "глючные" скрипты.
1. Установка: Secure vs Root
Первое, что я продумал, — это установка. Мой deploy.sh — это не просто git pull. Это полноценный интерактивный установщик.
Он сразу предлагает выбор:
Secure(Рекомендуемый): Скрипт сам создаёт отдельного системного пользователяtgbot, выдаёт ему права только на нужные директории (/opt/tg-bot), настраиваетsudoersтолько для перезапуска сервиса (для watchdog'а) и запускает всё в изолированномvenv. Бот не имеет доступа к root.Root(Для опытных): Если вам нужен полный фарш —rebootсервера,apt updateи чтение всех логов прямо из бота — вы можете выбрать этот режим.
90% аналогов просто предлагают запустить всё от рута. Я считаю это порочной практикой.
2. Watchdog, который не плачет
Бот — это сервис. А сервисы падают. Поэтому у меня их два: tg-bot.service и tg-watchdog.service.
watchdog.py — это отдельный, максимально "тупой" и надёжный скрипт. Его задача — раз в 5 секунд проверять статус systemctl status tg-bot.service.
Ключевая фишка: он не просто шлёт алерт "всё упало". Он присылает админу одно сообщение и редактирует его, показывая жизненный цикл:
Сервис бота Недоступен ?(и тут же даёт командуsystemctl restart)(если сервис стартует)
Сервис бота Активируется ?(когда сервис поднялся)
Сервис бота Активен ?

Но главная моя боль — ложные срабатывания. Когда я сам перезапускаю бота (например, через deploy.sh или из админки самого бота), я не хочу получать паническое "ШЕФ, ВСЁ УПАЛО!".
Поэтому bot.py перед плановым рестартом создаёт restart_flag.txt. А watchdog.py, прежде чем бить тревогу, проверяет: "Ага, есть restart_flag.txt. Значит, рестарт плановый. Молчу."
Python
# Кусочек из watchdog.py
# ...
else:
logging.warning(f"Сервис бота '{BOT_SERVICE_NAME}' НЕАКТИВЕН. ...")
# Проверка на плановый перезапуск (остается важной!)
if os.path.exists(RESTART_FLAG_FILE):
logging.info(f"Обнаружен плановый перезапуск. Alert-система не вмешивается.")
return
# Это настоящий сбой
if not bot_service_was_down: # Если это *первое* обнаружение сбоя
state_to_report = "down"
alert_type = "bot_service_down"
message_text = f"Сервис бота <b>{BOT_SERVICE_NAME}</b> Недоступен ?"
# ...
Это простое, но гениальное решение сэкономило мне кучу нервов.
3. Real-time мониторинг логов через tail -f
Мне мало знать, что CPU 10%. Я хочу знать, кто зашёл на мой сервер прямо сейчас. Поэтому я встроил в bot.py (который крутится в asyncio) фоновые задачи, которые непрерывно слушают tail -f на критичные логи.
Бот асинхронно читает auth.log (или secure) и fail2ban.log. Как только там появляется новая строка Accepted ... for ... from ... или fail2ban.actions.* Ban ..., бот парсит её и мгновенно шлёт мне алерт с флагом страны, IP и юзером.

Это даёт невероятное чувство контроля. Я ещё не успел закрыть дверь, а уже знаю, что кто-то (или что-то) зашло на сервер. И, конечно, эти алерты можно тонко настроить в меню "? Уведомления".
Python
# Кусочек из bot.py - запуск мониторов
# ...
if ssh_log_file_to_monitor:
task_logins = asyncio.create_task(reliable_tail_log_monitor(ssh_log_file_to_monitor, "logins", parse_ssh_log_line), name="LoginsMonitor")
background_tasks.add(task_logins)
else: logging.warning("Не найден лог SSH. Мониторинг SSH (logins) не запущен.")
task_bans = asyncio.create_task(reliable_tail_log_monitor(f2b_log_file_to_monitor, "bans", parse_f2b_log_line), name="BansMonitor")
background_tasks.add(task_bans)
# ...
4. Глубокая интеграция: Администрирование Core-сервисов
А вот и та самая "узкая задача". Многие из нас используют VPS для кастомных сетевых приложений, часто работающих на Docker. Они зависят от быстро обновляемых Core-библиотек, которые обеспечивают, скажем так, саму логику транспортировки данных. Обновлять их вручную — та ещё морока.
Бот автоматически определяет (по именам Docker-контейнеров) известные типы панелей управления (например, mar***n или a***ia) и обновляет их ядро до последнего стабильного релиза с GitHub в один клик. Код явно указывает на releases/latest/download, так что мы берём именно свежий стабильный билд, а не nightly-сборку.
Ну и вишенка на торте — генератор конфигураций доступа. Многим часто нужно поделиться доступом к своему сервису. Теперь вы можете просто скинуть боту JSON-файл с настройками. Бот на лету парсит его, генерирует конфигурационную ссылку нужного формата (да, ту самую, vless://...) и QR-код для клиента. Максимально удобно.

Что дальше? (Спойлер: Агент-Нода)
Этот бот решает мои текущие задачи. Но я уже смотрю в будущее. Сейчас это монолит: один бот на один сервер. Это не масштабируется.
Мой road-map выглядит так:
Архитектура "Агент-Нода". Текущий бот станет "Агентом" (или "Центром управления"). На все VPS будут ставиться легковесные "Ноды" — минималистичные скрипты. Агент будет давать им команды, а ноды — рапортовать о состоянии. Это позволит управлять парком серверов из одного бота.
Модульность. Я вынесу специфичные фичи (обновление Core-библиотек, Fail2Ban) в отдельные модули/плагины. Не нужен мониторинг F2B? Просто отключи модуль в конфиге. Хочешь добавить мониторинг Docker? Пишешь свой
docker_plugin.py.Локализация (EN/RU). Проект уже на GitHub, и я вижу к нему интерес. Первое, что нужно сделать — полная английская локализация.
И это только начало.
Заключение
Я сделал инструмент, который решил мою головную боль. Он безопасный, надёжный и делает ровно то, что мне нужно, не пытаясь быть комбайном.
Проект полностью open-source (GPL-3.0), написан на современном Python и aiogram 3.x. Если у вас, как и у меня, "чесались руки" сделать удобную админку для своих серверов — добро пожаловать.
Заходите на GitHub, ставьте звезды, предлагайте фичи, форкайте. Давайте сделаем управление VPS удобным, без костылей и дыр в безопасности.
Спасибо за внимание!
Комментарии (14)

pr0l
22.10.2025 14:19кто будет следить за ботом?)

jatix Автор
22.10.2025 14:19Если речь идёт о новых релизах и багфиксах — то да, это я.
А так — код не содержит никаких скрытых «мышеловок», удалённого сбора данных или трекинга (даже в обезличенном виде). Всё реализовано безопасно: работает в VENV и с локальными ENV-переменными.
Все личные данные (Telegram ID и конфиги каждого пользователя) генерируются исключительно локально.
Остальное — на плечах библиотек, подключённых через импорт, и, соответственно, на стеках aiogram и Telegram API.Поэтому — пользуйтесь спокойно!
Если говорить о проекте в целом — следить за ним или нет, дело каждого. Я никого не принуждаю. Сегодня это просто Telegram-бот, а завтра — конкурентоспособный продукт с WebUI, интеграциями и множеством функций, которых нет ни в одной другой системе мониторинга.
Какое будущее ждёт этот проект — никто, кроме вас, не знает.Как я уже писал ранее — это open-source-проект, изначально созданный под мои личные нужды с мыслью:
«Блин, ну вот классно было бы реализовать эту функциональность прямо внутри бота — чтобы всё было под рукой: зашёл в чат, ткнул и сразу получил ответ в виде сообщения».
Я открыт к pull-реквестам, багхантерству и любой конструктивной критике, кроме фраз вроде «ну есть же миллион таких и подобных программ».
Да, я переизобрёл велосипед — но, камон, это велосипед другого уровня, со своим стилем и вишенкой на торте.
alexs963
22.10.2025 14:19Кто будет следить что бот не упал, не завис?

jatix Автор
22.10.2025 14:19Watchdog.py (и сервис tg-watchdog.service) который установлен выливается вместе с основным ботом (в установщике вшита проверки всего бота и его ядра и модулей) следит за этим сервисом и рестартует его если в логах замечает Critical или KillService (SIGINT/SIGTERM), а так же следит за задержкой между нажатием кнопки и его отработкой и сигнализирует все в виде вывода ошибки и кусочка лога который ему не понравился.

pr0l
22.10.2025 14:19)) те когда сервак тупо повиснет, либо у него упадет инет, вы об этом не узнаете?
тут многие хотят донести до вас, что как проект чтобы набить умения классно. Но как реальный проект живущий и помогающий спотыкается об самые банальные вещи - сервак вырубился (повис, DNS не резолвит хосты, выключили, остановили за не уплату и тд) вы об этом узнаете не от бота установленного на этой же машине. (ну или пишите функцию heartbeat себе сообщением в телегу, не пришло - значит упал)
jatix Автор
22.10.2025 14:19Я понял про что вы говорите. Вы имеете в виду реализацию Ноды и Агента. Это в одной из следующих релизов будет.

Hopenolis
22.10.2025 14:19fail2ban не нужен, достаточно изменить стандартный порт ssh и стуки прекращаются полностью. А случаи когда кто то зашел на твой сервер через ssh с левого ип это вообще какой то феерический бред. Никогда такого не видел, делать для такого случая какое то там красивое оповещение - как такое в голову вообще прийти могло.
Когда сервер зависает, скажем от того что память утекла, он зависает наглухо, никакие тг боты не выживают.

jatix Автор
22.10.2025 14:19В установочнике — не соглашаемся с установкой и в bot.py в переключателе модулей находим строчку
ENABLE_FAIL2BAN = TrueИ меняем
TrueнаFalseСоответственно не будет Fail2Ban и не будет кнопки которая будет отвечать за вызов этого модуля, при желании — можешь удалить модуль даже в папке /opt/tg‑bot/modules/fail2ban.py, на работу бота — это никак не повлияет, но крайне не рекомендую этого делать, потому что может нарушится карта кнопок, и в целом возможность пользоваться самим модулем — не будет в последствии из бота, если даже Fail2Ban установишь.
Идея с оповещением не нова, она используется у хостеров (если твоим VPS пользуется больше одного человека, проект или сайт у тебя на нем, разные могут быть ситуации, опять же, если не нужно — отключаем оповещение. Все очень даже гибко настраивается. Критика должна быть обоснованной не только исходя из собственного опыта, а поглядывая и на тех кто рядом.
m1skam
А чем не устроили Prometheus / VictoriaMetrics / Zabbix и тд?