> https://ask.fedoraproject.org/en/question/44938/can-systemd-...Спасибо, узнал про systemd mailer. Но какие же там предлагаются портянки вместо простого и понятного (в т.ч. документированного) языка monitrc...
> В любом случае, мы живем в реальном мире. Где-то существуют системы, в
> которых все сервисы, влияющие на работоспособность обернуты monit, но в мире,
> где я живу, такой роскоши нет и не предвидится, т.к. ни
> у кого нет на это сил/времени.
Просто к сведению -- кусочки конфигурации можно дёргать из альта, там хороший набор дополнений: http://packages.altlinux.org/ru/Sisyphus/srpms/monit/sources...
> Для таких мониторинг писать лень, т.к. их масса на куче серверов.
> [...] monit тут не спасает, вернее спасает только теоретически.
Кого как -- если дистрибутив и пакетная база являются данностью, то скорее да. А если можно сделать хорошо не только на локалхостах, то нет. Проверено.
> Второй тип - свои (разрабатываемые) или купленные или другие подобные "левые" сервисы.
> Обычно вешаются под перезапускалку типа supervisord (а теперь можно прямо под
> systemd), подключатся к анализатору логов и снимаются показатели в zabbix или
> nagios. При таком типе мониторинга monit тоже вроде как ни при делах.
Потому что вместо него взят supervisord, который был бы не при делах, если бы взят был тот же monit? :)
> от [...] левых перезапускалок никуда не деться, т.к. systemd внедрен
> в продакшене недостаточно, а стратегия "запускать всегда под supervisord,
> а под чем запускается он сам - upstart или systemd, без разницы" дает
> универсальность. Но это вопрос времени)
Думаю, нет -- это типовое generalist vs specialist, комбайн vs инструмент. Т.е. баланс ещё сползёт, но и только.
> Я понимаю, что и от monit есть прок, но по факту вижу кучу примеров, когда systemd
> полезен, а с monit никто и заморачиваться не будет.
Это понятно, но с моей колоколенки кажется проблемой образования и подхода -- когда этот "никто" не склонен "заморачиваться", косяки у него вылезут не здесь, так там.
> Если сервис критичен, нужно постараться воткнуть несколько копий с
> каким-либо load balancing'ом и подключить мониторинг общих очередей в zabbix,
> и падения отдельных инстансов перестают быть критической ситуацией.
Кстати, у меня сложился рабочий вывод, что мониторинг хорош активный локальный с пассивным распределённым.
> По моему опыту, большая часть системных сервисов отваливается, а не залипает.
Да, залипания реже. Но у них и воспроизводимость с предсказуемостью сильно ниже.
> В любом случае, покрыть часть кейзов это лучше, чем ничего.
Зависит от того, считается ли полученный полстакан "наполовину полным" (закрытым вопросом) или "наполовину пустым" (открытым и требующим доработки).
> Запустить systemctl и посмотреть, что точно упало - это не проверка работоспособности
> сервера, а один из многих шагов поиска проблем. И хорошо, что есть такая возможность.
Эт понятно.
> Я не про изоляцию.
А я вполне сознательно про неё. Потому что отслеживание одичавших процессов -- очередная полумера, в то время как рассаживание не нуждающихся в общих пространствах имён процессов именно по контейнерам позволяет обеспечивать заметно большую эксплуатационную надёжность по сумме факторов, включая и обновления, и заменяемость/масштабируемость.
> Я про то, что systemd - первое решение, предлагающее надежное отслеживание всех
> сервисов их потомков в противовес созданию pid-файла, поиска процесса в списке,
> сравнения актуальности с pid-файлом, проблем с отпочковавшимися детьми и прочим.
А знаете, чего от этого подхода ждать? Дальнейшего понижения планки -- "да чего я буду следить за детишками, пусть полицай следит".
