none
SCOM 2012. Время работы переопределения RRS feed

  • Вопрос

  • Доброго врмени суток, коллеги!

    Имею инфраструктуру SCOM 2012.

    Инфраструктура что-то там мониторит.

    Хочу для части мониторов/правил написать переопределения с привязкой ко временным окнам.

    Например. Есть SQL сервер. Днём он работает на людей, а ночью занимается обслуживанием баз.

    И вот я хочу, чтобы монитор  SQL 2008 DB Average Wait Time днём срабатывал на, скажем, значение 250 (дефолтное), а ночью - на 10000.

    У кого какие мысли?

    30 октября 2013 г. 6:33

Ответы

  • По поводу фильтра времени работы мониторов. Правильно я понял, что речь идёт про мониторы, котрые я создаю самостоятельно? При этом эти мониторы должны основываться на скрипте, уже в котором я должен как-то предусмотреть работу с оверрайдами по времени? Или я что-то упустил и имеются какие-то стандартные (читать - гуёвые) средства, позволяющие определять время работы монитора/правила?

    А как быть с мониторами в MP, которые разрабатываются не мной? Например с тем же SQL 2008 DB Average Wait Time?

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

    Наверно можно написать собственный MP, в котором делать такие переопределения скриптами. Но это не вариант совершенно.


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

    Vladimir Zelenov | http://systemcenter4all.wordpress.com

    • Помечено в качестве ответа cryman 1 ноября 2013 г. 7:23
    1 ноября 2013 г. 6:36
    Отвечающий

Все ответы

  • Доброго врмени суток, коллеги!

    Имею инфраструктуру SCOM 2012.

    Инфраструктура что-то там мониторит.

    Хочу для части мониторов/правил написать переопределения с привязкой ко временным окнам.

    Например. Есть SQL сервер. Днём он работает на людей, а ночью занимается обслуживанием баз.

    И вот я хочу, чтобы монитор  SQL 2008 DB Average Wait Time днём срабатывал на, скажем, значение 250 (дефолтное), а ночью - на 10000.

    У кого какие мысли?


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

    Vladimir Zelenov | http://systemcenter4all.wordpress.com

    31 октября 2013 г. 16:18
    Отвечающий
  • По поводу фильтра времени работы мониторов. Правильно я понял, что речь идёт про мониторы, котрые я создаю самостоятельно? При этом эти мониторы должны основываться на скрипте, уже в котором я должен как-то предусмотреть работу с оверрайдами по времени? Или я что-то упустил и имеются какие-то стандартные (читать - гуёвые) средства, позволяющие определять время работы монитора/правила?

    А как быть с мониторами в MP, которые разрабатываются не мной? Например с тем же SQL 2008 DB Average Wait Time?

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

    Наверно можно написать собственный MP, в котором делать такие переопределения скриптами. Но это не вариант совершенно.

    1 ноября 2013 г. 5:03
  • По поводу фильтра времени работы мониторов. Правильно я понял, что речь идёт про мониторы, котрые я создаю самостоятельно? При этом эти мониторы должны основываться на скрипте, уже в котором я должен как-то предусмотреть работу с оверрайдами по времени? Или я что-то упустил и имеются какие-то стандартные (читать - гуёвые) средства, позволяющие определять время работы монитора/правила?

    А как быть с мониторами в MP, которые разрабатываются не мной? Например с тем же SQL 2008 DB Average Wait Time?

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

    Наверно можно написать собственный MP, в котором делать такие переопределения скриптами. Но это не вариант совершенно.


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

    Vladimir Zelenov | http://systemcenter4all.wordpress.com

    • Помечено в качестве ответа cryman 1 ноября 2013 г. 7:23
    1 ноября 2013 г. 6:36
    Отвечающий
  • Нестандартный?

    Гммм... чтож нестандартного в потребности мониторить объекты по критериям, которые есть функция от времени?

    Регулярные процедуры обслуживания тех же БД, полагаю, используются в подавляющем большинстве компаний. И, очевидно, что желание мониторить это хозяйство во время выполнения таких процедур является так же вполне естественным. При этом, скажем, время отклика приложения в рабочие часы свыше одной секунды является недопустимым, то в период обслуживания вполне так может быть и десять.

    Или более сложная конфигурация. Массив TMG, пишущий логи на внешний SQL. Раз в неделю идет удаление старых логов. Процедура не быстрая, и сервера TMG по таймауту отваливаются. Ибо SQL не Enterprise. В моём понимании это штатное поведение. А вот сказать SCOM, что "ты мониторь эту базу всю неделю, а вот по воскресеньям с 3 до 5 ночи не обращай внимания, что она отваливаться может" - увы. Только разработкой не сильно очевидных и прозрачных MP. Причем со всеми вытекающими . И вот это мне странно.

    1 ноября 2013 г. 7:38
  • Нестандартный?

    Гммм... чтож нестандартного в потребности мониторить объекты по критериям, которые есть функция от времени?

    Регулярные процедуры обслуживания тех же БД, полагаю, используются в подавляющем большинстве компаний. И, очевидно, что желание мониторить это хозяйство во время выполнения таких процедур является так же вполне естественным. При этом, скажем, время отклика приложения в рабочие часы свыше одной секунды является недопустимым, то в период обслуживания вполне так может быть и десять.

    Или более сложная конфигурация. Массив TMG, пишущий логи на внешний SQL. Раз в неделю идет удаление старых логов. Процедура не быстрая, и сервера TMG по таймауту отваливаются. Ибо SQL не Enterprise. В моём понимании это штатное поведение. А вот сказать SCOM, что "ты мониторь эту базу всю неделю, а вот по воскресеньям с 3 до 5 ночи не обращай внимания, что она отваливаться может" - увы. Только разработкой не сильно очевидных и прозрачных MP. Причем со всеми вытекающими . И вот это мне странно.


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

    Vladimir Zelenov | http://systemcenter4all.wordpress.com

    1 ноября 2013 г. 12:22
    Отвечающий
  • В режиме обслуживания фактически мониторинг отключается.

    А мне необходимо, чтобы он продолжался но с другими порогами.

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

    1 ноября 2013 г. 13:12
  • Есть множество способов, позволяющих автоматизировать режим Maintenance Mode, начиная от скриптов или даже менеджмент паков, заканчивая Orchestrator'ом.

    Vladimir Zelenov | http://systemcenter4all.wordpress.com

    2 ноября 2013 г. 20:23
    Отвечающий