Nagios, Zabbix, Cacti

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

Вот только «админ zabbix» звучит как «программист 1С». Для тех, кто в теме

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

только вот программист 1С получает 80 шт валяя дурака, и я знаю 5 бывших админов ушедших по этой причине в программисты 1С.

Zabbix посложнее и помощнее, nagios попроще и легче, cacti первый раз слышу

Предлагаю туда же где стоит Nagios, Zabbix, Cacti добавить такую штуку https://www.icinga.com/

В zabbix'е большего всего напрягает разрастание таблиц в БД.
Сейчас я обхожу эту проблему partition'гом, но при очередной итерации, мне приходит 100500 уведомлений о сработанных тригерах.

В zabbix это добавляется через одно место, поэтому я даже не буду писать как я это делал.

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

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

В zabbix'е тоже есть карты.

вызов принят

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

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

Как ты их собрался мониторить из не_zabbix?

switch.cfg , группа хостов и общие сервисы. Нагиос нормально почему то их мониторит, и сразу говорит об их ошибках, патере пакетов, что часто говорит о скором выходе из строя, а заббикс у меня плевал на них, а вот циски нормально заббикс мониторит.

switch.cfg , группа хостов и общие сервисы. Нагиос нормально почему то их мониторит, и сразу говорит об их ошибках, патере пакетов, что часто говорит о скором выходе из строя, а заббикс у меня плевал на них, а вот циски нормально заббикс мониторит.

Не понял. Каким образом nagios забирает данные со свитча? snmp?

MRTG+snmp .

Одной проверки - да. Мне гораздо интереснее, как добавить список процессов. Например, есть штук дцать серверов, на которых запущено по 1..5 инстансов оракл.

Мониторинг нескольких однотипных item'ов через универсальный шаблон

В результате в macros на уровне хоста перечислял список инстансов. Скрипт для discovery получал на вход этот макрос, и возвращал тот же самый список, но в zabbix'овом json. По которому из прототипов автоматически клепались item'ы и trigger'ы

                <discovery_rule>
[...]
                    <key>fake_discovery.pl[{$ORACLE_SIDS}]</key>
[...]
                    <item_prototypes>
                        <item_prototype>
[...]
                            <name>pmon count for &quot;{#ENTITY}&quot;</name>
[...]
                            <key>proc.num[ora_pmon_{#ENTITY}]</key>
[...]
                    <trigger_prototypes>
                        <trigger_prototype>
[...]
                            <expression>{Template DB Oracle simple:proc.num[ora_smon_{#ENTITY}].last(#1)}#1</expression>
                            <name>smon count for &quot;{#ENTITY}&quot; is not 1</name>

fake_discovery.pl: http://pastebin.com/8inE5k3z

В zabbix'е тоже есть карты.

Только делать их нужно опять же самостоятельно, либо извращаться через не самый логичный zabbix api.

Пределом моего велосипедостроения стал скрипт, поторый обновлял screen с IOPS'ами рейдгрупп массива. В средней колонке IOPS'ы одной конкретной рейдгруппы, в левой - IOPS'ы физических дисков, в правой - IOPS'ы логических томов.

Примерно в это время я окончательно понял что [не люблю] zabbix, поэтому так и не дописал автоматику ( чтобы скрипт мониторинга писал item с сериализованной структурой дисков, а на стороне сервера скрипт по этой структуре автоматически обновлял screen ).

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

Твоя судьба - допиливать шаблоны zabbix.

В zabbix, после ненадёжности его мониторинга, мне больше всего выносила мозг такая его особенность. Если ты внёс изменения в шаблон, особенно в discovery, совсем не факт что эти изменения автоматически придут на хосты, привязанные к шаблону. Часто требовалось отрывать хост от шаблона с удалением всех данных ( теряя статистику, которая необходима ), заново привязывать шаблон, и только потом изменения придут на хост.

а в чём проблема держать 2 системы мониторинга?

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

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

Причем, я уверен, что заббикс все это может, но реализация для меня - темный лес. По капле в час, пока не узнаешь - что будет, если...

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

Все что Вы желаете zabbix может, но его этому надо научить!

Только делать их нужно опять же самостоятельно, либо извращаться через не самый логичный zabbix api.

Согласен.
Автоматическое построение карты - это было бы очень круто.