Я вцелом говорю, о системном мониторинге — когда много данных различного порядка (не только температуры).
Это проще, когда есть четко-определенные отделы, которые сами для себя определяют пороги алертов. Когда людей не сотни, и обязанности перекликаются между друг другом возникает сложность в том, кто должен получить алерт и о чем, а также какой порог срабатывания.
Если конкретно — сейчас вот, например, прошивка на RAID контроллере устарела по мнению контроллера, как расценивать эту ошибку?
Для меня мониторинг — это не только настройка самого мониторинга, но и глубокий анализ деятельности админов/девелоперов/бизнес-отдела, для того чтобы их жизнь была не алертовым адом (и, как результат, фильтрами всех писем от zabbix/nagios в папку «alerts»), а реальной системой, когда смс/email от сервера мониторинга означает «Нужно бежать и чинить».
Спасибо за статью, очень здорово! Особенно понравилось как Вы «бочку» использовали в качестве корпуса :)
У нас теперь другая проблема — определить порог «важности» алертов. Просыпаться просто так никому не хочется, но и не знать что происходит — тоже не вариант.
Эх, вот бы это облако было распределенным через p2p, тогда бы и я стал его частью, а так — буду довольствоваться «чуть более энергонеэкономичным» домашним сервером…
Я всегда мечтал работать на медленном в плане железа ноуте, который выглядит приятно, но в то же не ощущать тормозов аппаратной части.
Ксати, интересно, не нарушает ли это гарантии Google?
Да, Вы правы, SCCM 2012 начиная с SP1 поддерживает в качестве клиентской операционной системы Linux. Но, к сожалению, это не меняет того, что это прекрасное (и, кстати, не очень дорогое) программное обеспечение — закрытое, и многие (если не все) *nix компании предпочтут использовать альтернативные открытие технологии, не говоря уже об «религиозном» отказе ставить «Винду» :)
Это проще, когда есть четко-определенные отделы, которые сами для себя определяют пороги алертов. Когда людей не сотни, и обязанности перекликаются между друг другом возникает сложность в том, кто должен получить алерт и о чем, а также какой порог срабатывания.
Если конкретно — сейчас вот, например, прошивка на RAID контроллере устарела по мнению контроллера, как расценивать эту ошибку?
Для меня мониторинг — это не только настройка самого мониторинга, но и глубокий анализ деятельности админов/девелоперов/бизнес-отдела, для того чтобы их жизнь была не алертовым адом (и, как результат, фильтрами всех писем от zabbix/nagios в папку «alerts»), а реальной системой, когда смс/email от сервера мониторинга означает «Нужно бежать и чинить».
Спасибо за статью, очень здорово! Особенно понравилось как Вы «бочку» использовали в качестве корпуса :)
Ксати, интересно, не нарушает ли это гарантии Google?
Выглядит весело!
Если позволите, привнесу свою лепту в эту прекрасную тему:
Управление правами доступа к WMI через Puppet
Puppet + Opsview: автоматический мониторинг на основе шаблонов