Главная System Center, Без рубрики, Новое Мониторинг в корпоративной среде
  • Мониторинг в корпоративной среде

    Предисловие

    Эта статья является первой в цикле статей об Microsoft Operations Manager 2007 R2. Сколько в итоге получится таких статей, я не знаю. Всё будет зависеть от наличия свободного времени, интереса читателей и еще кучи факторов. В первой статье я вкратце опишу, что понимается под словом «мониторинг» когда речь заходит о средних и крупных ИТ-системах. Если же у вас уже есть понимаю, что вам необходима система мониторинга уровня OpsMgr – можете смело пропустить эту статью, не думаю что вы найдете здесь для себя что-то новое.

    Понятие мониторинга

    Мониторинг. Очень часто доводится слышать этот термин в сфере ИТ. Но самое интересное, что каждый понимает под этим словом что-то своё. Для кого-то это – проверить, жив ли сервер пингами, а для кого-то – понять, почему вдруг пользователи начали жаловаться на «тормоза» в корпоративном приложении. И все по-своему правы. И на каждом уровне развития ИТ-инфраструктуры используется свои методы и средства для наблюдения и оценки работы ИТ-инфраструктуры.

    Когда у вас 1-2 сервера вы вряд ли задумывается о мониторинге. Обычно сервера находятся «под боком», вы можете хоть каждый час проверять сами их состояние, и при возникновении проблем вы узнаете сразу. При этом каждый аспект работы этих серверов изучен, и вы знаете как реагировать на ту или иную проблему. При росте инфраструктуры, когда у вас уже 5-10 серверов, следить за всеми серверами «руками» не так удобно. Обычно на этом этапе начинается внедрение скриптов, различных автоматических «пинговалок» и «проверялок» вроде GoldenEye. Но вот когда число серверов переваливает за 20-30, и бизнес-приложения начинаются «размазываться» по нескольким серверам, такие средства оказываются не совсем к месту. Часто приходилось видеть ситуации, когда по данным скриптовых проверок и проверок состояний различных служб всё отлично (всё пингуется, все службы запущены), а пользователи всё равно жалуются – почта «не ходит», 1С тормозит, сайт не открывается. И тогда администратор начинает «разбор полетов». И вот тогда обычно возникает вопрос – «а что происходит там, внутри приложения? Какие ресурсы и компоненты задействованы?». Именно в этот момент происходит понимание, что необходимо в первую очередь мониторить бизнес-приложения в целом, а уже потом сервера и службы, которые их обслуживают. Все крупные вендоры, такие как Microsoft, IBM, CA, HP, предлагают свои продукты исходя именно из этого подхода. И именно поэтому вместо monitoring употребляется слово operations management, т.е. управление операциями (а продукты от HP и Microsoft используют это обозначение в своих продуктах).

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

    • Осуществлять проверку максимального числа компонентов бизнес-приложения на самом глубоком уровне.
    • Иметь средства аналитики для быстрого обнаружения проблемных мест в работе бизнес-приложения, в том числе агрегации и корреляции событий.
    • Уметь выполнять проактивный мониторинг, т.е. обнаруживать потенциальную проблему до начала её влияния на бизнес. Замечу, что для администратора эта возможность является одной из ключевых, т.к. не только позволяет избежать простой бизнеса, но и повышает его оценку в глазах руководителя.
    • Иметь возможность долгосрочного хранения информации об ИТ-инфраструктуре
    • Иметь возможность реагировать на процессы, вплоть до действий по восстановлению компонентов системы. Согласитесь, полезно, когда кто-то делает за тебя всю работу J
    • Должна реализовывать в базовом функционале основные принципы ITIL, т.к. эти рекомендации давно стали де-факто стандартном в ИТ индустрии
    • Иметь возможность ведения базы знаний

    Этот список явно дает понять, что разного рода «проверялки» уровня GoldenEye не могут выполнять ни одной из этих задач, а если могут, то с очень большими оговорками. Некоторые коллеги могут возразить, что все эти задачи можно реализовать и самому, при помощи скриптов и различных утилит. Да, можно. Но такой подход можно охарактеризовать как «а после нас – хоть потоп». Он имеет право на жизнь в статичной инфраструктуре, где ничего не меняется годами (да, есть и такое, один знакомый недавно хвастался, что у него uptime сервера составляет что-то около 500 дней), или где применяются крайне специфичные системы. Но таких предприятий крайне мало. Что же касается «обычных» компаний, то в них ИТ-инфраструктура, а в особенности бизнес-приложения, редко переживают год. Представьте ситуацию – вы, как администратор, разработали отличную систему мониторинга, написали два десятка скриптов по косточкам разбирающие все ваши бизнес-приложения, даже «прикрутили» ко всему этому интерфейс. Получили за это премию и уважение руководства. А через год уволились. Приходит новый админ, и что? Документации нет, как это работает, знает только один человек, и тот уехал в Израиль\Австралию\Бирюлево и его координат нет. Да, но она работает, вроде бы всё отлично? Но через 3 месяца происходит внедрение новой версии корпоративного приложения, и построенная система мониторинга просто перестает работать. Обычно в этом случае про старую систему забывают, и начинают строить новую J Коммерческие системы мониторинга позволяют стандартизовать подход к проверке систем, что дает массу преимуществ, таких как наличия документации к системе, поддержки вендора, наличия специалистов по данной системе на рынке труда.

    Итак, вы пришли к пониманию, что вам необходима коммерческая система мониторинга. Какую выбрать? Для меня ответ на этот вопрос на самом деле крайне прост – выбирайте систему того вендора, который максимально представлен в вашей инфраструктуре. Если у вас в сети большинство бизнес-приложений базируются на HPUX – выбирайте продукт от HP. Если у вас ядром системы являются решения от Oracle – выбирайте и мониторинг от Oracle. Если у вас бизнес-приложения завязаны на продукты Microsoft – выбирайте систему мониторинга от Microsoft. Ибо на сегодняшний день никто лучше не знает о продукте, чем вендор его создавший (с некоторыми оговорками и исключениями, конечно).

    Хуже дело обстоит, когда сеть гетерогенная, и в ней перемещались не только несколько вендоров, но и несколько платформ – часть бизнес-приложений построено на платформе Windows, часть на Unix. В этом случае выбор системы не очевиден, и ответа на вопрос «что выбрать» однозначно дать не возможно. Очень может быть, что систем мониторинга будет не одна, а несколько. В этом случае необходимо обратить внимание на то, сколько ваших компонентов в данных момент, и насколько глубоко, поддерживает та или иная система мониторинга, как она развивается и поддерживается другими вендорами, насколько просто её интегрировать с другими системами, в том числе системами ServiceDesk.

    Почему именно OpsMgr?

    Сразу оговорюсь – я не ставил себе задачу сравнить системы мониторинга. Моя задача – рассказать про OpsMgr. Но всё же эту вводную статью я хотел бы закончить некими тезисами, почему я выбрал OpsMgr в качестве своей специализации, и в чем, на мой взгляд, основные его преимущества на данный момент перед другими подобными продуктами:

    • Рынок Windows-based приложений на сегодняшний день огромен. И, как я уже говорил выше, никто не знает о своих системах лучше, чем создавший их вендор. Поэтому вполне логично, что система мониторинга от Microsoft является одним из основных кандидатом при выборе.
    • OpsMgr способен получать данные от практически всех распространенных систем и приложений, существующих на рынке. Существуют решения для мониторинга VMware, Oracle Database, SAP, сетевых устройств Cisco, Linux-систем, Unix-систем, аппаратных платформ HP, Dell, Intel ,EMC и т.д. Список этот огромен, и многие из этих решений созданы для OpsMgr самими вендорами, что означает глубину управлением системы и поддержку со стороны вендора. За достаточно короткое время, OpsMgr стал де-факто основной системой мониторинга на рынке бизнес-приложений.
    • Легкая интеграция с любыми внешними системами, в том числе двухсторонняя. Частое требование к системе мониторинга – передача событий в систему ServiceDesk\HelpDesk. OpsMgr «из коробки» имеет поддержку такой коммуникации, причем он способен не просто передать событие во внешнюю систему, но и поддерживать эту связь на протяжении всей жизни события и синхронизировать состояния события между системами.
    • Относительная простота разработки компонентов системы. С одной стороны, создать достаточно мощную систему мониторинга собственного приложения или бизнес-сервиса можно прямо из консоли OpsMgr, не прибегая ни к каким сторонним средствам разработки. С другой, вы можете использовать любые средства разработки в случаях, когда вам потребуется мониторинг какого-либо крайне специфичного бизнес-приложения.
    • OpsMgr позволяет выполнять мониторинг с точки зрения бизнес-пользователя. Он способен отслеживать соблюдение уровней SLA, строить карты распределенных бизнес-приложений и производить оценку влияния того или иного сбоя на это приложения согласно карте.

    Этот список далеко не полный, и я очень надеюсь, что вы сами сможете его дополнить после изучения System Center Operations Manager.

    Антон Гриценко ака FreemanRU

    opsmgr.ru

Комментарии

  1. С почином, Вас, Антон! И спасибо!

  2. Будем ждать продолжения, желательно с уровнем не менее 300 🙂

  3. По поводу уровня – всё будет постепенно.

  4. operation – это, скорее, эксплуатация. operations management – управление эксплуатацией (а не операциями)

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

  6. Спасибо Вам. Какая классная вводная статья!

  7. Продолжайте! Спасибо за статью