Приветствую всех, дорогие читатели.
В этой статье я расскажу вам о своем «велосипеде», на котором я слежу за разными вещами, не отходя от консоли.
Однажды я столкнулся с ситуацией, когда разрослось довольно много разных проектов и серверов, но настроить нормальный мониторинг я так и не удосужился.
А в современном мире «правильный» мониторинг предполагает развертывание целой кучи программного обеспечения и настройку всего этого.
Ну, вы знаете, там.
докер, эластичный стек и поехали.
Для меня это были сильные накладные расходы.
Я хотел, чтобы он был запущен в производство один или два раза.
Я посмотрел в сторону Простой монитор в Python он был ближе всего мне по духу, но ему не хватало многих функций.
И в то же время мне хотелось выучить Го.
ну, в общем, вы сами знаете, с чего обычно все начинается.
Итак, я взял Go Welding и собрал это.
Cli Monitoring написан на Go и представляет собой набор двоичных файлов, каждый из которых получает данные со стандартного ввода, выполняет свою конкретную задачу и выводит результат на стандартный вывод. Существует четыре типа двоичных файлов: метрики , процессоры , фильтры , И результаты .
Метрики , как следует из названия, собирает некоторые данные и обычно идет первым в цепочке.
Процессоры находятся посередине и каким-то образом меняют данные или выполняют другие служебные функции.
Фильтры почти как процессоры, но в отличие от них пропускают или не пропускают данные в зависимости от состояния.
Выходы располагаются на выходе из цепочки и используются для отправки уведомлений различным сервисам.
Вся цепочка команд обычно выглядит так:
Любой частью этой цепочки может быть любая команда Linux, при условии, что она получает данные в стандартный ввод и отправляет их в стандартный вывод без буферизации.some_metric | processor_1 | processor_2 .
| cm_p_message | output_1 | output_2 .
Есть только одно маленькое НО, связанное с переносами строк, но об этом позже.
Название бинарников формируется как cm_{тип}_{имя} , где тип — один из трех: м, п, д или о , а name — это имя команды.
Например, cm_m_cpu — это метрика, которая выводит статистику ЦП на стандартный вывод в формате json. А файл cm_p_debounce — это процессор, который передает на выход только одно сообщение один раз в заданный интервал.
Есть один специальный процессор cm_p_message , который должен предшествовать первому выводу.
Создает сообщение необходимого формата для последующей обработки Выходами.
Для обработки json в консоли и различных условиях я использовал утилиту jq .
Это что-то вроде sed, но для json. Вот, например, как в итоге выглядит мониторинг загрузки процессора.
cm_m_cpu | cm_p_eot2nl | jq -cM --unbuffered 'if .
LoadAvg1 > 1 then .
LoadAvg1 else false end' | cm_p_nl2eot | cm_f_regex -e '\d+' | cm_p_debounce -i 60 | cm_p_message -m 'Load average is {stdin}' | cm_o_telegram
И так мониторинг количества сообщений в очереди RabbitMQ while true; do rabbitmqctl list_queues -p queue_name | grep -Po --line-buffered '\d+'; sleep 60; done | jq -cM '.
> 10000' --unbuffered | cm_p_nl2eot | cm_f_true | cm_p_message -m 'There are more than 10000 tasks in rabbit queue' | cm_o_opsgenie
Таким образом вы сможете следить за тем, чтобы в файл в течение 10 секунд ничего не записывалось.
tail -f out.log | cm_p_nl2eot | cm_p_watchdog -i 10 | cm_p_debounce -i 3600 | cm_p_message -m 'No write to out.log for 10 seconds' -s 'alert' | cm_o_telegram
Не спешите закрывать экран, теперь давайте посмотрим, что здесь происходит в первом примере.
1) Метрики cm_m_cpu Выводит строки в формате json раз в секунду (устанавливается параметром -i, по умолчанию — секунда).
Например {"LoadAvg1":2.0332031, "LoadAvg2":1.9018555, "LoadAvg3":1.8623047} 2) cm_p_nl2eot одна из служебных команд, преобразующая символ EOT в символ LF. Дело в том, что во избежание проблем с переносами строк я решил заставить все мои бинарники читать данные до ascii-символа EOT (End of Transmission).
Это позволяет безопасно передавать многострочные данные между командами.
Поэтому при вызове любых других команд их необходимо заключать в форму: cm_p_eot2nl | любая другая команда | cm_p_nl2eot. 3) Далее идет вызов утилиты jq , который проверяет поле LoadAvg1 и если оно больше 1, то отображает его дальше, если меньше, отображает false 4) Далее нам нужно удалить все сообщение из цепочки ЛОЖЬ .
Для этого используем фильтр cm_f_regex , который принимает на вход строку, сопоставляет ее с регулярным выражением и, если совпадение есть, выводит ее дальше.
В противном случае строка просто отбрасывается.
Вы можете использовать обычный grep, но, во-первых, он буферизует вывод, и полный синтаксис становится немного длиннее (grep --line-buffered), а во-вторых, cm_f_regex позволяет очень легко печатать совпадения групп.
Например: cm_f_regex -e '(\d+)-(\d+)' -o '{1}/{2}'
Преобразует строку 123–345 в строку 123/345. 5) Процессор cm_p_debounce в данном случае берет наше значение LoadAvg1 и выводит его дальше по цепочке только один раз каждые 60 секунд. Это необходимо для того, чтобы не спамить себя.
Вы можете установить любой другой интервал.
6) Почти все готово.
Остается только сгенерировать сообщение и отправить его в Telegram. Сообщение генерируется специальной командой cm_p_message .
Он просто принимает на вход строку, создает json с полями Severity, Message и другими, а затем выводит ее для обработки по выходам.
Если бы мы не передали ему параметр -m, то сообщение было бы stdin, т.е.
номер проса — наш LoadAvg1. Это не очень информативно.
7) Комада cm_o_telegram просто отправляет полученное на вход сообщение в Telegram. Настройки Telegram хранятся в ini-файле.
Конфигурация
Все параметры, которые принимают двоичные файлы, можно указать в ini-файле.Параметры, указанные в аргументе командной строки, имеют приоритет над ini-файлом.
Формат файла инициализации: [global]
host_name=override host name for this machine
[telegram]
cid=.
token=.
[opsgenie] apiToken=.
apiEndpoint=.
.
[debounce]
i=3600
Сам ini-файл выбирается в следующем порядке:
1) Файл cm.config.ini в текущем рабочем каталоге.
2) Файл /etc/cm/config.ini, если файл из шага 1 не найден
Производство
На реальном сервере я создаю файл, например cpu.sh, в котором содержится вся необходимая цепочка команд. Потом в короне пишу что-то вроде этого: */5 * * * * flock -n /etc/cm/cpu.lock /etc/cm/cpu.sh > /dev/null
Если что-то упадет, стая повторно поднимет команду.
Вот и все! Простота, которой мне так не хватало.
Вот такой получился инструмент, может кому-то он покажется удобным.
Для меня удобство в том, что не надо заморачиваться с кучей ненужных вещей, просто чтобы следить за нужными вещами.
А настраивается все довольно удобно: клонировал репозиторий, добавил в $PATH путь к бинарникам и все.
Пожалуйста, не судите строго.
Инструмент писался для себя, набор команд пока не велик.
Но буду рад любым отзывам и предложениям.
Спасибо всем за внимание.
Теги: #linux #Администрирование сервера #golang #мониторинг #Ненормальное программирование #мониторинг сервера
-
Арамейский
19 Oct, 24 -
Сербскохорватский Язык
19 Oct, 24 -
Все Начинается С Краткого
19 Oct, 24 -
Google Работает Над Киберпанком
19 Oct, 24 -
Видеоэкскурсии На Инфоком2008
19 Oct, 24