Pull to refresh

Comments 14

Когда в последний раз ковырял Icinga2, документация мне показалась не очень хорошей, как сейчас с этим дела обстоят?
По сравнению с Nagios, поправили конечно много разных косяков, но и подобавляли много разных штук.
В общем придется знатно поковыряться с этой системой мониторинга, те кто захочет ее использовать.
Сложно сказать, но я туда только для апи заглядывал, но когда у меня проблемы были мне один из разработчиков помог он постоянно на monitoring-portal.org тусуется и довольно быстро реагирует.

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

А какой в этом смысл, один раз надо будет всё равно конфигурацию писать и потом она также спокойно может лежать в файле.
Если вам охота меньше писать, то можно наделать шаблонов. К примеру для виндовс хостов, где будут всегда определённые сервисы. Тогда конфигурация сокращается до чего-то такого
object Host "WindowsServer" {
import "windowsHost"
}

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

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

Есть icings director, он как раз для этого, при этом настройки из бд, относительно мирно сосуществуют с настройками из конфиг файлов.

Есть смысл ставить icinga на windows хост? Не будет оно работать хуже/нестабильней чем linux вариант?
Я такого и не знаю даже, вроде как работает только под линуксом или вы не имеете ввиду icinga2 сервер?
Уже разобрался, в репозитории лежит клиент, просто не подписано что это клиент, потому немного запутался.

@de1m


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

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

Я там больше не работаю, поэтому могу сказат только по памяти.
У нас там было три отдела — веб, ms nav, системные администраторы на выезде.
То есть клиенты в основном были из других отделов. Сам мониторинг мы разделили на две части:
1. Только наблюдение и если клиент хочет, то мы за отдельные деньги решаем проблему. Так-же за это клиенту приходилось ежемесячно платить, немного.
2. Мы наблюдаем и сразу можем решать, клиент плотил фиксированную плату в месяц (довольно высокую, но дешевле, чем отдельный человек).
Когда я был, то клиентов было немного, в первом случае из-за неполного понимания зачем это надо, а во втором случае я думаю из-за цены. На второй вариант согласился тогда только один клиент и то, через пол года отказался.

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

У сторонних клиентов мы устанавливали всё сами, в основном у них был виндовс и я использовал ту програмку, что я описал выше (agen). В итоге установка одного сервера занимала где-то 10 минут и плюс ещё где-то час для настройки нового клиента — сделать пользователя в icinga и в otrs, написать емайл итд.

Я так-же установил otrs, для otrs есть модуль SystemMonitoring. Благодаря ему можно слать емейлы от мониторинга сразу в otrs и создавать тикет. Информация о тикете шлётся (автоматически) клиенту. Если это клиент из первого варианта, то ему можно позвонить и спросить хочет ли он, чтобы мы решили проблему. Когда проблема решена, то при закрытие тикета в мониторинг (автоматически через SystemMonitoring) пишется информация из otrs тикета.
Если в otrs правильно записывать время, которе понадобилось для решения проблемы, то в конце месяца из этого можно делать репорт, который можно использовать для оплаты. Я это делал через jasper report из otrs дб. Наверное можно и как-то по другому.
Sign up to leave a comment.

Articles