04.07.2025 13:00
eternaladm 19 5500 Источник

Привет, Хабр! Ручной мониторинг серверов и логов - это как разжигать костёр вместо использования микроволновки. Если вы вручную проверяете логи, доступность сервисов или реагируете на алерты посредством почты - попробуйте перейти на автоматизацию.

Почему скрипты?

  • Гибкость: кастомитазция проверки под свои нужды

  • Простота: запуск в cron или systemd - и можно с чистой душой забыть о проблеме

  • Самовосстановление: скрипт может не только найти проблему, но и исправить её (рестарт службы, чистка ненужных файлов, логов)

Автоматизированный мониторинг - это не про сложные системы в стиле Zabbix или Prometheus (они очень хороши для масштабируемых решений, данного факта не отрицаю). Это простые скрипты, которые делают ровно то, что вам нужно. Нет лишних зависимостей, сложных конфигов или чего-то лишнего.

Почему автоматизация мониторинга - крайне важный аспект

  • Экономия времени: скрипты работают 24/7, не уходят с работы, берут часть вашей рутинной работы на себя

  • Мгновенное оповещение: телеграм-бот напишет (и, возможно исправит) о проблеме раньше, чем пользователи могут начать жаловаться

  • Самовосстановление: скрипты могут исправить некоторые ошибки автоматически (рестарт служб, запуск служб, освобождение места на диске)

  • Практически полностью отсутствует человеческий фактор: скрипт не забудет проверить логи или отреагировать на алерт

Почему код может быть лучше готового софта для мониторинга?

Готовые системы мониторинга (Zabbix, Nagios) - крайне мощные инструменты, но иногда они могут быть избыточными для различных ситуаций. Скрипты оказываются удобнее, вот почему:

  1. Гибкость и кастомизация:

    • Готовые решения часто ограничены своим функционалом. Если вам требуется нестандартная проверка или особый формат уведомления - придётся искать плагины или громоздить костыли.

    • Скрипты делают только то, что нужно вам. Никакого лишнего функционала. Нужен парсинг специфичного лога? Никаких проблем. Необходимо, чтобы бот слал алерты? Легко.

  2. Легкость развёртывания:

    • Софт для мониторинга нередко требует настройки сервера, агента, БД.

    • Скрипты часто работают сразу: запустил - работает.

  3. Ноль лишних зависимостей:

    • Готовый софт может требовать Java, Docker и тд.

    • Bash/Python/PowerShell присутствует почти на любом сервере.

  4. Самовосстановление без сложной логики:

    • В 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

Заключение

  1. Скрипты идеальны для:

    • Нестандартных задач

    • Мгновенного реагирования

    • Простых инфраструктур

    • Сценариев "здесь и сейчас" (рестарт служб, блокировка IP)

  2. Крупный, готовый софт незаменим для:

    • Крупных распределённых систем

    • Сложных метрик

    • Централизованного управления

    • Долгосрочного использования и хранения данных

В итоге, выбор между готовыми системами мониторинга и скриптами зависит от конкретных задач и масштаба инфраструктуры. Скрипты отлично себя показывают в небольших проектах/сетях, где разворачивать полноценную систему мониторинга будет избыточно. Иногда проще закрыть задачу стандартными инструментами. С другой же стороны, в крупных системах без профессиональных решений вроде Zabbix не обойтись - они дают централизованное управление и глубокую аналитику.

Но это не значит, что выбирать нужно что-то одно. На практике, я часто встречал гибридные решения в стиле: базовый мониторинг через Nagios, который дополняется скриптами для нестандартных проверок или быстрого реагирования. Например, Zabbix может отслеживать общее состояние сервисов, а bash-скрипт - реагировать на критические ошибки в логах.

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

Буду рад обсудить ваше мнение на этот счёт в комментариях!

P.S. Я запустил свою группу в Телеграмм, буду рад видеть всех, кому интересен процесс написания скриптов и автоматизация в мире IT.

