Zabbix скрипты, безопасность, Ansible

Какие ужасные костыли. Zabbix - система мониторинга, он не должен перезапускать никакие сервисы на серверах, и вообще как-то активно вмешиваться в их работу.

Поддержу оратора выше, Zabbix для мониторинга, скрипты на стороне zabbix_agentd для расширения мониторинга, а не для управления клиентом! Не надо забивать гвозди шуруповёртом!

Предложите тогда решение. Какие еще варианты вы предлагаете, чтобы автоматизировать и в ответ на сообщения заббикса выполнять определенные скрипты? Или ждать месседжа и все руками?

Вообще-то это предусмотрено триггерами, выполнять команды.

Триггеры предусмотрены для уведомления админа о том что что-то пошло не так. Только человек должен решать что делать с проблемой. А если проблема регулярная, то админа пора менять.

Или ждать месседжа и все руками?

А зачем тогда вообще нужен админ, если мониторинг сам "может" (не может!) всё исправить (скорее доломать).

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

Перезапуск упавших сервисов и чистку чего-то там, если всё это нужно делать автоматически, сервер должен делать сам, автономно.

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

В чем здесь костыли?

Вот «месседж» должен слать заббикс. А всё остальное - сервер сам.

Как практически реализовать? Еще раз перечитайте. Если сервер сам, то всегда будут накладки и ошибочные месседжи - проблема уже решена, а тебе приходит сообщение, что она есть. Это должен быть инструмент синхронизируемый с заббиксом.

1. Насколько это безопасно?

На 73.2%.

2.

Выглядит более логично. В смысле, мониторинг пинает исполнителя, исполнитель исправляет проблему. Исполнителем может быть анзибль, почему ж нет.

для перезапуска упавшего сервиса

Restart=always
https://www.freedesktop.org/software/systemd/man/systemd.service.html

чистки регулярно забивающейся папки

Чисто не там где убирают, а там где не мусорят.

Насколько это безопасно?

Это не безопасно.

есть смысл запускать плейбуки Ansible на стороне сервера Zabbix для решения этих и подобным им вопросов?

Если плейбук сделает хуиту то отвечать будет автор плейбука. При этом ответ «это не я, это плейбук» приниматься не будет.

В заббиксе разве нет «оповещения если ошибка N раз/N секунд подряд» или чего-то похожего?

Это должен быть инструмент синхронизируемый с заббиксом.

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

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

Чисто не там где убирают, а там где не мусорят.

Я так понимаю, дома вы применяете тот же принцип - просто не мусорите и принципиально не убираете. Как успехи? Тут кажется, уже нужно идти в массы, уволить всех бестолковых уборщиков и просто перестать мусорить и проблема решена. Уверен, у вас впереди блестящая политическая карьера )

Если плейбук сделает хуиту то отвечать будет автор плейбука. При этом ответ «это не я, это плейбук» приниматься не будет.

Ок. Уволите меня тогда, господин директор ))

Почему сразу нужно вопринимать, что кто-то делает обязательно какую-то **иту, а вы д’артаньян?

С одной стороны решение. Но я же писал, что очевидно будут накладки. Разумнее идти от события - упал сервис - сообщение в заббикс - действия, не удалось решить - месседж. А не упал сервис - бежать семафорить, что он упал, а оказалось, что уже давно перезапущен пару минут назад. Заставлять заббикс мониторить сильно часто чревато заметно большей нагрузкой.

В принципе ответ я получил. Всем спасибо, особенно thesis - коротко и по делу.

что за самопротиворечие? вполне нормальный запрос со стороны тс. пусть заббикс триггерит какой-то скрипт.

что за самопротиворечие? вполне нормальный запрос со стороны тс. пусть заббикс триггерит какой-то скрипт.

Тебе воткнули нож в живот, но ты не пойдёшь в больницу, пока тебе со стороны не скажут «братан, у тебя кровь!»?

Если проблема возникла на машине, но триггер на её решение должен прилетать от другой машины (причём она может работать через Zabbix Proxy, а то и не один), проблема в голове того кто это придумал.

Насколько это безопасно?

Если заморочиться вопросом, то безопасно. Давать sudo только на определенные команды. Если агент в пассивном режиме, принимать комманды только с захардкодженого хоста заббикс сервера.

может есть смысл запускать плейбуки Ansible

Может быть

не нужно лирики. ситуации бывают разные. например если апп на одной машине из кластера стукнул в заббикс, а действие должно быть применено ко всем хостам.

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