Для чего нужен мониторинг IT?
Чтобы администраторы узнавали о проблемах в инфраструктуре раньше пользователей. Это, по сути, комплекс быстрой диагностики, который дает своевременное оповещение о проблемах и точную информацию, где и что случилось конкретно.
Пример: в 15:05 возникает проблема с почтой. Благодаря системе мониторинга админ уже в 15:07 видит, что на сервере не стартовала конкретная служба Windows, из-за чего не поднялся Exchange, и юзеры не получат писем. Без мониторинга ему бы позвонил руководитель около 17:00 и спросил бы, где письмо от партнёра, которое тот уже три раза отправил полчаса назад.
Как это было раньше?
Раньше информация о всей инфраструктуре (серверах, сетевых устройствах и так далее) просто собиралась. Роль «интеллектуального обработчика» лежала на администраторе: он, как пилот в кабине самолёта, должен был окинуть все приборы взглядом, чтобы понять картину. Ясно, что так мог не каждый.
Сейчас всё более автоматизированно и немного сложнее с точки зрения системы. Статусы стараются тесно привязать к бизнес-серверам, чтобы не было информации о мониторинге «в вакууме».
Также добавился мониторинг от лица конечного пользователя, когда эмулируются действия юзера — это робот, который раз в определённый промежуток времени запускает специальный скрипт: как будто пользователь бегает по менюшкам, что-то нажимает — и если у робота что-то не получается сделать, значит, и у человека не выйдет.
Плюс сейчас используется конфигурационная база данных: информация об объектах мониторинга представлена, как набор конфигурационных единиц. Каждый сервер, каждое сетевое устройство — это некая единица, все это хранится в централизованной базе данных. Такое представление позволяет потом интегрировать систему мониторинга с сервис-деском, системой управления активами и расширять функционал дальше.
Виртуализация
Раньше вся инфраструктура была физическая, все серверы представляли собой отдельные железки, находились в стойке, их можно было приходить и щупать, пока админ не видит. Сейчас инфраструктура часто состоит из виртуальных машин, когда сервер физически один, но на нём, например, крутится с десяток виртуальных. Это требует ряда тонкостей в настройке, зато дает массу преимуществ. Например, для нас, как для разработчиков систем мониторинга, это явный плюс: можно разместить всё в виртуальной среде. Система мониторинга – это ПО, которое состоит из нескольких модулей. И раньше под каждый модуль нужен был отдельный сервер. Когда железок было несколько, заказчик мог сказать, что, мол, слишком много оборудования требуется под вашу систему. Сейчас можно делать эти сервера виртуальными, и размещать их на одном физическом сервере. Это, к тому же, серьёзно снижает стоимость хороших систем мониторинга.
Пример того, как это работает
Есть один пример из жизни (имена и лица изменены). Итак, стоит HP Operations. Юзеры, привыкшие меняться файлами через FTP, в какой-то момент обнаруживают, что файл выложить не получается. Ткнулся первый юзер: сервер его не пустил. Пользователь подумал, что сбой временный и переслал файл по почте. Потом ткнулась ещё пара человек, у них тоже ничего не получилось, и кто-то написал тикет в поддержку. Саппорт начал разбираться, в чем дело. С виду все было хорошо: сервер был работоспособен, и, тем не менее, не сервис был недоступен. Искать такую проблему «на горячую» (при том, что останавливать работу других сервисов нельзя) — задача, в принципе, стандартная, но очень муторная без системы мониторинга. Админ же просто заглянул в список событий мониторинга и увидел много алертов от файрволов. Причём множественные обращения фиксировались снаружи. Очень быстро обнаружилась (сюрприз!) DDoS-атака на этот FTP, которая и была отсечена. Думаю, без мониторинга поиск проблемы был бы часа на три-четыре дольше, что могло повлечь дальнейшие осложнения.
Автоматизация
Ещё системы мониторинга умеют автоматически выполнять сервисные действия. Например, характерная ситуация: на сервере кончается место из-за временных файлов, приложения начинают тормозить. Админ заходит, чистит временные файлы, уходит — всё тип-топ до следующего повтора. Мониторинг умеет определять момент, например, когда 90% диска заполнено, генерировать событие – и запускать очистку самостоятельно в автоматическом режиме.
Поскольку система мониторинга умеет интегрироваться с сервис-десками, она может автоматически создавать тикеты о проблемах. То есть ниндзя из саппорта могут тихо и внезапно решить проблему еще до момента первого звонка.
Как это внедрить у себя?
Можно сказать, что система мониторинга, как и любая другая система большого объема, штука достаточно сложная. Внедрение обычно делается поэтапно, вне зависимости от того, делает это заказчик своими силами или же с помощью интегратора.
Сначала определяются объекты мониторинга (сетевое оборудование, серверы, приложения и т.д.). Потом выбираются критичные показатели для каждого объекта. Если взять слишком много данных, админы утонут в потоке оповещений о превышении предельных показателей, а если слишком мало – могут пропустить что-то важное. После этого нужно определиться с архитектурой, выбрать продукт, решение, вендора. Дальше уже можно приступать к настройке. Иногда делается пилотная зона-макет, а потом уже этот макет расширяется на всю инфраструктуру.
Готовые продукты
Системы мониторинга ориентированы на заказчиков разного уровня. Большие, сложные и дорогие решения требуют огромных трудозатрат по их разворачиванию и внедрению, но для крупного бизнеса это стоит того. Есть варианты поменьше и попроще для среднего и малого бизнеса, они представляют из себя некую коробку, которую достаточно легко внедрить. Самое известное решение из недорогих — Microsoft SCOM. Есть ряд open-source вариантов, они вообще бесплатны и требуют только довольно кропотливой настройки.
Для какого размера компании система полезна?
Предел там, где системный администратор не справляется с объемом работы и уже не может контролировать каждый сервер. В маленьких компаниях смысла в использовании таких систем обычно нет (или же можно брать частичные решения), а в компаниях среднего размера и крупных более-менее серьёзная система мониторинга обязательно должна быть. Такие системы начали развивать лет 10 назад, и сейчас почти все крупные заказчики IT-услуг уже внедрили у себя что-то подобное.
Что ещё умеет мониторинг?
- Строить отчеты, например, по использованию ресурсов. Можно измерить загрузку процессора, памяти, жесткого диска и т.д. Администратор может увидеть, что какой-то сервер перегружен, значит, с него нужно снять часть задач, а другой — недогружен, и туда можно перенести часть сервисов. Это задача планирования мощностей и их рационального использования.
- Визуализировать проблемы. Есть некое представление ИТ-систем, например, большой экран с картой филиалов компании и индикаторами состояния систем в каждом из них. Или, например, большая карта приложений. У промышленных систем мониторинга есть возможность построения приборных панелей, где можно выводить на экран нужные индикаторы, рисовать карты и так далее. Соответственно, это дает наглядность: администратор не бегает по менюшкам, не выискивает нужную информацию, а смотрит на большой экран и видит всё и сразу. Такой инженерный интерфейс очень полезен на хайлоад-проектах или в особо ответственных отраслях бизнеса.
- Искать «бутылочные горлышки». Когда система в первый раз назовёт вам конкретный сломанный коммутатор, который надо пойти и заменить на работающий, вы поймёте, насколько круто иметь алгоритмы поиска проблем.
Мониторинг кода
Относительно недавно появился мониторинг на уровне кода. Это относится в основном к приложениям J2EE и .NET. Подобные модули могут определять задержки в системных вызовах, утечки памяти, задержки в выполнении SQL запросов, и так далее.
Обучение
Изначально системы требовали больших усилий для настройки пороговых значений (что считать аварийной ситуацией – когда диск заполняется на 90% или 95%?). Естественно, при большом количестве объектов мониторинга это было трудоёмкой задачей. Сейчас системы мониторинга умеют анализировать исторические данные, изучать поведение объектов и на основании этого строить так называемые «динамические пороги». То есть система мониторинга «обучается» и понимает, что является нормальным подведением объекта, а что говорит об аварии.
Что это поменяет для ИТ-отдела?
Администраторы смогут освободиться от рутинной работы и сконцентрироваться на более важных и интересных задачах. Они будут точно представлять, что происходит в системе на данный момент, т.е. инфраструктура будет прозрачна. Стиля работы, когда они вынуждены тушить пожары и постоянно чинить неисправности, не будет, можно будет обходить грабли заранее. Решение рутинных проблем можно будет автоматизировать. Конечно, непредвиденные аварии, все равно придется устранять «вручную», но это будет легче, так как будет точная диагностика.
Останется только читать Хабр и убеждать бухгалтерию, что если админ мало работает, то это невероятное счастье.