Главная System Center, Новое OpsMgr, SCOM, мониторинг
  • System Center Operations Manager 2007 — Пакеты управления

    В прошлых статьях я не раз упоминал пакеты управления (management pack, МП). Пришло время поговорить о них поподробнее, т.к. пакеты управления – один из ключевых элементов OpsMgr. МП — кирпичики, из которых складывается система. Без пакетов управления OpsMgr – голая программная оболочка. Именно из пакетов управления OpsMgr узнает, что и как ему надо выполнять, что и где отображать в интерфейсе и т.д. Фактически пакет управления – это модуль описания, содержащий правила построения системы и ссылки на библиотеки сборок.

  • Главная System Center, Новое OpsMgr, SCOM, мониторинг
    • System Center Operations Manager 2007 – Health Model

      Данная статья продолжает цикл статей о OpsMgr 2007 R2, и в этот раз речь пойдет о модели здоровья. Кроме описанного ранее моделирования служб, OpsMgr использует еще одну модель – модель «здоровья» (Health Model). Каждый объект в системе OpsMgr имеет показатель «здоровья». Здоровье объекта определяется шестью состояниями: здоров (healthy ), предупреждение (warning ), критический (critical ), не проверяется (unmonitored ), в режиме обслуживания (Maintenance mode ) и «недоступен» ().

    • Главная System Center, Новое OpsMgr, SCOM, мониторинг
      • System Center Operations Manager 2007 R2 — Service Modeling

        В предыдущей части мы рассмотрели компоненты, из которых состоит система, построенная на OpsMgr 2007 R2. Теперь речь пойдет о том, как же работает OpsMgr «изнутри».

        OpsMgr реализует концепцию управления на основе моделей (model-based management). Любую систему можно разложить на службы (services), в свою очередь, любую службу можно представить в виде некой модели. Использование моделирования позволяет легко описать любую службу или процесс, при этом абстрагировавшись от реального аппаратного и программного обеспечения. Для примера моделирования и его крайней полезности в деле мониторинга, можно привести массу примеров. Например, возьмем терминальные службы: их разворачивают в компаниях с числом серверов от одного до нескольких тысяч. В рамках классического объектного мониторинга в каждом случае пришлось бы строить систему «по месту» — вносить в систему мониторинга каждый сервер, каждый сервис на этом сервере, строить некие правила проверки и так далее. При использовании моделирования мы можем создать некую абстракцию, создать для неё правила проверки и признаки, по которым мы можем отличить терминальные службы от прочих – и тогда всё равно, сколько серверов и компонентов в нашей системе, все они будут проверяться по единой модели и единым правилам.

      • Главная System Center, Новое OpsMgr, SCOM, мониторинг
        • System Center Operations Manager — Компоненты OpsMgr R2

          В предыдущей статье я вкратце описал класс систем мониторинга, к которым относится System Center Operations Manager. Данная статья будет первой технической статьей, и в ней я опишу компоненты, составляющие систему, построенную на OpsMgr.

        • Главная System Center, Новое OpsMgr, SCOM, мониторинг
          • Мониторинг в корпоративной среде

            Предисловие

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

          • Главная Storages, Windows, Новое Storages, мониторинг
            • ИОПСы и как их измерить

              db_status Зачастую камнем преткновения в анализе производительности системы хранения является замер текущей производительности дисковой подсистемы в IOPS. Без таких данных очень сложно, а порой и невозможно спроектировать адекватную систему хранения для имеющихся данных. Ошибка в оценке необходимого уровня производительности может напрямую исчисляться в тысячах долларов, ушедших в «молоко» при создании системы с «перелетом», и не меньших тысячах долларов потраченных на систему, не выполняющую своих задач в случае «недолета».