Comments 19
Скрипты - это прикольно. Но с расширением инфраструктуры приходишь к тому, что всё это надо где-то централизовано хранить в актуальном виде. Да и свои же наработки бывает необходимо копипастить. Всё просто когда серверов 10, а когда 100-1000? Так и приходим к оркестрации, а вот ее уже бэкапить
Спасибо за комментарий! Безусловно, расширение инфраструктуры усложняет использование скриптов, в этом плане я даже не спорю. Но, не стоит забывать, что достаточно много организаций не имеют даже планов по расширению, а из пула серверов - печати, 1С и, это в лучшем случае. Я в начале карьеры работал штатным админом в учебном заведении, там скрипты покрывали 99% задач.
Всё просто когда серверов 10, а когда 100-1000?
Это уже что-то про масштабные организации. Я говорил, что скрипты могут покрыть задачи небольших организаций, а с средними/крупными - только централизованное управление (Zabbix, Nagios).
Проблема самописных скриптов мониторинга - в том, что их тоже надо иногда мониторить. А они дают чувство ложной безопасности и мониторить вроде бы нечего. Но при этом у скриптов нет общего механизма отслеживания статуса - отработал, не отработал, выдает ошибку, не выдает... К тому же что-то могло поменяться вне скрипта, и он - будучи корректным - может перестать делать что-то осмысленное.
К примеру, когда-то давно у нас показания датчиков складировались в текстовые файлы. А скриптик из этих текстовых файлов брал последнюю строчку и при превышении показателей (конкретно- температуры) слал алярмы - мол, сервер перегрелся, срочно спасайте, а я пока его выключаю. Алярмы были редкостью, поэтому никто как-то о скрипте не думал - ну есть и есть, где-то запускается, приглядывает. И вот однажды приходит алярм со странными показаниями. Сервер, понятно, потушен. Смотрим графики мониторинга - да нет, все в норме, до самого конца все графики ровные, никаких аномалий. Открываем чудесный скрипт, начинаем проверять - мама дорогая, у нас эти файлики уже два года в бинарном формате, а скрипт их парсил как текстовые...
А что бы сделал Zabbix?
Минус за что? За вопрос? Он неполиткорректный или что?)
В данной организации - ничего. Zabbix предполагает наличие оператора, который, хоть как-то реагирует на сообщения в даш/почту. Решения "сервер перегрелся я его включаю" принимаются после анализа ipmi и согласования с отделами.
Не очень понятно. Задача: вам надо автоматически отключать сервер при перегреве. Если не надо, то первоначальный скрипт был неправильный по определению, даже с текстовой версией файла. Тогда при чем тут переход со скрипта на Zabbix? А если все-таки надо отключать, то как это сделал бы Zabbix? И как бы такое решение отреагировало на внезапную смену текста на двоичный формат?
ЗЫ. Про Zabbix не знаю ничего.
Спасибо за комментарий! Да, отчасти вы правы, но ведь многое зависит от автора скриптов. Если все делать более-менее грамотно - вряд-ли возникнут проблемы. У меня есть пара личных серверов, мониторинг которых полностью покрывается скриптами + документация (что, где, как и куда) даёт возможность следить за изменениями. Опять же, в случае масштабирования скриптами не ограничиться, о чём я говорил выше.
Используйте заббикс и не выдумывайте причины не использовать его для маленькой инсталляции. Он может работать на конфигурации 2/4. Кастомные скрипты выполнить из zabbix проще простого. Он выполняет все необходимые функции мониторинга из коробки, можно настроить мониторинг выполнения скриптов, чего сложнее добиться кроном. В отличии от скриптов, у вас будет история сработок(частота и время появления, повторяемость) в удобном виде, а это не мало важно при дебаге. Централизованное место где видно текущее состояние инфраструктуры ( иногда нужно посмотреть не только на проблемы, но и спланировать рост и прочее). Ваш совет из разряда вредных, но это субъективно моё мнение.
Спасибо за комментарий! Вы, почему-то, не берете в расчёт, что пространство ситуаций не ограничивается "стандартными" и всем известными. Есть экзотика и специфика, с которой мне доводилось сталкиваться за свою практику. Зачем мне громоздить и разворачивать Zabbix, если сервер изолирован от остальных и используется относительно редко, но полностью отказаться на данный момент нельзя?
Или, пример вне работы. Зачем мне разворачивать Zabbix для двух личных серверов, если скрипты полностью покрывают необходимые задачи?
Я в статье не призывал использовать только скрипты. Даже наоборот, писал, что в случае минимального масштаба они не покроют и часть задач.
Выполнение кастомных скриптов требует некоторого понимания 'что и под кем', иначе возникнут проблемы другого уровня. Все это требует квалификации - откуда она возьмется в смол-сегменте?
Чтобы написать хороший скрипт, даже с помощью ИИ, это надо употеть. Скрипт, который просто что-то там проверяет нежизнеспособен. Внутри него и вокруг надо намазывать, по сути, собственную систему обработки ошибок, логирования, самопроверки, многоканальных алертов и т. п. И тут выясняется, что проще стянуть готовый докер-образ заббикса, чем всем этим заниматься.
Поэтому на одиноком тестовом сервере - да, можно и скрипты, на всем остальном только что-то готовое. Если заббикс избыточен, есть более легкие варианты, или вовсе локальные типа monit.
Спасибо за комментарий! Не спорю, в статье я говорил, что ситуации бывают разные и каждый выбирает что-то своё.
Чтобы написать хороший скрипт, даже с помощью ИИ, это надо употеть.
Полагаю, тут каждому своё. Не испытываю проблем с написанием скриптов и, более того, данный процесс мне интересен. Почему бы не использовать данную возможность, если она присутствует? Зачем мне Zabbix/иные варианты, если каждый из них будет избыточен. Мне не нужен заранее прописанный и ограниченный функционал, я сделаю сам ровно то, что мне нужно.
Самое забавное, что через некоторое время забываешь, что и где крутиться и чего ты там навоял. Особенно, когда инфраструктура начинает подрастать. Через пару лет гасишь замшелый старый ftp, а в другом регионе сервер ложится, который через этот фтп данные забирал -).
Так это же хорошо. Ты становишься востребованным и даже незаменимым спецом в проекте, все на тебя молятся, кофе тебе приносят из хорошей кофейни, а не из кофе-машины на кухне, и всё такое... ;)
Спасибо за комментарий! Да, бывает и такое. Во многом это исправляется качественной и актуальной документацией по всем процессам, которые проходят в организации. Но, человеческий фактор тоже отметать не будем, все мы что-то можем забывать)
Автоматический рестарт службы:
$service = "nginx"
if ((Get-Service $service).Status -ne "Running") {
Start-Service $serviceОбычно подобное приводят как пример для инструментов (агентского) управления конфигурациями: chef, puppet, powershell dsc — когда описано некоторое состояние системы, а агент старается постоянно приводить систему к этому состоянию.
Но на самом деле автоматический перезапуск упавшей службы реализуется штатными средствами что в Windows, что в systemd в linux.
Насчёт systemd ничего не скажу, но в винде запросто бывают ситуации когда после перезагрузки сервера, например, определенные службы не стартуют, даже если в них прописаны параметры автоматического перезапуска и включен автозапуск, а если запустить руками - все работает отлично
Никсы разных версий бывают. Иногда и руками приходиться поднимать. Чаще всего проблема сервиса внутри потока отдельного процесса ВМ связана с выделением ресурсов. При этом сервис остаётся формально в рабочем состоянии. Решает даже не мониторинг статуса, а периодический рестарт сервиса.
Автоматизация мониторинга: как заставить скрипты работать вместо вас