Комментарии 10
в 15:05 возникает проблема с почтой. Благодаря системе мониторинга админ уже в 15:07 видит, что на сервере не стартовала конкретная служба Windows, из-за чего не поднялся Exchange, и юзеры не получат писем.
ИМХО пример не самый лучший.
Должно быть так. В 15:05:10 служба перестала отзываться по одному из портов. В 15:05:20 аппаратный балансировщик не дождался третьего кипалайва и положил rserver, уведя всех пользователей на другой CAS. 99% пользователей даже не заметили, что что-то произошло, а 1% удивился надписи «попытка подключения», которая пропала через несколько секунд.
(я описываю реальную историю — у нас такое было, причем почтовый администратор проглядел алерт и лишь спустя час обратил внимание в конфигурилке балансировщика, что один из серверов помечен как «down»; сервис не пострадал.
Но да, необходимость как SNMP-, так и более продвинутых мониторилок абсолютна и несомненна. Просто надобно не просто «отслеживать», а автоматизировать восстановление сервиса при обнаружении мониторилкой аварии. Балансировщик — классика.
Да, Вы правы. В большинстве случаев примерно так и происходит, но это просто пример, иллюстрирующий работу мониторинга. Упасть мог и другой сервис, как это, например, описано во втором, уже реальном, примере. Там бы автоматика не помогла: мониторинг — это огромная помощь системному администратору, но не замена опыта и умений.
То, что вы описываете прекрасно, но это не мониторинг о котором в статье, а некие failsafe кластера.
К сожалению нестандартных ситуаций и компонентов в рабочих цепочках очень много, и нужен именно мониторинг.
Ситуация с админом отреагировавшим за 2 мин видится мне несколько утопичной. Или у нас специалист на работе ничем не занимается а до рези в глазах смотрит на индикаторы, а за индикаторами наблюдает дежурная смена, которой надо 5-10 мин в рабочее время или 20-30 мин в нерабочее на то чтобы поднять админа, тому 10-20 мин чтобы запустить необходимые консоли и найти проблему, и 5 мин на устранение/воркэраунд. Т.е. 1 час — это хорошо, мы ведь говорим о нестандартных проблемах, которых не погасили кластера и т.п.
К сожалению нестандартных ситуаций и компонентов в рабочих цепочках очень много, и нужен именно мониторинг.
Ситуация с админом отреагировавшим за 2 мин видится мне несколько утопичной. Или у нас специалист на работе ничем не занимается а до рези в глазах смотрит на индикаторы, а за индикаторами наблюдает дежурная смена, которой надо 5-10 мин в рабочее время или 20-30 мин в нерабочее на то чтобы поднять админа, тому 10-20 мин чтобы запустить необходимые консоли и найти проблему, и 5 мин на устранение/воркэраунд. Т.е. 1 час — это хорошо, мы ведь говорим о нестандартных проблемах, которых не погасили кластера и т.п.
То, что вы описываете прекрасно, но это не мониторинг о котором в статье, а некие failsafe кластера.
Скорее «мониторинг на стероидах». Ведь отслеживание доступности ресурса — главное, что нужно настроить там. У меня Exchange кипалайвится четырьмя разными способами, и тишина в ответ на любой из них выльется в исключение сервера из балансировки и переназначение пользователей.
Практически любую систему можно кластеризовать на подобном уровне. От нее требуется лишь уметь одинаково обслуживать запросы, прилетающие к любому из фронтендов. Репликация сессий желательна, но абсолютно не обязательна.
Да, железные балансеры стоят не две копейки, но для небольших инфраструктур сгодятся и софтовые с теми же возможностями. Наверняка и опенсорс есть.
Ситуация с админом отреагировавшим за 2 мин видится мне несколько утопичной.
Ну например дежурный заметил отвалившуюся почту и прилетевший следом алерт, и набрал администратору (в рабочее время). Такое бывает. Но да, редко.
Повторюсь, мозг администратора — главное. Мониторинг — просто современный и удобный инструмент. Очевидно, лучше с ним, чем без него.
Наличие мозга у администратора само собой разумеется. И этот мозг требуется в том числе чтобы наладить и мониторинг, и автоматическую реакцию инфраструктуры на аварию. Если администратор узнает об аварии от конечных пользователей, то он — паршивый специалист. Если что-то сломалось, но пользователи об этом не узнали — он хороший специалист и обеспечил грамотное резервирование системы.
Один час простоя критической инфраструктуры — это абсолютно кошмарно. Время реакции в 55 минут (неважно, в дневное или ночное время) даже хуже.
Знаю я один банк, где ночная смена настолько боевая, что даже у поддерживающих критические системы администраторов нет VPN доступа в сеть. Вот это я понимаю…
Один час простоя критической инфраструктуры — это абсолютно кошмарно. Время реакции в 55 минут (неважно, в дневное или ночное время) даже хуже.
Знаю я один банк, где ночная смена настолько боевая, что даже у поддерживающих критические системы администраторов нет VPN доступа в сеть. Вот это я понимаю…
Самое известное решение из недорогих — Microsoft SCOM. Есть ряд open-source вариантов, они вообще бесплатны и требуют только довольно кропотливой настройки.
Хм, про open-source крайне не согласен. Есть много замечательных продуктов которые из коробки работают просто отлично, а настройка задокументирована от и до. По документации есть замечательный пример — Zabbix. А для не осиливших его установку настройку есть недорогая платная поддержка и обучение и много всего. Не будем забывать про nagios с вагоном плагинов, фронтэндов и прочих плюшек. Cati, OpenNMS и много много всего разного. Но долгая кропотливая настройка, это не верно. Все довольно просто и легко, самое главное понимать и осознавать, что необходимо получить от системы.
А то что Microsoft SCOM самое известное совсем не согласен, я например только от вас узнал об этом продукте, но я не идеал, на меня равняться не стоит.
Вы изобрели нагиос?
Автоматизация, классический пример как делать нельзя, если есть проблема с бесполезными временными файлами, то ее надо лечить, а не мониторингом костыли городить.
«Как это работает» — тоже из разряда выдуманных. При чем тут «на горячую», если фтп жив? Первое подозрение в такой ситуации у любого админа — файер. И вообще, если уж строить мониторинг, то ддос, кмк, случай критичный, и как минимум на него надо было реагировать, а не ждать обращений от пользователей.
И в конце снова, «решение рутинных проблем». Это значит повторяющихся?
Как то несерьезно.
PS: И да, тоже первый раз читаю про мониторинг от MS.
«Как это работает» — тоже из разряда выдуманных. При чем тут «на горячую», если фтп жив? Первое подозрение в такой ситуации у любого админа — файер. И вообще, если уж строить мониторинг, то ддос, кмк, случай критичный, и как минимум на него надо было реагировать, а не ждать обращений от пользователей.
И в конце снова, «решение рутинных проблем». Это значит повторяющихся?
Как то несерьезно.
PS: И да, тоже первый раз читаю про мониторинг от MS.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое мониторинг в IT или почему админы стали больше спать?