LINUX.ORG.RU
ФорумAdmin

Посоветуйте тулзу для реагирования на алерты Prometheus и события systemd

 , , ,


2

4

Привет.

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

Собственно, есть недосервер, собранный из очень херового железа (вследствие чего какие-то его части регулярно отваливаются) и исполняющий очень херовый софт (который тоже регулярно отваливается, течёт и сегфолтится).

Сейчас я юзаю Netdata с кастомными плагинами + Prometheus + Alertmanager + Grafana. С помощью регулярных выражений и такой-то матери кое-как отконвертил встроенную библиотеку алертов Netdata в формат Prometheus, настроил репортинг на почту + SMS, вроде норм.

Однако, я замечаю, что моя реакция на большинство событий крайне однообразна. Например, если диск уже полминуты репортит 100% загруженности, а количество операций в секунду - 0, значит, подвис SATA-контроллер и его нужно перезапустить. А если не помогло или скрипт вернул 1, то нужно эскалировать алерт до критического.

Я хочу это автоматизировать. Посоветуйте что-нибудь.

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

Поскольку они все оформлены в виде systemd-юнитов, задача упрощается: нужен софт, который будет мониторить события запуска/остановки systemd-юнитов, собирать их логи из journald и что-нибудь с ними делать (например, отсылать на почту или инжектировать как синтетические алерты в тот же Prometheus).

Я понимаю, что обе хотелки можно набросать на питоне и D-Bus за два часа, но не хочу велосипедить без надобности. Вдруг уже есть какой-нибудь клёвый, модный и молодёжный комбайн, который всё это умеет?

★★★★★

Вдруг уже есть какой-нибудь клёвый, модный и молодёжный комбайн, который всё это умеет?

Всё либо поросшее древними костылями и уже годами страдающее от ошибок архитектуры (забикс), либо попросту сырое.

набросать на питоне и D-Bus за два часа

Звучит проще, чем учиться управлять комбайном и свыкаться с тем, как он устроен.

melkor217 ★★★★★
()
Ответ на: комментарий от e1nste1n

А ведь точно, плюсую monit. Самый простой и легковесный мониторинг из тех, что я видел.

melkor217 ★★★★★
()
Ответ на: комментарий от e1nste1n

melkor217

Monit не интегрируется ни с чем из того, что я перечислил. Всё сведётся к написанию тех же самых скриптов (только хуже, потому что мне не подходит pull-модель).

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от melkor217

набросать на питоне и D-Bus за два часа

Звучит проще, чем учиться управлять комбайном и свыкаться с тем, как он устроен.

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

Всё либо поросшее древними костылями и уже годами страдающее от ошибок архитектуры (забикс), либо попросту сырое.

Давай сырое.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)

Alert manager не только на почту инфу слать может. На него можно какие угодно хуки навешать, в том числе перезапуск.

Про не логиниться не очень понятно. Сделай отправку на почту результата выполнения действия. Если письмо не пришло - разбираешься.

софт, который будет мониторить события запуска/остановки systemd-юнитов, собирать их логи из journald и что-нибудь с ними делать

Этот софт называется systemd. Выправь свои юниты чтобы фейлившаяся задача всегда означала пофейлившийся юнит. И не было такого что юнит как бы здоров а задача не выполнена.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Alert manager не только на почту инфу слать может. На него можно какие угодно хуки навешать, в том числе перезапуск.

Там из релевантного есть только вебхуки. Вебхуки — это, на минуточку, HTTP-сервер с REST API, конфиг с правилами и метамониторинг (если действие не выполнилось, синтезировать новый алерт). Это всё можно навелосипедить, но я не хочу. Вдруг уже есть готовое?

Про не логиниться не очень понятно. Сделай отправку на почту результата выполнения действия. Если письмо не пришло - разбираешься.

Этот софт называется systemd. Выправь свои юниты чтобы фейлившаяся задача всегда означала пофейлившийся юнит. И не было такого что юнит как бы здоров а задача не выполнена.

Не нужно учить меня, как пользоваться systemd :) Это само собой. Но фейлы кто-то должен собирать. Я постоянно логинюсь на сервер, делаю systemctl --failed и потом смотрю логи за последний запуск пофейлившихся юнитов. Я больше не хочу так делать.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Всё сведётся к написанию тех же самых скриптов

Ну а это, пожалуй, никто за тебя не сделает.

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

