none
Поговорим о серверах-исключениях RRS feed

  • Вопрос

  • Други!

    Возникла несколько нестандартная задача. Хотя... по моему, вполне стандартная для пользователей МОМ 2005 Smile.

    Вопрос:

    Как средствами OpsMgr 2007 задать исключение серверов из списка мониториемых?

    Не вообще удалить из мониторинга, не поставить в режим "Maintenance Mode", а именно перевести в режим необслуживаемых (Unmanaged Computers)?

     

    Предвижу вопрос: а зачем?!

    Предположим, у вас есть набор тестовых серверов. О том, что они тестовые и их не надо мониторить знают далеко не все. Соответственно, один админ их будет засовывать в мониторинг (их же там нет!), а другой - упорно удалять (тестовым серверам там не место!).

    Как бы организовать так, чтобы OpsMgr "знал" об их существовании и "знал", что эту группу надо игнорировать?

    14 декабря 2007 г. 19:27

Все ответы

  • О том, что они тестовые и их не надо мониторить знают далеко не все. Соответственно, один админ их будет засовывать в мониторинг (их же там нет!), а другой - упорно удалять (тестовым серверам там не место!).

    Это, конечно, не моё дело... Но... И бардак же у Вас в организации... Управлением любым сервисом должна заниматься группа с единой информацией о сервисе. Я подчеркиваю - любым
    Потому решением проблемы будет дать в репу обоим администраторам: одному за то, что не поделился сокровеным знаниям о тестовости серверов, второму за то, что после третьего появления серверов в мониторинге он не озадачился и не провел раследование.
    Далее, для оптимизации мониторинга при проведении тестов (я не буду говорить о недопустимости смешивания тестовой и рабочей среды, ладно? Wink ) можно выделить эти самые тестовые сервера в отдельную группу и делать им отключение/включение мониторинга таким образом.
    15 декабря 2007 г. 14:39
  • Как сказано! Ух!!! Но все же Wink...

    Думаю, Вы правы, это действительно не Ваше дело: организация распределения прав и обязанностей в чужой организации Smile.

    ЛВС, в которой уже реализуется принцип неопределенности Гейзенберга (количество серверов, которые находится в данный момент времени в онлайн, известно с точностью до десятка; а за время выполнения LDAP-запроса оно гарантированно изменяется), в которой организована развитая система делегирования полномочий, которая живет в 10 часовых поясах, все же может позволить себе некоторые неочевидности .

     

    Не буду говорить, что приведенный мной случай - утрированный пример и имеет с реальностью очень мало общего. Про сертификацию сети на MOF, ITILv2, SOX, 900x тоже промолчу. Не буду вспоминать про "чужой монастырь" и т.п. народные мудрости. Даже не буду заострять внимание на неполиткорректном предложении физической расправы Smile. Не буду спрашивать: является ли, например, по мнению глубокоуважаемого оппонента сервер с именем AS-Q213-new8.domen.ru "тестовым"... Опустим мелочи!

     

    Вернемся к сути моего вопроса.

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

    Насколько я могу судить, такой способ потребует включения этой ОДНОЙ группы во ВСЕ остальные существующие и в будущем создаваемые группы в раздел исключений. Нет единого места, где можно было бы сказать: "эти сервера пропускать, их алармы - в топку!". Или все же есть? Собственно, это и было сутью моего вопроса.

     

    Поделитесь опытом!

    15 декабря 2007 г. 15:46
  • +1 к замечанию Александра. Особенно после прочтения твоего ответа. Бардак у вас несусветный, видимо. Что за сеть такая, если там нет ничего постоянного. Мрак. Тем более, если говоришь, что чтите всякие MOF-ы и ITIL-ы. Толи меня память подводит, толи еще чего, но кажется там в продакш ВООБЩЕ нельзя сервера вставлять без согласования со всеми службами.

     

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

    15 декабря 2007 г. 17:20
    Отвечающий
  • Туше!

    Друзья, у нас опять разговор уходит от темы.

    Зря я, наверное, привел тот пример и употребил слово "тест" . Хотел как лучше, а получилось как всегда...

    Наше обсуждение плавно перетекло с технической проблемы на процесс-менеджмент.

    Может хватит, а?

    Если хотите обсудить этот офф-топик - давайте перенесем это в другое место или вообще в оффлайн! Обещаю, отвечу в рамках своей компетенции на все вопосы подробно и аргументировано. Договорились?

     

    А сейчас давайте плясать от сути вопроса.

    Идеи по решению поставленной задачи есть? Или закрываем обсуждение как тупиковое?

    15 декабря 2007 г. 19:50
  • Вот я и говорю - бардак у Вас. Отсюда и проблемы, которых в нормальной сети просто не возникают. Но это, как всегда, имхо.
    По поводу Вашей проблемы - нужно, скорее, идти от противного - сделать группу серверов, которые не тестовые. И уведомления и алерты показывать только для нее. Это эдинственное, что я мог бы рекомендовать в данном случае, по крайней мере с ходу. А поддерживать сие богатство придется, естественно, вручную, по крайней мере, если не давать тестовым серверам отличное от нетестовых доменное имя.
    16 декабря 2007 г. 11:28
  •  Treemer написано:

    Туше!

    Друзья, у нас опять разговор уходит от темы.

    Зря я, наверное, привел тот пример и употребил слово "тест" . Хотел как лучше, а получилось как всегда...

    Наше обсуждение плавно перетекло с технической проблемы на процесс-менеджмент.


    О. Вы уже пришли к пониманию, что правильно заданный вопрос это 80% ответа? Действительно, как сформулировали, такое обсуждение и получили =)
    Переформулируйте так, чтобы стала ясна реальная задача - получите (может быть) реальный ответ Wink
    16 декабря 2007 г. 11:33
  •  Treemer написано:

    Как средствами OpsMgr 2007 задать исключение серверов из списка мониториемых?

    Не вообще удалить из мониторинга, не поставить в режим "Maintenance Mode", а именно перевести в режим необслуживаемых (Unmanaged Computers)?

     

    На мой взгляд режим "Maintenance Mode" как решает поставленную задачу "исключения" из мониторинга.

    17 декабря 2007 г. 11:34
    Модератор
  •  

    Интересно, а зачем вообще в МОМ 2005 ввели режим Unmanaged Computers?

    Судя по развернувшемуся обсуждению - ну абсолютно бесполезная группа Smile.

    17 декабря 2007 г. 16:34
  • unmanagmed, на сколько я помню - это лишь сервера, найенные в процессе поиска, но на которые не было установлено агента или они не были назначены на мониторинг без агента.

    Так как у тебя все-таки сервера попадают в обслуживаемые?

    17 декабря 2007 г. 17:07
    Отвечающий
  • Ок, придется всетаки выкладывать карты на стол...

    Как же мне не хотелось этими частностями отвлекать народ от поставленной задачи! Вот увидите, теперь обсуждение будет идти не вокруг "исключений", а вокруг "оррригинального решения"...

    Ну, да простят меня модераторы, я сделал что мог Smile.

     

    Уважаемый Фримен сделал не совсем корректное утверждение по unmanaged servers для МОМ 2005. Эта группа широко использовалась для гибкого управления всякими исключениями. Например, в нее было удобно "отложить" сервера, идущие под перезаливку или демонтаж, но для которых было полезно сохранить накопленную для отчетов статистику...

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

    В МОМ 2005 не было иного элементарного объекта мониторинга нежели сервер. Чтобы вывести в мониторинг Лотус понадобилось программно порождать виртуальные сервера типа "Лотус". А чтобы МОМ не стриг их под общую гребенку - выносить их в Анменеджи. Особыми методами их счетчики динамически транслировались на хост-машны, подменяя ряд "родных" перфкаунтеров. Вот так оно и работало, если вкратце и без технических подробностей.

    Механизм на самом деле оказался весьма универсальным, позволяющим точно так же "отражать" в МОМ данные от ряда других, специфических для нашего бизнеса, систем.

     

    Мой вопрос (см. далекое первое письмо) возник, когда остро встала задача реализовать скорейший перенос имеющихся наработок в новую систему. Конечно, разумнее и правильнее реализовать все то же заново, с использованием правил разработки МР для SCOM (на основе Entity), но вот быстрее ли? Да и денежку кто на это даст? Вот и ищем обходные пути.

    А вы кусаться... Эх...

     

    А по поводу "как попадают" - автоматически. Агент включен в стандартный образ заливки. Так что и тестовые иногда пробиваются. В МОМе, кстати, подозрительные на тестовость сервера помещались в карантин Анменеджа "до выяснения".

     

    Теперь мы можем перейти к решению заданного вопроса или понадобится еще что-то объяснять?

    17 декабря 2007 г. 22:39
  • Все понятно. Могу только сказать, что SCOM это другой продукт по отношению к MOM. Он имеет другую идеологию мониторинга. Поэтому перенос возможен только для стандартных MP, но все, что изобретено сверх того, вы не сможете перенести один в один. Как говорят в таких случаях: забудьте все что было раньше.

     

    С SCOM вам будет даже проще, потому что он позволяет мониторить "классы", т.е. именно те объекты, которые необходимы, а не сервер как таковой. Такой подход называется сервис-ориентированным. Более того поддерживается концепция распределенных сервисов, или приложений. Это позволяет легко разделить мониторинг железа, производительности и мониторинг бизнес процессов.

     

     

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

    18 декабря 2007 г. 4:22
    Модератор
  • Мдя. По моему уравнение с 5ю неизвестными, 6й степени, свелось к квадратному уравнению Smile

    Если я правильно понял, тебе надо мониторить часть функционала на сервере. Т.е. чтобы на данном ЖЕЛЕЗНОМ сервере мониторился только программный компонент. так вот в SCОМ для этого не надо делать исключений для всего сервера. Достаточно сделать overide стандартным правилам (или как написал sie), к тому же в вашем случае, как я понимаю, еще очень полезным будет написать свой distributed application, в которое включить только те компоненты, которые нужны вашей компании компоненты, и они будут мониторится как одно целое.

    18 декабря 2007 г. 8:13
    Отвечающий
  • >По моему уравнение с 5ю неизвестными, 6й степени, свелось к квадратному уравнению

    Было бы все так просто... только эти квадратные уравнения включены в жесткие дифуры как граничные условия.

     

    Коллеги, вы все говорите правильно, но только для случая, когда вся эта система строится "с нуля".

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

    Спасибо и за ликбез по теории МР-строения в SCOM Smile. Думаю, наши разработчики с удовольствием прочтут Ваши слова и, может быть, даже что-то найдут для себя новое... Боюсь, только, что они уже бредят цитатами из документации по этому замечательному продукту и нервно оглядываются на темные углы и шорохи Smile . Увы, более сырого сопровождения и среды разработки лично я давно не видел Sad.

    По словам Янушпольского, документацию обещают серьезно переработать в официальном SP1, ждем... И будем все перерабатывать...

     

    Что ж, думаю, на этом обсуждение можно закрывать. К сожалению, желаемого удовлетворительного ответа я так и не получил Sad.

    18 декабря 2007 г. 11:49
  • я бы Вашим разработчикам рекомендовал еще на authoringMP.com сходить.

    18 декабря 2007 г. 11:52
  •  

    Угу... чуть ли не homepage`м стоит.

    Только пока выход продукта меня не устраивает.

     

    Эх, найти бы приличный пошаговик по строительству дистрибьютед аппликейшена (мечтательно) с элементами SQL, скриптов и... (захлебнулся от желания). Видел подобный пошаговик по подключению к OpsMgr SNMP устройств на примере одной фирменной железки, да потерял ссылку. А то везде только ссылки на визард-билдеры, а они очень ограничены функционально...

     

    А пока даже на Авторинг-Консоль нельзя положиться - курочит код без предупреждения Sad

    Бета, одно слово.

     

    Но за совет - спасибо! В свое время этот сайт стал для меня откровением Smile.

    18 декабря 2007 г. 14:25
  • authoringMP.com

    Для статистики и потомков - authoringmpS.com

    18 декабря 2007 г. 19:49
    Отвечающий