Выбор системы мониторинга ресурсов

[Иван Левшин aka Ivan L.]

Он сильно платный, я смотрю только в сторону OSS. Нагиос так не умеет - он так же, как и исинга, работает по расписанию. Насколько мне известно, конечно. Речь идет о неком listener, который работает на стороне сервера мониторинга и обрабатывает соответствующим образом входящий на сервер поток. Ну т.е. события появляются тогда, когда клиент сообщает о них, а не тогда, когда у сервера руки дошли до проверки.

[Ковалев Артем]

Умеет, умеет. У него есть плагин для ловли snmp trap (так называется то, что вам нужно, когда "больной" сам сообщает, что у него что-то случилось).
Вот например инструкция http://askaralikhan.blogspot.ru/2010/12 ... agios.html

[Иван Левшин aka Ivan L.]

Неее, это не то SNMP - это прекрасно, мне нужно, чтобы, например, оперативно обрабатывался тот же syslog - как только там появились некие ключевые моменты, чтобы система реагировала. За инструкцию - спасибо, будем посмотреть.

[Иван Левшин aka Ivan L.]

Артем, как Вы решали проблему выполнения плугинов в нагиос, когда требуется выполнение в контексте рута? Например, check_edir_time - фактически выполняет ndsrepair -T, работает только от рута. Icinga работает от icinga/icinga - и, соответственно, выполнить ndsrepair не в состоянии. Попробовал добавить icinga в sudo - нет эффекта. Переписывать плугин не хочется.

[skoltogyan]

а скрипту, который будет запускать ndsrepair , судошный бит если поставить ?

[Иван Левшин aka Ivan L.]

Расшифруй? Я ж полностью деревянный в этих ваших линухах

[skoltogyan]

chmod u+s файл
установит на фале этот бит
при запуска на выполнение будет выполняться с UID владельца файла, а не UID пользовтаеля.
Если владелец root, то от рута и будет выполняться

chmod u-s файл
снять этот бит с фала

проверить стоит бит или нет
ls -la файл
будет чото типа
-rwsr-x-r-x- файл

"s" вместо "x" говорит о том, что установлен этот бит

[Ковалев Артем]

Артем, как Вы решали проблему выполнения плугинов в нагиос, когда требуется выполнение в контексте рута? Например, check_edir_time - фактически выполняет ndsrepair -T, работает только от рута. Icinga работает от icinga/icinga - и, соответственно, выполнить ndsrepair не в состоянии. Попробовал добавить icinga в sudo - нет эффекта. Переписывать плугин не хочется.

Я - несколько извращенно
Есть такой плагин - check_by_ssh
Вот ему можно указать, что на удаленную машину он входит как рут (-l root). А удаленной может быть и локальная машина

Но реально я с такими задачами не сталкивался, тот же check_edir_time можно заменить просто проверкой времени на всех серверах (check_ntp_time).

[Иван Левшин aka Ivan L.]

Нуууу.... Удаленный доступ прям к руту - сильно нефеншуйно (хотя понятно, что ровно так оно почти у всех и работает).

Набрел тут на интересную систему (судя по описанию): Heka. Обещают все на свете - включая и listener для внешних процессов, и output, который как-то что-то куда-то может энкодить.... Писано на Go. У этого хотя бы дока внятная Не как у исинги. Надо будет посмотреть.

P.S. А заменять ndrespair -T на проверку времени на серверах.... Это сильно, честное пионерское! Никогда не сталкивались с тем, что в системе-то с временем все нормально, а вот унутре eDirectory - совсем не нормально? Когда, например, по тем или иным причинам сервера просто теряют адреса друг друга. Я видел многократно - и прекрасно помню удивление админов: "ну ntpq-то нормально все кажет...."

P.P.S. Пора, видимо, менять тему топика. Если Heka хотя бы вполовину так прекрасна и настраивается хотя бы чуть лучше Icinga, Icinga пойдет в шлюзы.

[skoltogyan]

5 копеек - на хабре щупали
http://habrahabr.ru/post/250803/

[Ковалев Артем]

Нуууу.... Удаленный доступ прям к руту - сильно нефеншуйно (хотя понятно, что ровно так оно почти у всех и работает).

Набрел тут на интересную систему (судя по описанию): Heka. Обещают все на свете - включая и listener для внешних процессов, и output, который как-то что-то куда-то может энкодить.... Писано на Go. У этого хотя бы дока внятная Не как у исинги. Надо будет посмотреть.

P.S. А заменять ndrespair -T на проверку времени на серверах.... Это сильно, честное пионерское! Никогда не сталкивались с тем, что в системе-то с временем все нормально, а вот унутре eDirectory - совсем не нормально? Когда, например, по тем или иным причинам сервера просто теряют адреса друг друга. Я видел многократно - и прекрасно помню удивление админов: "ну ntpq-то нормально все кажет...."

P.P.S. Пора, видимо, менять тему топика. Если Heka хотя бы вполовину так прекрасна и настраивается хотя бы чуть лучше Icinga, Icinga пойдет в шлюзы.

Иван, вы знаете, доступ рута по ssh и ключу куда безопаснее, чем советанный выше suid-bit на скрипт! Скрипт, Карл!

Никогда не сталкивались с тем, что в системе-то с временем все нормально, а вот унутре eDirectory - совсем не нормально?
Ни разу такого не видел. Даже предположить, как оно так может стать, если время синхронизируется с мастером, не могу. Слаб в фантазии. Либо время с мастером синхронизировано и тогда "ntp всё нормально кажет", либо нет - и тогда и в edir, и в ОС есть проблема со временем.

[Иван Левшин aka Ivan L.]

В порядке оффтопика...

Артем,

1. Безусловно, я почитал за suid-бит и в курсе, чем оно чревато
2. Пикантность ситуации ровно в том, что ndsrepair -T показывает именно состояние eDirectory (ну т.е. "нормальное состояние ntp"!="время в eDirectory синхронизировано". Я уже привел Вам пример того, как именно это случается: один из серверов по тем или иным причинам "забывает" адреса остальных и привет. ntpq -p показывает, что все волшебно и замечательно, а в выводе ndsrepair -T синхронизации нет. Исправляется элементарно - в Advanced делаем Repair network address и все работает, но беда в том, что если Вы смотрите на синхронизацию ntp и полагаете, что и с eDirectory все отлично - я Вам сочувствую Или Вы думаете, что NDS/eDirectory Healthcheck писали идиоты и они не в курсе, что можно взять и проверить синхронизацию времени в ntp?

[Иван Левшин aka Ivan L.]

Апдейт.

Остановился на связке hekad+influxdb+grafana (соответственно: сборщик+time-series db+рисовалка всяческих вкусностей). Выглядит как замена того же Nagios - не хватает, конечно, кучи плугинов, которые есть у Nagios, но, с учетом того, что информация получается скриптами или бинарниками, их вывод можно обрабатывать той же Heka (использовать имеющийся функционал или расширять его за счет Extension).

Причины выбора:

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

Надеюсь, все понимают, что написанное - чистый субъективизм?