UPD: За более хипстерские решения ничего не говорить не буду, с ними у меня как-то постоянно не срастается.

melkor217 ★★★★★
()
Последнее исправление: melkor217 (всего исправлений: 1)
Ответ на: комментарий от intelfx

Теоретически то что ты описываешь на тему api - это cockpit. Web-хуки к управлению сервисами. Подойдет ли оно на практике не знаю

alpha ★★★★★
()
Ответ на: комментарий от alpha

Смотрел?

Смотрел. Как бы да, но как бы нет. Он собирает статистику точечными замерами, но больше ничего не делает. Если у меня scraping interval 10s, а юнит за это время выполнился три раза, причём второй раз сфейлился, то я это не поймаю. Не говорю уже про логи и invocation ID.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от melkor217

Ну а это, пожалуй, никто за тебя не сделает.

Ладно, убедили, пойду костылять.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Cockpit - это операции с системой которые ты триггеришь через веб интерфейс. И они реализованы через dbus.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Я знаю. И я говорю не об этом.

У Alertmanager, действительно, есть возможность реагировать на алерты как угодно. Но «как угодно» реализовано через веб-хуки, т. е. тебе предлагается написать HTTP-сервер, который принимает запросы от Alertmanager в определённом формате с жсоном в теле и дальше делает что хочет. Это сразу же означает:

  • HTTP-сервер
  • придумать к нему конфиг и написать парсер
  • сделать метамониторинг (как только Alertmanager передал мне алерт, он дальше за него не отвечает. если мой скрипт сфейлился, я должен запихнуть это событие обратно в Prometheus)
  • ...

Разумно, правда, спросить, вдруг такое уже написано?

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Примерно на этом месте, кстати, становится очевидно, почему я создал один тред на две задачи. Если начинать это писать, сразу же возникает желание в сервере-обработчике алертов тупо синхронно(!) запускать юниты, если systemd вернул ошибку — возвращать 50x, а дальше эти юниты вместе со всеми остальными мониторить согласно второй хотелке, а если они сфейлились — в общем порядке инжектировать в Prometheus новый алерт, дописывать к нему InvocationID и уже другим вебхуком ловить и слать на почту вместе с логами. То есть на самом деле это две части одной задачи, если по-хорошему делать.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от system-root

Прикольно. На первый взгляд выглядит как решение. Как минимум не залочено на poll-модель, лол.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Я писала с телефона, поэтому не развернуто. Попробую ещё раз.

1) если цель автоматизации при падении сервиса его переподнять, то зачем делать round-trip через внешний мониторинг когда именно это же делает systemd? Реализуй это на месте, а внешний мониторинг оставь для случаев когда ты не знаешь что с этим делать.

2)

тебе предлагается написать HTTP-сервер, который принимает запросы от Alertmanager в определённом формате с жсоном в теле и дальше делает что хочет.

Cockpit - это уже HTTP-сервер, у которого уже реализованы функции управления сервисами через dbus. Если цель твоего хука в alert-manager - это перезапустить сервис, то ему достаточно постучаться в cockpit и готово. Payload сформатировать в нужный json - это не проблема.

alpha ★★★★★
()
Ответ на: комментарий от alpha

если цель автоматизации при падении сервиса его переподнять

Нет. Цель автоматизации — (1) при наступлении произвольных указанных условий запустить юнит и (2) при падении юнита (не обязательно из п. 1) отправить его логи за последний запуск мне на мыло.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Я постоянно логинюсь на сервер, делаю systemctl --failed и потом смотрю логи за последний запуск пофейлившихся юнитов. Я больше не хочу так делать.

Сделай запуск по крону с диффом от предыдущего состояния и отправку отчёта тебе, в случае, если дифф есть

dhameoelin ★★★★★
()

Не совсем по теме прометеуса, но на работе использую связку TIGK

telegraf для сбора метрик и проксирования, InfluxDB для хранения, Grafana чтобы рисовать (хронограф еще вместо админки есть) и Kapacitor чтобы алертить и реагировать. Правда сам капаситор именно что про агрегацию данных с инфлюкса и рассылку альертов в случае чего (есть даже куча интеграций со всякими телеграммами и тд), но возможность повесить на событие скрипт присутсвует, пользуюсь ей чтобы дергать дженкинс и например мониторинги перезапускать (есть набор навасяненых кем-то и периодически отъезжающих из-за количества машин).

Dred ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.