LINUX.ORG.RU
ФорумAdmin

Что умеет Nagios?

 ,


0

1

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

Мне было сказано приспособить для этой цели сервер Nagios. Он так умеет?

Оракл на Red Hat, Nagios на CentOS, остальные машины используют оффтопик.

Заранее спасибо.

P.S. Нужно ставить на все машины Nagios Cross-Platform Agent?

Перемещено leave из general

★★★

кроме

собирать воедино все логи

все остальное умеет. ты можешь туда и свои сервисы писать.

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

По каким словам искать в документации? Как это делается, на наблюдаемые машины ставятся демоны/службы для сбора данных?

И какая проблема в сборе логов?

olegd ★★★ ()

Может метрики собирать с православного оракла метрики плагином check_oracle_health. С остальных серверов уровень загрузки процов, памяти, дисков и т.д. Для сбора логов в одно место есть другие инструменты.

anonymous ()
Ответ на: комментарий от olegd

Можно сделать нагиос-плагинами, но из коробки решения нет + придётся писать проверки nrpe самому. Можно погуглить nagios plugin syslog.

kcehna ()
Ответ на: комментарий от olegd

Да, как правило, на наблюдаемые машины ставится служба. Но nagios - мониторинг из разряда сделай сам, и никто не мешает тебе собирать все данные сервера, скажем, по snmp, http или любому протоколу, который вам удобен. Напишите скрипт для обработки в формат, понятный для Nagios, и он будет работать.

Проблема в сборе логов такова, что nagios для этого не предназначен. Он предназначен для сборки метрик. То есть у вас есть какой-то параметр, значение которого вы должны получать и следить за его изменениями. А логи - это не значение и за его изменениями следить не нужно. Значение - это, например, ваш RPS, доступность, число ошибок в минуту или что-то такое - как правило, цифра (хотя некоторые любят мониторить версию ядра - мало ли, хакнут и подменят).

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

И какая проблема в сборе логов?

ну собирать логи он попусту не умеет. и вообще, он не должен это уметь.

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

Проблема в сборе логов такова, что nagios для этого не предназначен. Он предназначен для сборки метрик. То есть у вас есть какой-то параметр, значение которого вы должны получать и следить за его изменениями. А логи - это не значение и за его изменениями следить не нужно. Значение - это, например, ваш RPS, доступность, число ошибок в минуту или что-то такое - как правило, цифра

То есть ни он, ни широко известные плагины неспособны устроить быстрый поиск по всем логам событий, происшедших 2017-09-08 в 14:28:41, например?

Это можно обойти, если отслеживать появление в логах строк с ключевыми словами? Такие плагины есть?

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

Может быть и можно, но я не представляю, как.

Логичнее nagios можно заставить смотреть на наличие строк с ключевыми словами или даже их подсчет (хотя если логи текстовые, у вас могут быть проблемы с анализом по времени). А потом, если в nagios загорелся индикатор, уже смотреть логи руками.

А для анализа логов обычно применяется ELK стэк.

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

хотя если логи текстовые, у вас могут быть проблемы с анализом по времени

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

А для анализа логов обычно применяется ELK стэк.

Можно подробнее?

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

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

Смотрите, у вас есть текстовый лог. Да, в каждой строке есть время. Но это все текст, это обычная строка. То есть чтобы из текстового лога выдрать данные после определенного времени, вам надо анализировать весь файл целиком, каким-то образом текстовое значение времени конвертировать в любое другое, которое можно сравнить на предмет больше-меньше (например, POSIX-формат), сравнить с требуемым значением, и если сравнение удовлетворяет ваше условие, проанализировать строку на предмет наличия искомого ключевого слова. И так каждый раз.

Чтобы этого геморроя избежать, логи лучше хранить в какой-то базульке. Я, например, храню в influxdb, но очень сильно об этом жалею :) И вот наиболее популярный формат хранения логов для анализа - ELK.

Можно подробнее?

google elasticsearch logstash kibana. Информации вагон на любом IT-ресурсе.

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

Рекомендую check_mk. Удобнее, чем Nagios (это надстройка под него).

Выглядит примерно так: http://i.imgur.com/YF3DchF.png

Все графики рисуются из коробки: http://i.imgur.com/6fLESJi.png

Настраивать очень просто.

Писать свои плагины тоже не сложно, если есть базовые знания python. Либо можно через mrpe.cfg лепить свои плагины, можно на чём угодно в этом случае.

Пример плагина для мониторинг состояния дисков на HP-UX, серверная часть: https://github.com/4815162342lost/check_mk_plugins_and_checks/blob/master/che...

Клиентская часть: https://github.com/4815162342lost/check_mk_plugins_and_checks/blob/master/hp_...

Чек на основе mrpe.cfg (клиент возвращает текст и код возврата, на серверной стороне ничего не надо делать): https://github.com/4815162342lost/check_mk_plugins_and_checks/blob/master/mrp...

Попроще: https://github.com/4815162342lost/check_mk_plugins_and_checks/blob/master/mrp...

Касаемо логов — есть плагин logwatch. Я с ним не работал, к сожалению, только анализировал исходник при решении проблемы одной, но смысл такой, что он запоминает смещение в файле и при след. сканировании ищет новые ошибки в log-файле (проверяет только новые записи в логе, поэтому сканирование идёт быстро).

Пример: http://i.imgur.com/4Fj6BaF.png

посмотреть какие процессы были активны

Можно мониторить жив ли конкретный процесс, но всю историю вроде как нельзя (хотя можно извратиться)

какие файлы были открыты.

боюсь, что это будет тоже проблематично, возможно, audit тебе поможет

Вообще, для сбора логов есть специализированные решения.

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

Спасибо. Но нам важнее всего именно логи, остальное — полезное дополнение.

https://github.com/4815162342lost/check_mk_plugins_and_checks/blob/master/hp_...

Ошибка 404.

Касаемо логов — есть плагин logwatch. Я с ним не работал, к сожалению, только анализировал исходник при решении проблемы одной, но смысл такой, что он запоминает смещение в файле и при след. сканировании ищет новые ошибки в log-файле (проверяет только новые записи в логе, поэтому сканирование идёт быстро).

А проверять появляющиеся в директории новые файлы он может?

возможно, audit тебе поможет

Это плагин, или другая программа?

Вообще, для сбора логов есть специализированные решения.

Смотрю предложенный выше ELK.

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

А проверять появляющиеся в директории новые файлы он может?

в теории можно, но это уже извращение полное будет, Nagios не для этого создаётся. Проще думаю скрипт написать на основе find самому

Это плагин, или другая программа?

Другая программа (сложноватая в настройке): https://blog.selectel.ru/audit-sistemnyx-sobytij-v-linux/

В общем, Nagios тебе не нужен, насколько я понял.

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

Nagios тебе не нужен, насколько я понял.

Правильнее сказать, «тебе нужен не Nagios» :)

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