Комментарии (19)


  1. Sosnin
    04.07.2025 13:36
    #28528518

    Скрипты - это прикольно. Но с расширением инфраструктуры приходишь к тому, что всё это надо где-то централизовано хранить в актуальном виде. Да и свои же наработки бывает необходимо копипастить. Всё просто когда серверов 10, а когда 100-1000? Так и приходим к оркестрации, а вот ее уже бэкапить


    1. eternaladm Автор
      04.07.2025 13:36
      #28530582

      Спасибо за комментарий! Безусловно, расширение инфраструктуры усложняет использование скриптов, в этом плане я даже не спорю. Но, не стоит забывать, что достаточно много организаций не имеют даже планов по расширению, а из пула серверов - печати, 1С и, это в лучшем случае. Я в начале карьеры работал штатным админом в учебном заведении, там скрипты покрывали 99% задач.

      Всё просто когда серверов 10, а когда 100-1000?

      Это уже что-то про масштабные организации. Я говорил, что скрипты могут покрыть задачи небольших организаций, а с средними/крупными - только централизованное управление (Zabbix, Nagios).


  1. berez
    04.07.2025 13:36
    #28528740

    Проблема самописных скриптов мониторинга - в том, что их тоже надо иногда мониторить. А они дают чувство ложной безопасности и мониторить вроде бы нечего. Но при этом у скриптов нет общего механизма отслеживания статуса - отработал, не отработал, выдает ошибку, не выдает... К тому же что-то могло поменяться вне скрипта, и он - будучи корректным - может перестать делать что-то осмысленное.

    К примеру, когда-то давно у нас показания датчиков складировались в текстовые файлы. А скриптик из этих текстовых файлов брал последнюю строчку и при превышении показателей (конкретно- температуры) слал алярмы - мол, сервер перегрелся, срочно спасайте, а я пока его выключаю. Алярмы были редкостью, поэтому никто как-то о скрипте не думал - ну есть и есть, где-то запускается, приглядывает. И вот однажды приходит алярм со странными показаниями. Сервер, понятно, потушен. Смотрим графики мониторинга - да нет, все в норме, до самого конца все графики ровные, никаких аномалий. Открываем чудесный скрипт, начинаем проверять - мама дорогая, у нас эти файлики уже два года в бинарном формате, а скрипт их парсил как текстовые...


    1. dyadyaSerezha
      04.07.2025 13:36
      #28530570

      А что бы сделал Zabbix?


      1. dyadyaSerezha
        04.07.2025 13:36
        #28533144

        Минус за что? За вопрос? Он неполиткорректный или что?)


      1. Whols
        04.07.2025 13:36
        #28533320

        В данной организации - ничего. Zabbix предполагает наличие оператора, который, хоть как-то реагирует на сообщения в даш/почту. Решения "сервер перегрелся я его включаю" принимаются после анализа ipmi и согласования с отделами.


        1. dyadyaSerezha
          04.07.2025 13:36
          #28533876

          Не очень понятно. Задача: вам надо автоматически отключать сервер при перегреве. Если не надо, то первоначальный скрипт был неправильный по определению, даже с текстовой версией файла. Тогда при чем тут переход со скрипта на Zabbix? А если все-таки надо отключать, то как это сделал бы Zabbix? И как бы такое решение отреагировало на внезапную смену текста на двоичный формат?

          ЗЫ. Про Zabbix не знаю ничего.


    1. eternaladm Автор
      04.07.2025 13:36
      #28530586

      Спасибо за комментарий! Да, отчасти вы правы, но ведь многое зависит от автора скриптов. Если все делать более-менее грамотно - вряд-ли возникнут проблемы. У меня есть пара личных серверов, мониторинг которых полностью покрывается скриптами + документация (что, где, как и куда) даёт возможность следить за изменениями. Опять же, в случае масштабирования скриптами не ограничиться, о чём я говорил выше.


  1. azk
    04.07.2025 13:36
    #28529742

    Используйте заббикс и не выдумывайте причины не использовать его для маленькой инсталляции. Он может работать на конфигурации 2/4. Кастомные скрипты выполнить из zabbix проще простого. Он выполняет все необходимые функции мониторинга из коробки, можно настроить мониторинг выполнения скриптов, чего сложнее добиться кроном. В отличии от скриптов, у вас будет история сработок(частота и время появления, повторяемость) в удобном виде, а это не мало важно при дебаге. Централизованное место где видно текущее состояние инфраструктуры ( иногда нужно посмотреть не только на проблемы, но и спланировать рост и прочее). Ваш совет из разряда вредных, но это субъективно моё мнение.


    1. eternaladm Автор
      04.07.2025 13:36
      #28530596

      Спасибо за комментарий! Вы, почему-то, не берете в расчёт, что пространство ситуаций не ограничивается "стандартными" и всем известными. Есть экзотика и специфика, с которой мне доводилось сталкиваться за свою практику. Зачем мне громоздить и разворачивать Zabbix, если сервер изолирован от остальных и используется относительно редко, но полностью отказаться на данный момент нельзя?

      Или, пример вне работы. Зачем мне разворачивать Zabbix для двух личных серверов, если скрипты полностью покрывают необходимые задачи?

      Я в статье не призывал использовать только скрипты. Даже наоборот, писал, что в случае минимального масштаба они не покроют и часть задач.


    1. Whols
      04.07.2025 13:36
      #28533336

      Выполнение кастомных скриптов требует некоторого понимания 'что и под кем', иначе возникнут проблемы другого уровня. Все это требует квалификации - откуда она возьмется в смол-сегменте?


  1. sukharichev
    04.07.2025 13:36
    #28530134

    Чтобы написать хороший скрипт, даже с помощью ИИ, это надо употеть. Скрипт, который просто что-то там проверяет нежизнеспособен. Внутри него и вокруг надо намазывать, по сути, собственную систему обработки ошибок, логирования, самопроверки, многоканальных алертов и т. п. И тут выясняется, что проще стянуть готовый докер-образ заббикса, чем всем этим заниматься.

    Поэтому на одиноком тестовом сервере - да, можно и скрипты, на всем остальном только что-то готовое. Если заббикс избыточен, есть более легкие варианты, или вовсе локальные типа monit.


    1. eternaladm Автор
      04.07.2025 13:36
      #28530602

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

      Чтобы написать хороший скрипт, даже с помощью ИИ, это надо употеть. 

      Полагаю, тут каждому своё. Не испытываю проблем с написанием скриптов и, более того, данный процесс мне интересен. Почему бы не использовать данную возможность, если она присутствует? Зачем мне Zabbix/иные варианты, если каждый из них будет избыточен. Мне не нужен заранее прописанный и ограниченный функционал, я сделаю сам ровно то, что мне нужно.


  1. swshoo
    04.07.2025 13:36
    #28530362

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


    1. dyadyaSerezha
      04.07.2025 13:36
      #28530574

      Так это же хорошо. Ты становишься востребованным и даже незаменимым спецом в проекте, все на тебя молятся, кофе тебе приносят из хорошей кофейни, а не из кофе-машины на кухне, и всё такое... ;)


    1. eternaladm Автор
      04.07.2025 13:36
      #28530606

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


  1. Busla
    04.07.2025 13:36
    #28531422

    • Автоматический рестарт службы:

    $service = "nginx"
if ((Get-Service $service).Status -ne "Running") {
   Start-Service $service

    Обычно подобное приводят как пример для инструментов (агентского) управления конфигурациями: chef, puppet, powershell dsc — когда описано некоторое состояние системы, а агент старается постоянно приводить систему к этому состоянию.

    Но на самом деле автоматический перезапуск упавшей службы реализуется штатными средствами что в Windows, что в systemd в linux.


    1. Lordzero
      04.07.2025 13:36
      #28532072

      Насчёт systemd ничего не скажу, но в винде запросто бывают ситуации когда после перезагрузки сервера, например, определенные службы не стартуют, даже если в них прописаны параметры автоматического перезапуска и включен автозапуск, а если запустить руками - все работает отлично


    1. Whols
      04.07.2025 13:36
      #28533380

      Никсы разных версий бывают. Иногда и руками приходиться поднимать. Чаще всего проблема сервиса внутри потока отдельного процесса ВМ связана с выделением ресурсов. При этом сервис остаётся формально в рабочем состоянии. Решает даже не мониторинг статуса, а периодический рестарт сервиса.