
Привет, Хабр! Ручной мониторинг серверов и логов - это как разжигать костёр вместо использования микроволновки. Если вы вручную проверяете логи, доступность сервисов или реагируете на алерты посредством почты - попробуйте перейти на автоматизацию.
Почему скрипты?
Гибкость: кастомитазция проверки под свои нужды
Простота: запуск в
cron
илиsystemd
- и можно с чистой душой забыть о проблемеСамовосстановление: скрипт может не только найти проблему, но и исправить её (рестарт службы, чистка ненужных файлов, логов)
Автоматизированный мониторинг - это не про сложные системы в стиле Zabbix или Prometheus (они очень хороши для масштабируемых решений, данного факта не отрицаю). Это простые скрипты, которые делают ровно то, что вам нужно. Нет лишних зависимостей, сложных конфигов или чего-то лишнего.
Почему автоматизация мониторинга - крайне важный аспект
Экономия времени: скрипты работают 24/7, не уходят с работы, берут часть вашей рутинной работы на себя
Мгновенное оповещение: телеграм-бот напишет (и, возможно исправит) о проблеме раньше, чем пользователи могут начать жаловаться
Самовосстановление: скрипты могут исправить некоторые ошибки автоматически (рестарт служб, запуск служб, освобождение места на диске)
Практически полностью отсутствует человеческий фактор: скрипт не забудет проверить логи или отреагировать на алерт
Почему код может быть лучше готового софта для мониторинга?
Готовые системы мониторинга (Zabbix, Nagios) - крайне мощные инструменты, но иногда они могут быть избыточными для различных ситуаций. Скрипты оказываются удобнее, вот почему:
-
Гибкость и кастомизация:
Готовые решения часто ограничены своим функционалом. Если вам требуется нестандартная проверка или особый формат уведомления - придётся искать плагины или громоздить костыли.
Скрипты делают только то, что нужно вам. Никакого лишнего функционала. Нужен парсинг специфичного лога? Никаких проблем. Необходимо, чтобы бот слал алерты? Легко.
-
Легкость развёртывания:
Софт для мониторинга нередко требует настройки сервера, агента, БД.
Скрипты часто работают сразу: запустил - работает.
-
Ноль лишних зависимостей:
Готовый софт может требовать Java, Docker и тд.
Bash/Python/PowerShell присутствует почти на любом сервере.
-
Самовосстановление без сложной логики:
В Zabbix/Prometheus, автоисправление - это отдельная настройка.
В скрипте это 3 строки кода:
if service nginx status | grep -q "dead"; then
systemctl restart nginx
fi
Когда скрипты могут быть наилучшим решением? В какой ситуации использовать?
Нет бюджета на лицензионный софт - бесплатные скрипты против платных лицензий.
Необходима быстрая проверка "здесь и сейчас" - не хотите разворачивать Prometheus ради одного сервера.
Нестандартные источники данных - мониторинг Arduino, кастомных API.
Автоматические действия - очистка кеша, рестарт служб, блокировка IP.
Что можно автоматизировать?
Мониторинг доступности сервисов (Python/PowerShell)
Простой пример скрипта на Python для проверки доступности сайта:
import requests
def check_website(url):
try:
response = requests.get(url, timeout=5)
return response.status_code == 200
except:
return False
if not check_website("https://example.com"):
print("Сайт недоступен!") # Можно добавить отправку в Telegram
Аналог на PowerShell:
$url = "https://example.com"
try {
$response = Invoke-WebRequest -Uri $url -TimeoutSec 5
if ($response.StatusCode -ne 200) { Write-Host "Сайт недоступен!" }
} catch { Write-Host "Ошибка подключения!" }
Парсинг логов и алерты в Telegram (bash + gerp + cron)
Допустим, необходимо мониторить ошибки в nginx-логах и получать уведомления:
#!/bin/bash
LOG_FILE="/var/log/nginx/error.log"
TG_BOT_TOKEN="YOUR_TELEGRAM_BOT_TOKEN"
TG_CHAT_ID="YOUR_CHAT_ID"
ERRORS=$(grep -i "error\|failed" "$LOG_FILE" | tail -n 5)
if [ -n "$ERRORS" ]; then
curl -s -X POST "https://api.telegram.org/bot$TG_BOT_TOKEN/sendMessage" \
-d "chat_id=$TG_CHAT_ID" \
-d "text=Обнаружены ошибки в логах Nginx:
$ERRORS"
fi
Добавляем скрипт в cron (crontab -e
):
*/5 * * * * /path/to/your/script.sh
Самовосстановление: автоматическое исправление проблем
Например, если диск заполнен на 90% - скрипт вычистит старые логи:
#!/bin/bash
THRESHOLD=90
USAGE=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
echo "Очистка диска..."
find /var/log -type f -name "*.log" -mtime +7 -delete
# Можно добавить уведомление в Telegram
fi
Возможность интеграции с Telegram для мгновенных алертов
Telegram — идеальный инструмент для уведомлений:
Бесплатно
Мгновенные push-уведомления
Поддержка ботов
Пример отправки сообщения через Python:
import requests
def send_telegram_alert(message):
bot_token = "YOUR_BOT_TOKEN"
chat_id = "YOUR_CHAT_ID"
url = f"https://api.telegram.org/bot{bot_token}/sendMessage"
payload = {"chat_id": chat_id, "text": message}
requests.post(url, json=payload)
send_telegram_alert("Сервер перегружен! CPU > 90%")
Готовые примеры для автоматизации
Мониторинг нагрузки CPU:
import psutil, time
while True:
cpu_load = psutil.cpu_percent(interval=1)
if cpu_load > 80:
print(f"Высокая загрузка CPU: {cpu_load}%")
# Можно добавить отправку в Telegram
time.sleep(60)
Автоматический рестарт службы:
$service = "nginx"
if ((Get-Service $service).Status -ne "Running") {
Start-Service $service
Send-MailMessage -To "admin@example.com" -Subject "Служба $service перезапущена" -Body "Служба была остановлена и перезапущена автоматически."
}
Мониторинг изменений в файлах:
sudo apt install inotify-tools # Для Debian/Ubuntu
inotifywait -m /etc/nginx -e modify |
while read path action file; do
echo "Файл $file был изменён! Отправляем алерт..."
# Тут можно добавить отправку в Telegram
done
Заключение
-
Скрипты идеальны для:
Нестандартных задач
Мгновенного реагирования
Простых инфраструктур
Сценариев "здесь и сейчас" (рестарт служб, блокировка IP)
-
Крупный, готовый софт незаменим для:
Крупных распределённых систем
Сложных метрик
Централизованного управления
Долгосрочного использования и хранения данных
В итоге, выбор между готовыми системами мониторинга и скриптами зависит от конкретных задач и масштаба инфраструктуры. Скрипты отлично себя показывают в небольших проектах/сетях, где разворачивать полноценную систему мониторинга будет избыточно. Иногда проще закрыть задачу стандартными инструментами. С другой же стороны, в крупных системах без профессиональных решений вроде Zabbix не обойтись - они дают централизованное управление и глубокую аналитику.
Но это не значит, что выбирать нужно что-то одно. На практике, я часто встречал гибридные решения в стиле: базовый мониторинг через Nagios, который дополняется скриптами для нестандартных проверок или быстрого реагирования. Например, Zabbix может отслеживать общее состояние сервисов, а bash-скрипт - реагировать на критические ошибки в логах.
По итогу, главное - чтобы мониторинг работал эффективно. Если скрипты могут покрыть ваши задачи - отлично. Если инфраструктура растёт и требует сложных решений - всегда можно развернуть специализированные решения. Главное - не останавливаться на ручном контроле.
Буду рад обсудить ваше мнение на этот счёт в комментариях!
P.S. Я запустил свою группу в Телеграмм, буду рад видеть всех, кому интересен процесс написания скриптов и автоматизация в мире IT.
Комментарии (19)
berez
04.07.2025 13:36Проблема самописных скриптов мониторинга - в том, что их тоже надо иногда мониторить. А они дают чувство ложной безопасности и мониторить вроде бы нечего. Но при этом у скриптов нет общего механизма отслеживания статуса - отработал, не отработал, выдает ошибку, не выдает... К тому же что-то могло поменяться вне скрипта, и он - будучи корректным - может перестать делать что-то осмысленное.
К примеру, когда-то давно у нас показания датчиков складировались в текстовые файлы. А скриптик из этих текстовых файлов брал последнюю строчку и при превышении показателей (конкретно- температуры) слал алярмы - мол, сервер перегрелся, срочно спасайте, а я пока его выключаю. Алярмы были редкостью, поэтому никто как-то о скрипте не думал - ну есть и есть, где-то запускается, приглядывает. И вот однажды приходит алярм со странными показаниями. Сервер, понятно, потушен. Смотрим графики мониторинга - да нет, все в норме, до самого конца все графики ровные, никаких аномалий. Открываем чудесный скрипт, начинаем проверять - мама дорогая, у нас эти файлики уже два года в бинарном формате, а скрипт их парсил как текстовые...
dyadyaSerezha
04.07.2025 13:36А что бы сделал Zabbix?
Whols
04.07.2025 13:36В данной организации - ничего. Zabbix предполагает наличие оператора, который, хоть как-то реагирует на сообщения в даш/почту. Решения "сервер перегрелся я его включаю" принимаются после анализа ipmi и согласования с отделами.
dyadyaSerezha
04.07.2025 13:36Не очень понятно. Задача: вам надо автоматически отключать сервер при перегреве. Если не надо, то первоначальный скрипт был неправильный по определению, даже с текстовой версией файла. Тогда при чем тут переход со скрипта на Zabbix? А если все-таки надо отключать, то как это сделал бы Zabbix? И как бы такое решение отреагировало на внезапную смену текста на двоичный формат?
ЗЫ. Про Zabbix не знаю ничего.
eternaladm Автор
04.07.2025 13:36Спасибо за комментарий! Да, отчасти вы правы, но ведь многое зависит от автора скриптов. Если все делать более-менее грамотно - вряд-ли возникнут проблемы. У меня есть пара личных серверов, мониторинг которых полностью покрывается скриптами + документация (что, где, как и куда) даёт возможность следить за изменениями. Опять же, в случае масштабирования скриптами не ограничиться, о чём я говорил выше.
azk
04.07.2025 13:36Используйте заббикс и не выдумывайте причины не использовать его для маленькой инсталляции. Он может работать на конфигурации 2/4. Кастомные скрипты выполнить из zabbix проще простого. Он выполняет все необходимые функции мониторинга из коробки, можно настроить мониторинг выполнения скриптов, чего сложнее добиться кроном. В отличии от скриптов, у вас будет история сработок(частота и время появления, повторяемость) в удобном виде, а это не мало важно при дебаге. Централизованное место где видно текущее состояние инфраструктуры ( иногда нужно посмотреть не только на проблемы, но и спланировать рост и прочее). Ваш совет из разряда вредных, но это субъективно моё мнение.
eternaladm Автор
04.07.2025 13:36Спасибо за комментарий! Вы, почему-то, не берете в расчёт, что пространство ситуаций не ограничивается "стандартными" и всем известными. Есть экзотика и специфика, с которой мне доводилось сталкиваться за свою практику. Зачем мне громоздить и разворачивать Zabbix, если сервер изолирован от остальных и используется относительно редко, но полностью отказаться на данный момент нельзя?
Или, пример вне работы. Зачем мне разворачивать Zabbix для двух личных серверов, если скрипты полностью покрывают необходимые задачи?
Я в статье не призывал использовать только скрипты. Даже наоборот, писал, что в случае минимального масштаба они не покроют и часть задач.
Whols
04.07.2025 13:36Выполнение кастомных скриптов требует некоторого понимания 'что и под кем', иначе возникнут проблемы другого уровня. Все это требует квалификации - откуда она возьмется в смол-сегменте?
sukharichev
04.07.2025 13:36Чтобы написать хороший скрипт, даже с помощью ИИ, это надо употеть. Скрипт, который просто что-то там проверяет нежизнеспособен. Внутри него и вокруг надо намазывать, по сути, собственную систему обработки ошибок, логирования, самопроверки, многоканальных алертов и т. п. И тут выясняется, что проще стянуть готовый докер-образ заббикса, чем всем этим заниматься.
Поэтому на одиноком тестовом сервере - да, можно и скрипты, на всем остальном только что-то готовое. Если заббикс избыточен, есть более легкие варианты, или вовсе локальные типа monit.
eternaladm Автор
04.07.2025 13:36Спасибо за комментарий! Не спорю, в статье я говорил, что ситуации бывают разные и каждый выбирает что-то своё.
Чтобы написать хороший скрипт, даже с помощью ИИ, это надо употеть.
Полагаю, тут каждому своё. Не испытываю проблем с написанием скриптов и, более того, данный процесс мне интересен. Почему бы не использовать данную возможность, если она присутствует? Зачем мне Zabbix/иные варианты, если каждый из них будет избыточен. Мне не нужен заранее прописанный и ограниченный функционал, я сделаю сам ровно то, что мне нужно.
swshoo
04.07.2025 13:36Самое забавное, что через некоторое время забываешь, что и где крутиться и чего ты там навоял. Особенно, когда инфраструктура начинает подрастать. Через пару лет гасишь замшелый старый ftp, а в другом регионе сервер ложится, который через этот фтп данные забирал -).
dyadyaSerezha
04.07.2025 13:36Так это же хорошо. Ты становишься востребованным и даже незаменимым спецом в проекте, все на тебя молятся, кофе тебе приносят из хорошей кофейни, а не из кофе-машины на кухне, и всё такое... ;)
eternaladm Автор
04.07.2025 13:36Спасибо за комментарий! Да, бывает и такое. Во многом это исправляется качественной и актуальной документацией по всем процессам, которые проходят в организации. Но, человеческий фактор тоже отметать не будем, все мы что-то можем забывать)
Busla
04.07.2025 13:36Автоматический рестарт службы:
$service = "nginx" if ((Get-Service $service).Status -ne "Running") { Start-Service $service
Обычно подобное приводят как пример для инструментов (агентского) управления конфигурациями: chef, puppet, powershell dsc — когда описано некоторое состояние системы, а агент старается постоянно приводить систему к этому состоянию.
Но на самом деле автоматический перезапуск упавшей службы реализуется штатными средствами что в Windows, что в systemd в linux.
Lordzero
04.07.2025 13:36Насчёт systemd ничего не скажу, но в винде запросто бывают ситуации когда после перезагрузки сервера, например, определенные службы не стартуют, даже если в них прописаны параметры автоматического перезапуска и включен автозапуск, а если запустить руками - все работает отлично
Whols
04.07.2025 13:36Никсы разных версий бывают. Иногда и руками приходиться поднимать. Чаще всего проблема сервиса внутри потока отдельного процесса ВМ связана с выделением ресурсов. При этом сервис остаётся формально в рабочем состоянии. Решает даже не мониторинг статуса, а периодический рестарт сервиса.
Sosnin
Скрипты - это прикольно. Но с расширением инфраструктуры приходишь к тому, что всё это надо где-то централизовано хранить в актуальном виде. Да и свои же наработки бывает необходимо копипастить. Всё просто когда серверов 10, а когда 100-1000? Так и приходим к оркестрации, а вот ее уже бэкапить
eternaladm Автор
Спасибо за комментарий! Безусловно, расширение инфраструктуры усложняет использование скриптов, в этом плане я даже не спорю. Но, не стоит забывать, что достаточно много организаций не имеют даже планов по расширению, а из пула серверов - печати, 1С и, это в лучшем случае. Я в начале карьеры работал штатным админом в учебном заведении, там скрипты покрывали 99% задач.
Это уже что-то про масштабные организации. Я говорил, что скрипты могут покрыть задачи небольших организаций, а с средними/крупными - только централизованное управление (Zabbix, Nagios).