- PVSM.RU - https://www.pvsm.ru -
Чтобы администраторы узнавали о проблемах в инфраструктуре раньше пользователей. Это, по сути, комплекс быстрой диагностики, который дает своевременное оповещение о проблемах и точную информацию, где и что случилось конкретно.
Пример: в 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%?). Естественно, при большом количестве объектов мониторинга это было трудоёмкой задачей. Сейчас системы мониторинга умеют анализировать исторические данные, изучать поведение объектов и на основании этого строить так называемые «динамические пороги». То есть система мониторинга «обучается» и понимает, что является нормальным подведением объекта, а что говорит об аварии.
Администраторы смогут освободиться от рутинной работы и сконцентрироваться на более важных и интересных задачах. Они будут точно представлять, что происходит в системе на данный момент, т.е. инфраструктура будет прозрачна. Стиля работы, когда они вынуждены тушить пожары и постоянно чинить неисправности, не будет, можно будет обходить грабли заранее. Решение рутинных проблем можно будет автоматизировать. Конечно, непредвиденные аварии, все равно придется устранять «вручную», но это будет легче, так как будет точная диагностика.
Останется только читать Хабр и убеждать бухгалтерию, что если админ мало работает, то это невероятное счастье.
Автор: adovgan
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/it-infrastruktura/8648
Нажмите здесь для печати.