для чего в основном служат данные мониторинга
Мониторинг на основе данных
При работе над облачными сервисами Webzilla мы уделяем очень большое внимание системе мониторинга. Мы уверены, что только имея корректно работающий и надежный мониторинг, мы можем оказывать сервис на требуемом клиентами уровне качества. Во время работы над первым из облачных продуктов компании – облачным хранилищем Webzilla Instant Files – мы приступили к построению системы мониторинга еще до того, как начали строить сам продукт, продумали мониторинг для каждой функции еще на этапе её планирования.
Система сбора и анализа эксплуатационных данных
Обычно, когда говорят «мониторинг», под этим словом понимают событийный мониторинг ( ** PROBLEM Host Alert: server01 is DOWN ** ). Краеугольный же камень нашего мониторинга — непрерывная работа с операционными данными. Состояние всех находящихся под наблюдением систем описывается показателями, меняющимися в течение всего наблюдения.
В простейшем случае — если выключился сервер (скажем, из-за отключения питания) — эти данные имеют простую форму: доступно на 1 сервер меньше, чем мы ожидали. Если же ситуация более сложная: например, по каким-то причинам приложение постепенно деградировало и стало медленнее отвечать на запросы, измерения могут показать, например, что «95-й перцентиль времени ответа удвоился за последнюю неделю». При этом, какого-то конкретного момента времени, когда система «сломалась» не существует. Лягушка не может назвать точный момент времени, когда вокруг нее образовался кипяток.
Иными словами, привычные события переформулировать на языке данных чаще всего нетрудно, но данные имеют и самостоятельную дополнительную ценность. Мы решили строить мониторинг с ориентацией на данные.
Сначала мы собираем данные. Потом — принимаем решения.
Конфигурирование такой системы осуществляется довольно просто.
Конфигурирование Ganglia
Членство в кластере определяется в конфигурационном файле демона мониторинга gmond.conf
Все узлы кластера должны в конфигурации демона мониторинга иметь строчки, разрешающее рассылать мультикастом данные:
и принимать данные от других узлов
Кроме того, нужно разрешить мета-демону совершать опрос:
Сам мета-демон посредством его конфигурационного файла gmetad.conf должен быть настроен так, чтобы он обходил по очереди все узлы:
Описанная выше конфигурация изображается следующей схемой:
Демоны мониторинга Ganglia обмениваются данными друг с другом. Мета-демон опрашивает один демон мониторинга из кластера. При его недоступности, он обращается к следующему — и так далее. Веб-фронтенд получает XML от демона мониторинга и отображает его в понимаемой человеком форме.
Практическое применение
Если вам интересно увидеть, как выглядит веб-фронтенд Ganglia, это можно сделать на открытом фронтенде Wikipedia. Мы используем тот же интерфейс, устанавливаемый по умолчанию. Он выглядит недружественным, но подружиться с ним недолго. Кроме того, он имеет весьма приличную мобильную версию, которая радует менеджера. Возможность компульсивно следить за работой системы, находясь где угодно и в любое время — бесценна.
Система сбора и анализа логов
Нельзя пройти мимо проекта с таким милым логотипом
Мы настроили Logstash как rsyslog-сервер. Благодаря этому Logstash может собирать логи с любого софта, способного писать в syslog.
Иметь просто систему сбора логов мало. Мы хотим получать от этого выгоду. Централизованое хранилище логов несет сразу несколько плюсов.
Индексирование и поиск
Когда количество серверов измеряется десятками, не говоря уже про сотни, удобство работы с логами имеет значение. У этого удобства есть два аспекта: гибкость и простота использования.
Logstash может использоваться совместно с ПО, которое обеспечивает эти возможности — Elasticsearch и Kibana.
Elasticsearch — это система поиска, снабженная REST API, построенная на основе Apache Lucene. Наличие API делает систему гибкой.
Kibana — это веб-фронтенд, способный работать поверх Elasticsearch. Он отвечает за простоту использования. Работу Kibana можно оценить по демонстрационной странице
Событийный мониторинг
Когда кто-то строит систему мониторинга, она может не иметь системы сбора логов или эксплуатационных данных (хотя это и неправильно). Но она точно имеет событийный мониторинг — собственно говоря, поиск по «Хабрахабру» говорит нам о том, что обсуждая мониторинг, люди имеют в виду прежде всего именно его событийную составляющую.
Событийный мониторинг важен потому, что он предоставляет главные интерфейсы для взаимодействия операторов поддержки с системой. Он служит для них приборной панелью и отсылает уведомления.
В качестве системы событийного мониторинга мы выбрали Shinken. Это Nagios-подобная система мониторинга, но не форк Nagios. Shinken был переписан полностью с нуля, сохранив при этом совместимость с плагинами для Nagios.
С точки зрения же масштабируемости и надежности Shinken дает интересные возможности.
Масштабирование и обеспечение отказоустойчивости
Каждый из этих демонов может запускаться совершенно независимо от остальных. Кроме того, можно запускать столько демонов, сколько нужно (за исключением арбитра).
Обеспечение резервирования арбитров довольно несложно. Каждый демон может иметь запасной (spare) экземпляр. За это отвечает параметр конфигурации ‘spare’. При определении основного арбитра он устанавливается равным нулю,
а при конфигурировании запасного — единице
Когда главный арбитр отказывает, запасной принимает на себя управление. Если арбитры сконфигурированы идентично (а это — единственный правильный способ их настраивать), потеря связности между ними ничем не угрожает. Запасной сделает все то же, что и основной, и не нанесет вреда.
Описание событийного мониторинга было бы неполным, не упомяни мы о событиях, которые мы отслеживаем. Многие из них довольно специфичны (и поэтому малоинтересны большинству читателей), другие — очень общие (и поэтому хорошо описаны в десятке других мест). Однако, пара из них тесно связаны со всей описанной выше системой и потому представляют интерес.
Немного о проверках
«Живость» хоста
Можно придумать много определений «живого» хоста. Некоторые полагают, что живым можно считать хост, отвечающий на ICMP. В реальности, выбор правильного определения не имеет большого значения. Важен сервис, запущенный на хосте, а не сам хост. Главная причина, по которой нам нужно знать жив хост или нет в каком-то формальном смысле — это правильное определение зависимостей. Построив описанную систему, проверку живости хоста мы получили «бесплатно». Каждый хост должен отправлять в Ganglia свои данные. Пока он их действительно отсылает — он в некотором смысле «жив». Если не отсылает — с ним точно не все в порядке. Мы проверяем наличие этих данных при помощи Ganglia-плагина для Nagios, слегка модифицированного для наших целей.
Проверка эксплуатационных данных
Имея систему сбора эксплуатационных данных, было бы неразумно не использовать ее в событийном мониторинге. Самый простой способ сделать это — сравнивать получаемые значения с некоторыми пороговыми. Упомянутый в предыдущем пункте Ganglia-плагина для Nagios делает это из коробки.
Высокоуровневая схема взаимодействия компонент мониторинга
Понять ее проще, чем нарисовать.
Кластер приложения отсылает эксплуатационные данные в Ganglia, логи в Logstash и событийные проверки в Shinken.
Ganglia отсылает данные о «живости» хостов и проверки эксплуатационных данных в Shinken.
Shinken обрабатывает получаемое двумя способами. Он отсылает уведомления операторам и запускает обработчики событий, исправляющие некоторые неисправности.
Логи, эксплуатационные данные и информация о событиях отправляются в «приборные панели» — Kibana, Ganglia web frontend и Shinken web соответственно, где за ними наблюдают операторы.
Почему мы решили про это написать?
Система мониторинга, которую мы строили не задумывалась как соответствующая каким-то «правильным» практикам панацея. Тем не менее, в жизни она показала себя надежным помощником, на которого можно положиться.
Основным элементом нашей системы предотвращения и обработки нештатных ситуаций является наша команда поддержки, работающая беспрерывно. Мы не пытались придумать автономную систему, способную работать без человеческого вмешательства.
То, что она работает в нашем окружении не означает, что она будет работать в другом без внесения в нее изменений. Мониторинг является частью нашей общей экосистемы, включающей как технические меры (такие как наличие и грамотное использование системы управления конфигурациями), так и бизнес-процессы в работе нашей команды поддержки.
Тем не менее, мы уверены, что наш подход достаточно гибок и может быть в том или ином виде применен в достаточно широком круге ситуаций, с которыми сталкиваются в своей работе команды, поддерживающие IT-сервисы.
Давайте обсудим мониторинг
Вот уже четвертый год я занимаюсь организацией того, что принято называть Observability. Набранный за это время опыт я обличаю в текст, делюсь им с вами в виде размышления-рекомендации и выношу на суд общественности. Здесь практически не будет технических деталей – статья намеренно написана таким образом, дабы изложенное можно было положить на практически любой стек технологий. Дело в том, что инструменты врываются в тренды и покидают их с невероятной скоростью, посему их выбор остается за вами. Давайте обсудим мониторинг.
О мониторинге в контексте метрик
Если спросить среднестатистического технаря-инженера, с чем у него ассоциируется мониторинг, то скорее всего вам ответят – «метрики приложения», и подразумеваться будет их сбор и некоторая визуализация. Причем, о изнанке этого процесса, как показал мой опыт, многие даже не задумываются – в понимании большинства «оно просто показывается в Grafana/Kibana/Zabbix/подставьте нужное».
Из чего же сделан мониторинг?
Со временем, я для себя вывел следующие аспекты:
Сбор метрик из различных источников – приложения, показатели хоста, «железной» части площадки; различия в pull и push моделях пока не затрагиваем, об этом чуть позже
Запись и дальнейшее их (метрик) хранение в базе данных с учетом особенностей самой БД и использования собранных данных
Визуализация метрик, которая должна балансировать между возможностями выбранного технологического стека, удобством использования дашборд и «хотелками» тех, кому с этим всем предстоит работать
Отслеживание показаний метрик по заданным правилам и отправка алертов
О сборе метрик
Итак, вы решили создать систему мониторинга. Первым шагом предлагаю задуматься о том какие метрики собирать:
Показатели обслуживаемых приложений – здесь появляется слой метрик, которые можно связать с процессами, в корректности и стабильности работы которых вы напрямую заинтересованы; ими могут быть гипервизор, ваш софт для клиента, некоторые системные процессы.
На этом уровне появляется возможность (а часто необходимость) устанавливать однозначную связку «инфраструктура-приложение». В самом простом виде она может выглядеть так – вы мониторите состояние процесса «запущен/не запущен», к этой метрике привязываете теги с именами хоста и приложения, по сумме которых можно будет однозначно определить, к чему именно эта метрика относится
Показатели бизнес-процессов – сюда относится информация, на основе которой можно делать выводы о работоспособности бизнес-функций.
В качестве примера возьмем операцию списания денег с лицевого счета пользователя – допустим, для успешного выполнения операции необходимо, чтобы был доступен личный кабинет (веб-сервер), сервис постановки задач в очередь, брокер асинхронных сообщений, платежный шлюз и база данных. Чтобы быть уверенным, что операция может быть выполнена, вам понадобится следить за состоянием всей цепочки, хотя бы в самом простом виде – работают ли все приложения в ней
Результаты смок-тестов – по сути, расширение предыдущего уровня; это показатели периодически выполняемых фейковых бизнес-операций, по которым можно будет поймать проблему
Pull VS Push
Предмет жарких споров в тематических каналах и форумах с извечным вопросом – что же лучше?
Push-модель – это когда у вас есть классическая БД, в которую активно пишут агенты. Отличается большим объёмом точек конфигурирования (как правило, по количеству агентов мониторинга), но в то же время дает возможность базе заниматься своей основной задачей – хранить метрики и управлять их жизненным циклом, пассивно ожидая, пока в неё что-нибудь положат.
Pull-модель – насколько мне известно, относительно новый подход, набравший популярность с приходом в нашу жизнь платформ для оркестровки контейнеров. В этом случае, сам сервер мониторинга ходит по пассивным экспортерам и забирает у них метрики. Плюс – единая точка конфигурирования, сам сервер, которому надо рассказать, что и откуда забирать. ИМХО, он же и главный минус – в случае отвала сети вы теряете показатели за время её простоя. Отлично показывает себя в эфемерных средах вроде K8s, когда количество сущностей, которые необходимо мониторить, изменяется с течением времени. За их пределами уже не столь удобен – для получения метрик от хостов вам понадобятся агенты-экспортеры.
Выбор модели остается за вами – исходите из ваших потребностей и задач.
О хранении
Здесь буду немногословен – на текущий момент придумано немало TSDB (Time-Series DataBase), заточенных именно под временные ряды. Вам остается только выбрать то, что по соотношению «доступный функционал – производительность – удобство и возможности языка запросов» покажется максимально приемлемым.
Мой личный фаворит – VictoriaMetrics, рекомендую ознакомиться.
О визуализации
Подобно тому, как метрики делились на уровни, аналогично разделяется и визуализация:
Уровень площадки – самый высокий уровень визуализации, с которого, после получения алерта, пользователю мониторинга стоит начинать работать. Дашборд(ы) здесь представляют собой набор логически разделенных индикаторов «всё хорошо/что-то сломалось».
Например, каждая панель показывает состояние какой-либо группы приложений – Nginx`ы, Apache`и, Службы виртуализации; при наличии проблемы с любой из сущностей группы панель переходит из состояния «всё хорошо» в состояние «что-то сломалось», привлекая внимание
Уровень группы – следующий уровень, к которому переходит пользователь; должен быть доступен по drilldown-ссылке с предыдущего дашборда. Если ранее мы подсветили, с какой группой возникла проблема, здесь мы должны ответить на вопрос «с каким именно объектом группы?».
Продолжая начатый выше пример, здесь отображаются все Nginx на вашей площадке, по которым выведены ключевые показатели – состояния процессов, состояния соединений с БД, количество ошибок и так далее. Тут не стоит сильно вдаваться в детали, пяти-шести панелей на объект наблюдений будет достаточно
Уровень объекта – конечная точка движения нашего пользователя в большинстве случаев.
На этом уровне детально визуализируются метрики конкретного приложения/процесса/другого подвергнутого принудительному мониторингу объекта. Здесь пользователь должен найти для себя ответ на такой вопрос – «что же именно сломалось?». Начиная с этого уровня, переходы между дашбордами должны наследовать контекст – если пользователь на уровне группы кликнул по панели процесса nginx_01 хоста proxy.local, метрики именно этого приложения на этом хосте и должны отображаться
Уровень фрагмента объекта – формально, продолжение предыдущего уровня, но введен вот зачем: если какая-либо часть нашего объекта имеет слишком много метрик и достойна того, чтобы рассматриваться отдельно, под неё заводится персональный дашборд.
Например, у нашего Nginx есть апстримы со своими метриками; дабы не усложнять уровень объекта и не перегружать его, мы заводим под апстрим персональный дашборд, а на предыдущем оставляем только кликабельные индикаторы с состоянием апстрима «онлайн/частично онлайн/оффлайн». И вновь, переходы должны наследовать контекст, чтобы облегчить пользователю навигацию
Уровень инфраструктуры – самый низкий уровень визуализации и отправная точка в сборе метрик.
Тут отображаются показатели хост-системы и окружающего «железа». Хорошим ходом будет разбить на разные дашборды метрики разных частей – состояние CPU, RAM, дисков и т.д., организовав возможность горизонтального перехода между ними. Переход же на этот уровень можно создать с двух предыдущих, снова с учётом ранее установленного контекста; если пользователь смотрел на метрики приложения на хосте proxy.local, этого хоста метрики и должны отображаться
Подводя итог написанному выше, у нас получается такая диаграмма уровней, демонстрирующая путь пользователя:
Пользователь мониторинга двигается сверху вниз, разбирая инцидент
Делайте ваши дашборды шаблонными, с возможностью установки контекста через переменные. Мысль достаточно очевидная, согласен, но, тем не менее, мне приходилось встречать хардкод хостов и приложений, порождающий ворох из копий одних и тех же дашборд, что выливалось в неподдерживаемый хаос
Также, стоит выносить в переменные различные потенциально изменяемые вещи – имя базы данных с метриками, вручную составленные словари «число-значение» и т.п.
Добавляйте описание к всем панелям. Если отображаемая на панели информация кажется хоть немного неочевидной, не поленитесь дать ей описание – буквально одно-два предложения сильно облегчат работу пользователей и помогут вам же, когда возникнет необходимость вернуться к работе с дашбордом
В качестве средства визуализации сейчас лидирует небезызвестная Grafana, в которой есть функционал переменных, внутренних и внешних ссылок c шаблонизацией, комментариев к панелям и еще всякое-всякое.
О алертинге
Алертинг, пожалуй, самая значимая часть системы мониторинга. На мой взгляд, при идеальном алертинге визуализация метрик и вовсе не нужна – хорошее, годное сообщение сообщает ровно столько информации, сколько нужно для начала работ по восстановлению.
К сожалению, или к счастью, в мире нет ничего идеального, но можно попробовать к этому приблизиться. Итак, хороший алерт можно приготовить из таких ингредиентов:
Полнота сообщения – в теле алерта должна содержаться информация о том, что именно произошло и за какой период времени.
Пример: «Средняя нагрузка на CPU превышает 90% в течение последних пяти минут»; пользователь, получивший такое сообщение, видит информацию, во-первых, о событии, во-вторых, о его длительности на момент получения, что позволяет сходу примерно оценить масштабы бедствия.
Здесь стоит уточнить, что метрика обычно оценивается за некоторый период, из которого выводится максимальное/среднее/минимальное/иное другое значение, а не её мгновенный показатель – это позволяет сгладить (или же выделить – зависит от того, что именно вам нужно) всплески и временнУю задержку в доставке метрик до базы данных
Уточняющие метаданные – алерт должен сопровождаться набором тегов/лейблов, раскрывающих контекст события; это могут быть имя хоста, приложения, идентификатор uri веб-сервера и т.п.
Штамп времени первого срабатывания – тут всё просто, в алерте жизненно необходима метка времени, чтобы при получении нотификации можно было понять, новый ли алерт у вас сработал, или это всё еще горит старый
Ссылка на систему управления алертами/систему визуализации метрик, на ваш выбор – она нужна для получателя, чтобы он смог сразу перейти в мониторинг, а не тратил время на судорожный поиск закладки в браузере
С самим алертом, вроде, разобрались, теперь немного о процессе нотификации:
Не допускайте спама со стороны системы управления алертами. Когда вашего получателя заваливает письмами/СМСками/сообщениями от бота, рано или поздно он перестанет предавать им хоть какое-то значение и пропустит критичную нотификацию. Хорошим тоном будет настроить рассылку таким образом, чтобы по уже «горящим» алертам повторные уведомления отправлялись спустя какое-то время
Выделите ключевые метаданные и группируйте алерты по ним; тогда вместо, например, семи сообщений по одному объекту, ваш пользователь получит одно, в которое будут вложены остальные. Это также позволяет снизить количество нотификаций (помним про предыдущий пункт)
Предусмотрите возможность для себя и/или пользователя временно отключать некоторые алерты, например, на время технических работ
Если ваша система это позволяет, настройте иерархию алертов с автоматическим подавлением нижестоящих. Если у вас из сети выпал сервер, нет необходимости дополнительно слать письма о том, что приложения на нем стали недоступны, это и так очевидно из первого
Разделите алерты по группам – инженерам пусть приходят технические алерты, а бизнесу бизнесовые. Условной коммерческой дирекции не интересно, что у вас упал Nginx (им это ни о чем не скажет), для них куда важнее знать, что цепочка выполнения бизнес-функции «покупка товара» развалилась и компания несет потенциальные убытки
Рекомендую пощупать AlertManager – приложение из стека Prometheus, в котором есть все описанные выше возможности. Лично для меня он стал той самой «серебряной пулей», решившей сразу вагон и маленькую тележку проблем. Веб-хуки и API для интеграций входят в комплект.
Вместо заключения
В первую очередь, выражаю благодарность тем, кто прочитал до конца; надеюсь, что статья показалась вам интересной и полезной.
Это первый текст из трех запланированных – дальше я бы хотел затронуть тему логирования и его синергии с мониторингом, после чего, возможно, перейти к некоторым техническим деталям (уже не только сухим текстом). Если вам было бы интересно об этом почитать, пожалуйста, напишите в комментариях. Попробуем разобрать и обсудить сначала общий подход к сбору и централизованному хранению журналов, их роль в оценке состояния наблюдаемой площадки, а также затронем вопрос – «можно ли отрывать логи от метрик?».
Что такое мониторинг в IT или почему админы стали больше спать?
Для чего нужен мониторинг IT?
Чтобы администраторы узнавали о проблемах в инфраструктуре раньше пользователей. Это, по сути, комплекс быстрой диагностики, который дает своевременное оповещение о проблемах и точную информацию, где и что случилось конкретно.
Пример: в 15:05 возникает проблема с почтой. Благодаря системе мониторинга админ уже в 15:07 видит, что на сервере не стартовала конкретная служба Windows, из-за чего не поднялся Exchange, и юзеры не получат писем. Без мониторинга ему бы позвонил руководитель около 17:00 и спросил бы, где письмо от партнёра, которое тот уже три раза отправил полчаса назад.
Как это было раньше?
Раньше информация о всей инфраструктуре (серверах, сетевых устройствах и так далее) просто собиралась. Роль «интеллектуального обработчика» лежала на администраторе: он, как пилот в кабине самолёта, должен был окинуть все приборы взглядом, чтобы понять картину. Ясно, что так мог не каждый.
Сейчас всё более автоматизированно и немного сложнее с точки зрения системы. Статусы стараются тесно привязать к бизнес-серверам, чтобы не было информации о мониторинге «в вакууме».
Также добавился мониторинг от лица конечного пользователя, когда эмулируются действия юзера — это робот, который раз в определённый промежуток времени запускает специальный скрипт: как будто пользователь бегает по менюшкам, что-то нажимает — и если у робота что-то не получается сделать, значит, и у человека не выйдет.
Плюс сейчас используется конфигурационная база данных: информация об объектах мониторинга представлена, как набор конфигурационных единиц. Каждый сервер, каждое сетевое устройство — это некая единица, все это хранится в централизованной базе данных. Такое представление позволяет потом интегрировать систему мониторинга с сервис-деском, системой управления активами и расширять функционал дальше.
Виртуализация
Раньше вся инфраструктура была физическая, все серверы представляли собой отдельные железки, находились в стойке, их можно было приходить и щупать, пока админ не видит. Сейчас инфраструктура часто состоит из виртуальных машин, когда сервер физически один, но на нём, например, крутится с десяток виртуальных. Это требует ряда тонкостей в настройке, зато дает массу преимуществ. Например, для нас, как для разработчиков систем мониторинга, это явный плюс: можно разместить всё в виртуальной среде. Система мониторинга – это ПО, которое состоит из нескольких модулей. И раньше под каждый модуль нужен был отдельный сервер. Когда железок было несколько, заказчик мог сказать, что, мол, слишком много оборудования требуется под вашу систему. Сейчас можно делать эти сервера виртуальными, и размещать их на одном физическом сервере. Это, к тому же, серьёзно снижает стоимость хороших систем мониторинга.
Пример того, как это работает
Есть один пример из жизни (имена и лица изменены). Итак, стоит HP Operations. Юзеры, привыкшие меняться файлами через FTP, в какой-то момент обнаруживают, что файл выложить не получается. Ткнулся первый юзер: сервер его не пустил. Пользователь подумал, что сбой временный и переслал файл по почте. Потом ткнулась ещё пара человек, у них тоже ничего не получилось, и кто-то написал тикет в поддержку. Саппорт начал разбираться, в чем дело. С виду все было хорошо: сервер был работоспособен, и, тем не менее, не сервис был недоступен. Искать такую проблему «на горячую» (при том, что останавливать работу других сервисов нельзя) — задача, в принципе, стандартная, но очень муторная без системы мониторинга. Админ же просто заглянул в список событий мониторинга и увидел много алертов от файрволов. Причём множественные обращения фиксировались снаружи. Очень быстро обнаружилась (сюрприз!) DDoS-атака на этот FTP, которая и была отсечена. Думаю, без мониторинга поиск проблемы был бы часа на три-четыре дольше, что могло повлечь дальнейшие осложнения.
Автоматизация
Ещё системы мониторинга умеют автоматически выполнять сервисные действия. Например, характерная ситуация: на сервере кончается место из-за временных файлов, приложения начинают тормозить. Админ заходит, чистит временные файлы, уходит — всё тип-топ до следующего повтора. Мониторинг умеет определять момент, например, когда 90% диска заполнено, генерировать событие – и запускать очистку самостоятельно в автоматическом режиме.
Поскольку система мониторинга умеет интегрироваться с сервис-десками, она может автоматически создавать тикеты о проблемах. То есть ниндзя из саппорта могут тихо и внезапно решить проблему еще до момента первого звонка.
Как это внедрить у себя?
Можно сказать, что система мониторинга, как и любая другая система большого объема, штука достаточно сложная. Внедрение обычно делается поэтапно, вне зависимости от того, делает это заказчик своими силами или же с помощью интегратора.
Сначала определяются объекты мониторинга (сетевое оборудование, серверы, приложения и т.д.). Потом выбираются критичные показатели для каждого объекта. Если взять слишком много данных, админы утонут в потоке оповещений о превышении предельных показателей, а если слишком мало – могут пропустить что-то важное. После этого нужно определиться с архитектурой, выбрать продукт, решение, вендора. Дальше уже можно приступать к настройке. Иногда делается пилотная зона-макет, а потом уже этот макет расширяется на всю инфраструктуру.
Готовые продукты
Системы мониторинга ориентированы на заказчиков разного уровня. Большие, сложные и дорогие решения требуют огромных трудозатрат по их разворачиванию и внедрению, но для крупного бизнеса это стоит того. Есть варианты поменьше и попроще для среднего и малого бизнеса, они представляют из себя некую коробку, которую достаточно легко внедрить. Самое известное решение из недорогих — Microsoft SCOM. Есть ряд open-source вариантов, они вообще бесплатны и требуют только довольно кропотливой настройки.
Для какого размера компании система полезна?
Предел там, где системный администратор не справляется с объемом работы и уже не может контролировать каждый сервер. В маленьких компаниях смысла в использовании таких систем обычно нет (или же можно брать частичные решения), а в компаниях среднего размера и крупных более-менее серьёзная система мониторинга обязательно должна быть. Такие системы начали развивать лет 10 назад, и сейчас почти все крупные заказчики IT-услуг уже внедрили у себя что-то подобное.
Что ещё умеет мониторинг?
Мониторинг кода
Обучение
Изначально системы требовали больших усилий для настройки пороговых значений (что считать аварийной ситуацией – когда диск заполняется на 90% или 95%?). Естественно, при большом количестве объектов мониторинга это было трудоёмкой задачей. Сейчас системы мониторинга умеют анализировать исторические данные, изучать поведение объектов и на основании этого строить так называемые «динамические пороги». То есть система мониторинга «обучается» и понимает, что является нормальным подведением объекта, а что говорит об аварии.
Что это поменяет для ИТ-отдела?
Администраторы смогут освободиться от рутинной работы и сконцентрироваться на более важных и интересных задачах. Они будут точно представлять, что происходит в системе на данный момент, т.е. инфраструктура будет прозрачна. Стиля работы, когда они вынуждены тушить пожары и постоянно чинить неисправности, не будет, можно будет обходить грабли заранее. Решение рутинных проблем можно будет автоматизировать. Конечно, непредвиденные аварии, все равно придется устранять «вручную», но это будет легче, так как будет точная диагностика.
Останется только читать Хабр и убеждать бухгалтерию, что если админ мало работает, то это невероятное счастье.