Технические средства мониторинга ИБ / Хабр

Вступление

Вероятно, вы знаете, что компания Splunk всерьез и, возможно, надолго ушла с рынка этой страны. Но мы продолжаем работать со Splunk, я этим занимаюсь больше 5 лет, а Аня, @manabanana — второй год. Мы обросли практикой, рецептами, фишками и ощущениями от этой системы.

(Факты и цифры, оставленные в этом абзаце и других местах текста без изменений следует воспринимать как актуальные по состоянию на 2022 год, когда был прочитан данный доклад. С тех пор многое изменилось, профессиональные интересы докладчиков, принявших в прошлом челленж Splunk, связаны в настоящее время с рядом других систем и сфер IT, подробности можно узнать в наших профилях или в личном диалоге.)

Я расскажу, как у нас устроен Splunk, а Аня поделится предельно конкретным кейсом по мониторингу нашей системы мониторинга, который она решила благодаря ее всепроникающей логике и изобретательности. Если конкретно — кейс будет про жизненный цикл данных внутри поискового индекса, как за этим можно смотреть, чем нас удивил мониторинг процессов и где в итоге мы нашли зацепку.

Думаю, что многие пошли в IT-сферу, исходя из кайфа, который испытываешь, когда напишешь офигенный код, построишь удачную архитектуру, и это всё здорово и эффективно работает. В дополнение вы покрываете свои системы тестами, и работа составляющих их звеньев становится абсолютно прозрачной и понятной.

Наша мотивация и цель сегодня такая же — поделиться ощущением от эксплуатации сложных систем. Тем удовольствием и кайфом, которые мы испытываем, когда такая система — с множеством степеней свободы, движущихся частей и параметров настройки — из неуправляемого хаотического нечто становится послушной, понятной и предсказуемой. Это очень приятное ощущение.

Гибкие материалы:  Экзаменационные билеты для рабочих люлек подъемников с ответами|Охрана труда и подготовка кадров

Что нам стоит soc построить

Чем выше бюджет проекта, чем больше проект политизирован, тем сложнее изменить его вводные. Но для решения вопросов безопасности тоже действует принцип Парето.  Добивать самые трудоёмкие 1-5-10% договора, которые не будут заметны в общем результате, не выгодно ни одной из его сторон.

Итоговые цели нужно как ставить, так и пересматривать. А когда они зафиксированы в договоре, это практически невозможно. Например, база данных, с которой по грандиозному плану будут собираться события аудита, упадёт под дополнительной нагрузкой, вызванной этим самым аудитом.

Декомпозицию на этапы можно производить вплоть до подключения «вот этих 5 видов источников» или создания «вот этих 10 сценариев и ранбуков к ним». Главное – это не полнота внедрения, а полнота использования того, что внедрено. Обосновать модернизацию эффективного решения проще, чем того, которое всплывает два раза в год в негативном контексте и стоит в десять раз дороже.

Если не знаете, что точно хотите и можете получить от автоматизации – просите пилотный проект. Но если не понимаете, что вам надо «без автоматизации» – от кого будете защищаться, куда и как ему было бы интересно проникнуть, что вам с этим делать – преимуществ от пилота будет мало.

В технической части вы, вероятно, совершите скачок. Но подходит ли вам конкретный продукт – сказать будет сложно. Тут нужен консалтинг, а не внедрение технических решений. Пока вы не определитесь, что хотите автоматизировать, выбор конкретной системы не будет обоснованным. То, что показалось достаточным в ходе сегодняшнего пилота, завтра придётся подпирать костылями.

Пилот должен проводиться в рамках разумного. Я знаю организацию, которая столкнулась с невозможностью масштабирования после закупки. Не первый раз просят пилот, в котором у SIEM 30 графических панелей, 40 видов источников, 50 правил корреляции и 60 отчётов.

Log Management

Первым этапом может быть Log Management (LM) в виде специализированного решения или унифицированного варианта, типа Elastic Stack. Вы получите централизованное хранилище журналов событий различных источников, которые приведены к единой модели данных «из коробки» или под ваши требования рядом нехитрых манипуляций.

Почему полезно начать с данного этапа, а не сразу переходить к SIEM? Это дешевле, а решаемые в процессе внедрения вопросы одинаковые. Учитывайте и стоимость поддержки от покупки до перевода в промышленную эксплуатацию – 30-60% от стоимости в год. Растянулся проект на два года – скупой платит дважды в прямом смысле слова.

Система может продолжить работать рядом с SIEM для экономии его лицензионной квоты одновременно с хранением дополнительных данных для расследований и Threat Hunting-а. Или её можно модернизировать в SIEM: некоторые производители предлагают такой вариант.

Какие задачи стоит решить при внедрении решения LM:

  1. Определить перечень источников, настроек аудита, полей событий и способов сбора; подключить все типы источников, чтобы определить все связанные риски. Модель нарушителя, модель угроз и оценка рисков – это шаг номер ноль в построении системы мониторинга. Но как эти документы конвертируются в перечень источников и настройки их аудита? С типовыми решениями типа операционных систем или активного сетевого оборудования всё более или менее понятно. Есть читшиты по EventID, примеры поиска угроз с использованием их событий и т.д. Но при подключении какой-нибудь системы ip-телефонии всё может быть не так тривиально. Набор полей генерируемого события не закроет потребности расследования. Представление событий на источнике будет отличаться от того, что он отдаёт вовне. Цель подключения теряется, но договор дороже денег.

    Да, эту подготовительную работу можно произвести без LM, обратившись к событиям на источнике напрямую. Но в предложенном подходе кроется ряд возможностей:

    • Изучение логов в производительной среде. Попробуйте поискать события на Windows Event Collector, агрегирующем данные с трёхсот хостов, с помощью встроенных инструментов. Поиск растягивается на минуты, если вообще завершается корректно. А возможности настройки фильтрации очень ограничены.

    • Оценка нагрузки на источник от передачи событий в стороннюю систему. Заодно можно изучить и нагрузку на сеть. Помню случай, когда трафик проходил через межсетевой экран по пути от одной подсети сегмента в другую (о чём заказчик предпочёл умолчать). Поток Syslog-событий большого объёма привёл к отказу в обслуживании на данном файрволе.

    • Понимание, необходимы ли вам дополнительные логгеры на существующих источниках по результатам расследований. События Sysmon могут быть информативнее событий Windows. А Auditbeats фиксирует то же, что и auditd, но не дробит единое событие на четыре строки, что требует дополнительной корреляции и лицензионной квоты. Если такие логгеры нужны, как вы будете ими управлять? Часть решений стабильны, часть оставляет желать лучшего. Это всплывает только при масштабировании. Готовы ли вы «платить» за их преимущества?

    • Оценка потока событий. У интеграторов и производителей есть калькуляторы, чтобы теоретически прикинуть это значение. Но я видел межсетевые экраны, которые давали как 50 событий в секунду, так и 12000. Нагрузка, под которой находится устройство, пиковые скачки данных и когда они происходят, что из событий будет отфильтровано – всё это калькуляторы не учтут. А лицензия уже заложена в бюджет.

      На примере сбора событий рассмотрим различие в философии решений одного класса. Что вы собираете и в какую модель данных складываете, хочется оптимизировать хотя бы со стороны лицензии и объёма хранилища. Но один вендор рекомендует собирать только те события, которые нужны, и вытаскивать из них только то, что полезно. И вообще, сделать всё, чтобы не размывать фокус аналитика. Что же тут интересного? В этой системе такая философия реализована вкладкой, позволяющей посмотреть сгруппированные данные по всем событиям и провалиться в искомые. Есть возможность хранить с различными сроками одни метаданные событий для операционной деятельности и другие для комлайенса и отчётности. Удобно устанавливать предварительные фильтры и способы отображения данных не только для ограничения доступа, но и для удобства оператора. Нужен ли вам такой подход? Зависит от задач. Но близкое знакомство с этой, шестой для меня SIEM, изменило представление о классе решений в целом.  

  2. Привести инфраструктуру в соответствие с политиками и регламентами. Для большинства этих кейсов корреляция не требуется. Но без такого порядка борьба со сложными угрозами не будет результативна. Действительно ли межсетевое взаимодействие идёт только по разрешенным портам? Все ли пользователи работают через корпоративный браузер? Используются ли где-то вместо технических персональные учётные записи? Вопросов к ИТ здесь может возникнуть масса. И теперь у вас есть инструмент для их решения. Идеализировать не стоит – инфраструктура меняется быстро, лес рубят – щепки летят. Но поэтапно закручивать гайки не в ущерб бизнесу – вполне.

  3. Организовать Threat Hunting и расследование инцидентов. LM для данной задачи – единственная необходимая платформа. Вы видите подбор пароля на котроллере домена по событиям 4776, в которых виден только FQDN атакующего, и он отсутствует в DNS. Что делать дальше? Есть ли у вас логи рабочих станций и серверов с соотносимыми 4625? Аутентифицируются ли устройства при подключении к сети? Существует ли актуальная CMDB и процедуры её обновления? Кто может в обход VPN подключаться удалённо? Что делать, если подбор пароля идёт через почтовый сервер? Эти вопросы могут привести вас к мысли о необходимости сбора дополнительных событий или внедрения отсутствующих средств защиты. Также результаты расследований должны привести к решению следующих задач:

    • Определить список критичных инцидентов и создать для них ранбуки или плейбуки (далее – ранбуки, как более пригодный для автоматизации вариант).Это утвердит алгоритм и результаты расследований. Станет понятно, что автоматизировать с помощью SIEM. Возможно, вы решите пойти по моделям в ИБ систематически или решите свои критичные задачи. Важно понять, хватает ли вам информации, чтобы отличить нормальную активность от инцидента, и к кому с ним идти. Сможете ли вы оперативно заблокировать учётную запись или порт, или ИТ потребуется на это неделя? Результаты корреляции настолько же важны, насколько их отсутствие, если их некому анализировать, а, обнаружив угрозу, вы не в состоянии её подтвердить и устранить.

    • Устранить ложно положительные (ЛПС) и ложно отрицательные (ЛОС) «срабатывания». Под срабатываниями понимают автоматическое создание подозрения на инцидент в SIEM. Но ими можно считать и результаты ручной работы. Что если любое прилетающее обновление ПО вызовет шквал фолсов? Или события генерируются не тогда, когда вы этого ожидаете, и вы пропускаете угрозу. Или требуется дополнительная информация, чтобы отличить штатную работу от инцидента. Если ЛПС или ЛОС будет слишком много, смысл автоматической корреляции теряется. Возможно, стоит посмотреть на проблему под иным углом: искать более подходящие индикаторы. Инцидент – это не атомарное действие, а целый Kill Chain. Злоумышленник оставляет множество следов. Если у вас нет способа засечь атакующего на одном шаге, ловите на другом. Говорят, что безопасность – это сложно достижимое состояние. Потому что команда защитников одна, а команд атакующих – целая плеяда. Но верно и обратное – если злоумышленнику надо успешно завершить каждый шаг атаки, то защитнику достаточно обнаружить его на любой стадии. После этого легко размотать всю последовательность действий.

Результаты использования LM:

  1. Логи собираются в централизованное хранилище, доступное аналитику для поисковых запросов, построения отчётов и визуальных панелей. Это позволяет оперативно проверять гипотезы (Threat Hunting) и обеспечивает единую консоль для анализа данных всех средств защиты.

  2. Для значительной части вопросов и проблем, которые возникнут при внедрении системы следующего уровня, уже выработаны решения.

  3. Определены перечни инцидентов для мониторинга. Аналитик выявляет, расследует и реагирует на данные инциденты по ранбукам, попутно уменьшая ЛОС и ЛПС.

  4. Состояние инфраструктуры приведено в соответствие с политиками и стандартами.

  5. Возможность и способ сбора событий, их состав и объём определены и управляемы.

Следующий этап зрелости – переход от LM к SIEM. Мы пойдём более кратко: этот раздел уже создал нам базу.

SIEM

Переход от LM к системам класса Security Information and Event Management требуется в двух случаях:

  1. Необходимо оповещение операторов о подозрениях на инциденты (далее – инциденты) в режиме близком к реальному времени. К этой опции должны прилагаться сотрудники, работающие в том же режиме – 24х7.

  2. Необходимо выявление последовательностей разнородных событий. Это уже не просто фильтрация и агрегация, как в LM или Sigma (на текущий момент).

Дополнительно вы получите:

  1. Правила «из коробки», которые хороши в качестве примеров или отправной точки. Или после глубокой доработки и настройки.

  2. Историческую корреляцию, совмещающую преимущества SIEM (структура корреляционного запроса) и LM (работа с данными на всю глубину). Быстрое тестирование нового правила на исторических данных, проверка только что пришедшего IOC, который обнаружен две недели назад, запуск правил с большими временными окнами в неурочное время – всё это применения данной функции. Она может быть частью базового решения, требовать отдельных лицензий или вовсе отсутствовать.  

  3. Второстепенные для одних, но критичные для других функции. Иное представление данных на дашбордах, отправка отчётов в мессенджер, гибкое управление хранением событий и т.д. Производитель стремится оправдать скачок цены от LM к SIEM.

Задачи на этом этапе следующие:

  1. Создание логики детектирования всех интересных вам инцидентов. Без автоматизации вам приходилось выбирать только самые критичные. Сейчас можно учесть всё действительно важное. Главный вопрос – как на таком потоке выстроить реагирование.

  2. Уменьшение ЛПС и ЛОС путём обогащения данных – добавления информации из внешних справочников, изменения пороговых значений, дробления правил по сегментам, группам пользователей и т.д. Возросший объём статистики по работе сценариев улучшает качество их анализа.

Обе задачи решаем итерационно. Хороший показатель – 15 инцидентов на смену аналитика. Достигли его – закручиваем гайки дальше.

Начинаем оценивать эффективность расследования – время на приём в работу инцидента, время на реагирование, время на устранение последствий и т.д. И пытаться этой эффективностью управлять – что мешает работать быстрее, где основные задержки?

Результаты использования SIEM:

  1. Выявление инцидентов происходит в автоматическом режиме, возможно обнаружение и корреляция цепочек разнородных событий.

  2. Рост числа типов инцидентов. Аналитик переключает внимание с обнаружения на расследование и реагирование. При этом не стоит забывать про Threat Hunting – этот метод остаётся лучшим для определения новых для вас угроз.

Какой шаг сделать дальше? Тут лучших практик нет. Следующие этапы могут идти последовательно в любом порядке, параллельно или вовсе отсутствовать.

. Monit — Простое решение для превентивного мониторинга

Технические средства мониторинга ИБ / Хабр

Monit — это маленькая open source-утилита для управления и мониторинга Unix-систем. Monit обеспечивает автоматическое сопровождение и восстановление, умеет выявлять причины сбоев.

Стоимость: Бесплатно, open source.

Технические средства мониторинга ИБ / Хабр

Полноценное решение для построения графиков различных метрик, создано на базе RRDTool.

Стоимость: Бесплатно, open source.

Технические средства мониторинга ИБ / Хабр

Этот сервис позволяет быстро диагностировать проблемы на Linux-серверах.

Стоимость: Триал 14 дней, затем от $19 ежемесячно.

Технические средства мониторинга ИБ / Хабр

Свободная платформа класса Enterprise для сетевого мониторинга и управления.

Стоимость: Бесплатно, open source.

Технические средства мониторинга ИБ / Хабр

Внешний мониторинговый сервис для веб-сайтов, созданный компанией ZOHO Corp. Website & Server Monitoring Service.

Стоимость: Триал 30 дней, затем от $9 ежемесячно.

Технические средства мониторинга ИБ / Хабр

Мониторинговая система для серверов на FreeBSD, Windows, OS X и Linux, с кастомными плагинами.

Стоимость: Триал 15 дней, затем от $9 ежемесячно.

* * *upd.

Технические средства мониторинга ИБ / Хабр

PM2 менеджер процессов для NodeJS и мониторинг серверов.

Стоимость: Есть бесплатная версия.

IRP или SOAR

Эти термины изначально говорили о разных системах: Incident Response Platform и Security Orchestration, Automation and Response (или Report). Но современные решения расположились по всей палитре между этими огнями и поэтому термины стали синонимами с широким диапазоном значений.

Основных функций у этих систем четыре:

  1. Тикетница. В карточке инцидента аналитики получают задачи, комментируют их выполнение, передают активности между сменами и т.д.

  2. Создание ранбуков. Варианты функционала различны: просто графическое представление алгоритма действий, оно же с функцией отображения хода расследования или расширенный вариант – каждый из шагов алгоритма может быть автоматизирован скриптом.

  3. Автоматизированное реагирование на инциденты. Каждый шаг алгоритма может быть выполнен вручную, автоматизировано или автоматически. Зависит только от уровня контроля человеком, который вы хотите оставить. Блокировать ли в автоматическом режиме учётную запись для предотвращения развития инцидента? А если это ЛПС? А если это учётка главного бухгалтера в день выдачи заработной платы? А если это учётка администратора домена и через минуту будет поздно? Производитель даёт набор интеграций из коробки и инструменты создания практически любых пользовательских вариантов с использованием нескольких языков программирования.

  4. Анализ метрик эффективности SOC, доступных системе.

Это специализированный сервис деск с функцией исполнения скриптов.  Если у вас получится закрыть часть требований встроенным функционалом, вам необходимо получить более простые и стабильные способы работы со скриптами или дать службе мониторинга отдельный от ИТ инструмент со специализированным интерфейсом – это решения для вас.

Автоматизация способна ускорить реагирование на часть кейсов на 1-2 порядка. Но далеко не в каждом случае. Второй вариант использования – учёт действий аналитика. Если в инциденте участвует критичный актив, например, АСУ ТП, каждый шаг должен быть выполнен компетентным сотрудником, который ответственен за решение; ничего не должно быть пропущено, лог реагирования сохранён.

Результата использования IRP/SOAR:

  1. Алгоритмы решения всех инцидентов собраны воедино, выстроен автоматизированный процесс расследования и реагирования.

  2. Ведётся лог действий по реагированию, что позволяет как контролировать его в ручном режиме, так и собирать метрики для оценки эффективность процесса.

NTA и NBA

У вас уже скорее всего есть SIEM, который получает агрегированные данные трафика в форматах NetFlow, sFlow, jFlow, Packeteer или сам создаёт такие агрегаты из копии трафика. Их основные данные – информация L3 и L4 OSI. Также, у вас скорее всего внедрён IDS/IPS, который не записывает трафик, но анализирует его полную копию от L2 до L7, насколько позволяет шифрование.

Если эти средства не решили ваши задачи, можно дополнить систему мониторинга с помощью Network Traffic Analysis. Это решение производит запись трафика для его последующего исследования. При планировании стоит учесть гораздо больший по сравнению с LM/SIEM объем хранилища и необходимость предварительной расшифровки данных.

Трафик объединяет в себе и информацию, и факт её передачи. В отличие от событий, генерация которых избирательна, он полностью описывает, что произошло между двумя взаимодействующими системами, и его нельзя удалить или сфабриковать. События собираются в LM или SIEM с некоторой задержкой, если это не Syslog, в случае которого возможен спуфинг. А если успеть очистить журнал источника – действие, подозрительное само по себе – что точно случилось узнать будет трудно.

Также можно использовать решения класса Network Behavior Analysis – аналог U(E)BA для сети со всеми его преимуществами и недостатками, но с парой особенностей. Во-первых, эти решения гораздо чаще выпускаются в виде обособленных продуктов. Во-вторых, как мы уже говорили в части 6, основных сетевых протоколов несколько десятков, что делает решение «из коробки» довольно эффективным.

Результат использования NTA и NBA – у вас есть аналоги SIEM и U(E)BA, позволяющие использовать все особенности трафика.

Custom it-monitoring stacks

В третью категорию следует отнести индивидуальные разработки, основанные на различных технологических стеках. Многие крупные компании, учитывая недостатки вышерассмотренных решений, стремятся избавиться от них путем комбинирования технологических компонентов и внутренней разработки.

Принимая во внимание, что Graphite и Prometheus не являются готовыми решениями и не рассчитаны для работы «из коробки», их часто используют как основу для проектирования итоговой системы. Например, в том же Graphite можно заменить подсистему хранения данных с Whisper популярным InfluxDB, оптимизировав тем самым хранение time-series-данных.

Или, при необходимости обеспечения отказоустойчивости и реализации OLAP-сценария обработки данных, можно выбрать связку ClickHouse ZooKeeper, обеспечив максимально эффективные хранение и обработку данных. Eсли же требуется более красивый и функциональный интерфейс, к любому из четырех вышерассмотренных решений можно добавить инструмент Grafana, позволяющий по-новому взглянуть на собираемые ИT-метрики.

А если добавить пару самописных сервисов для решения узкоспециализированных задач, удастся получить практически идеальную систему ИT-мониторинга. Может возникнуть вопрос, почему «практически»? Ответ прост: крайней высокая сложность сопровождения подобной системы.

При возникновении внештатных ситуаций или необходимости доработки системы, в случае отсутствия высококвалифицированных специалистов, компания может столкнуться с серьезными проблемами. Чтобы избежать такого развития событий, в штате компании обязательно должны присутствует специалисты с соответствующими компетенциями.

Таблица 3. Достоинства и недостатки Custom IT-monitoring stacks

Достоинства

Недостатки

Возможность комбинирования компонентов и создания индивидуальной системы под конкретные задачи

Архитектурная сложность решения

Наличие инструментов по масштабированию и отказоустойчивости

Низкий уровень ИБ – отсутствие полноценной ролевой модели доступа и сложность организации безопасного взаимодействия между компонентами системы

Продвинутые архитектура хранения и визуализация данных

Отсутствие официальной поддержки

Возможность доработки функционала системы с помощью самописных скриптов и сервисов

Отсутствие поддерживаемой библиотеки плагинов

Альтернативным решением, позволяющим нивелировать рассмотренные выше недостатки, является использование современных коммерческих систем. На зарубежном рынке представлено достаточно много решений от крупных вендоров – ManageEngine OpManager, IBM Tivoli Monitoring, Solarwinds Network Performance Monitor и других.

На российском рынке также имеются активно развивающиеся продукты в сфере ИIT-мониторинга, в частности Naumen Network Manager и NGRSOFTLAB Dataplan. Каждый из этих продуктов предлагает современный стек технологий, продвинутые инструменты по оповещению и реагированию, а также качественную официальную поддержку.

Netxms – система мониторинга корпоративной сети

Система управления и мониторинга сети корпоративного класса, которая обеспечивает комплексное управление событиями, мониторинг производительности, оповещения, отчетность и построение графиков для всех слоев ИТ-инфраструктуры. Полностью на русском языке.

Система имеет трехуровневую архитектуру: информация собирается агентами мониторинга (либо высокопроизводительные агенты NetXMS или агенты SNMP) и предоставляется мониторинг серверу для обработки и хранения. Сетевой администратор может получить доступ к собранным данным с помощью полнофункционального клиентского приложения (MANAGEMENT CONSOLE) или веб-интерфейса.

NetXMS имеет широкий спектр поддерживаемых платформ, операционных систем и СУБД, обеспечивая полную интеграцию с какой-либо инфраструктурой.

NetXMS может быть использована для мониторинга всей ИТ-инфраструктуры, начиная с протокола SNMP-совместимых аппаратных средств (таких как коммутаторы и маршрутизаторы) и заканчивая приложениями на серверах.

Victor Kirhenshtein и Alex Kirhenshtein – оригинальные авторы, поддерживающие NetXMS. NetXMS работает нативно в ОС Windows, ОС Linux и других Unix-подобных системах. Она лицензирована под GNU GPL v2, опубликованной FSF.

Особенности:

  • единая платформа для управления и мониторинга всей ИТ-инфраструктурой;
  • предназначена для максимальной производительности и масштабируемости;
  • распределенный мониторинг сети;
  • автоматическое обнаружение сети;
  • гибкая и простая в использовании обработка событий
  • инструменты анализа воздействия на бизнес;
  • быстрое развертывание с минимальными усилиями конфигурации;
  • легкая и простая интеграции со смежными продуктами;
  • встроенная поддержка большинства популярных платформ и операционных систем;
  • мониторинга сетевых устройств, серверов и приложений с одного сервера управления;
  • сбор данных из протокола SNMP-совместимых платформ или из родного NetXMS агента;
  • возможность отправки электронных писем и смс-уведомлений или выполнение внешних программ как реакция на любое событие, что позволяет пользователям получать предупреждающие уведомления на основе собранных значений;
  • организация наблюдаемых объектов в иерархические структуры для представления зависимостей сервисов;
  • централизованное удаленное обновление агента;
  • портативная клиентская библиотека;
  • гибкая политика на основе обработки событий (в том числе правила корреляции);
  • удаленные действия;
  • гибкая настройка контроля доступа;
  • встроенный скриптовый движок для автоматизации и управления.

По умолчанию, логин “admin” и пароль “netxms” для доступа к консоли управления. При первом входе появится окно изменения пароля. Перед использованием рекомендуется изучить инструкции на официальном сайте.

Prometheus, graphite

Во вторую категорию входят современные решения, к которым можно отнести такие системы, как Prometheus и Graphite. Они появились сравнительно недавно и активно развиваются. Архитектура обоих решений направлена именно на работу с time-series-данными. Независимо от метода сбора (SNMP/агенты), итоговое представление и хранение данных в обоих решениях будет в формате временных рядов, за исключением, что Graphite хранит данные в кольцевой СУБД Whisper, а Prometheus – в файлах (используя многомерную модель с продвинутыми механизмами индексирования и тегирования).

Поскольку рассматриваемые решения появились сравнительно недавно, разработчики учли многие недостатки предыдущих систем и постарались сделать решения более гибкими и удобными. Помимо наличия основополагающего функционала по мониторингу ИТ-метрик, Graphite и Prometheus имеют ряд преимуществ, но не обошлось и без недостатков (таблица 2).

Таблица 2. Достоинства и недостатки Graphite и Prometheus

Достоинства

Недостатки

Современная архитектура хранения данных и относительно низкая степень утилизации дисковой подсистемы

Ограниченность функционала в части настройки логики триггеров и автоматизации реагирования на инциденты

Оптимизированный язык запросов, позволяющий более удобно работать с собираемыми данными

Отсутствие цельности решения – подсистема сбора данных требует множество сторонних агентов и плагинов. При этом решения не имеют встроенной подключаемой библиотеки

Продвинутые возможности по созданию и кастомизации дашбордов, их сортировке и расположению

Отсутствие официальной поддержки и относительно небольшое сообщество

Продвинутые возможности по настройке временных срезов и применению различных функций прямо на визуализациях

Отсутствие инструментов по масштабированию и отказоустойчивости

Zabbix, nagios

Наиболее популярными и узнаваемыми системами ИT-мониторинга являются такие решения, как Zabbix и Nagios. Они построены на базе программного обеспечения с открытым исходным кодом и давно зарекомендовали себя как качественные и успешно решающие целевые задачи продукты.

И Zabbix, и Nagios способны осуществлять мониторинг большинства компонентов любой современной ИT-инфраструктуры, включая сетевое оборудование, ОС, различные приложения, базы данных, платформы виртуализации и т. д. Обе системы поддерживают агентский и безагентский сбор данных с целевых источников, имеют инструменты оповещения, визуализации и реагирования, а также сторонние плагины и возможность модернизации логики работы с помощью внешних скриптов.

Данные решения находятся в одной категории, достаточно схожи по своему функционалу и поэтому имеют аналогичные достоинства и недостатки (таблица 1).  

Таблица 1. Достоинства и недостатки Zabbix и Nagios

Достоинства

Недостатки

Продвинутые возможности по настройке триггеров и оповещений об инцидентах

Использование РСУБД в качестве подсистемы хранения данных и, как следствие, высокая степень утилизации дисковой подсистемы

Большая библиотека плагинов, существенно расширяющая возможности решений

Ограниченный интерфейс как в части функционала, так и в части визуализации

Наличие официальной поддержки и крупного сообщества

Отсутствие инструментов по масштабированию и отказоустойчивости

Большое количество сторонних систем, поддерживающих интеграцию

Ограниченные возможности по ретроспективному анализу собираемых данных

В современном мире, учитывая архитектурную сложность и территориальную распределенность ИТ-инфраструктур, непросто встретить среднюю или крупную компанию, не использующую системы ИТ-мониторинга. Сбои в работе ИТ-оборудования при отсутствии адекватного мониторинга, использующего инструменты оповещения, визуализации и реагирования, способны серьезно пошатнуть бизнес-процессы, а следовательно, принести существенные финансовые потери.

Выбирая систему мониторинга ИT-инфраструктуры, необходимо принимать во внимание не только характеристики и возможности отдельно взятого комплекса, но и учитывать такие нюансы, как сложность развертывания, стоимость сопровождения и наличие соответствующих компетенций в компании.

Далее рассмотрим наиболее популярные open-source системы мониторинга ИТ-инфраструктуры, сегментируем их на категории в зависимости от основных принципов и парадигмы работы, выявим достоинства и недостатки и определим, существует ли единственно лучшая система или же каждая из рассмотренных в статье может найти своего функционального заказчика.

За чем нужно следить


Мониторинг инженерной инфраструктуры нужно вести по возможности на трех уровнях: автономные датчики, оборудование и системы в целом.

Под автономными датчиками мы в первую очередь подразумеваем датчики протечек, температурные датчики, датчики объема и движения.

  • датчики протечек нужны всегда, особенно если в дата-центре используется система охлаждения с жидким теплоносителем или фреоновая с увлажнением. Размещаем их под каждым кондиционером, узлом и краном трубопровода, т. е. в тех местах, где может закапать.
  • температурные датчики устанавливаем в холодных и горячих коридорах машинных залов, в помещениях с инженерной инфраструктурой (насосные, помещения АКБ, ГРЩ и пр.).
  • датчики объема/движения, открытия и закрытия дверей стоек. В отличие от предыдущих, они опциональны. Их можно использовать в залах или для группы стоек, огороженной забором (cage).

Оборудование

нужно мониторить по возможности все: ИБП, ДГУ, кондиционеры, PDU, АВР, камеры и пр. По каждому важно получать следующую информацию:

Следить за каждой единицей оборудования в изоляции недостаточно. Чтобы понимать общую картину, отслеживайте

системы целиком

. Так вы сможете видеть взаимосвязь оборудования в единой цепочке, и вам будет легче понять, на каком этапе возникла неисправность. Взаимосвязи оборудования в системе можно визуализировать с помощью принципиальных схем.

Пример 2: отключился распределительный щит в машинном зале. Если мы мониторим оборудование по отдельности, то понадобится время, чтобы понять источник поломки – щит или ИБП, от которого он питается. Если же у нас перед глазами будет схема всей системы, то мы быстро увидим слабое звено.

Технические средства мониторинга ИБ / Хабр
Схема системы энергоснабжения, показывающая все оборудование в одной цепочке.

Индексы и жизненный цикл данных в них

Индексеры — это хранилища проиндексированных данных, а индексы — это то, что там уже есть. Физически индексы — это директории в файловой системе индексера.

Данные у нас чаще всего делятся по системам или департаментам, и поступают в специально созданные для департаментов различные группы индексеров. Из четырех типов хранилищ — Hot Path, Cold Path, Thawed Path и Frozen Path — мы используем только два, Hot Path и Cold Path.

Каждый индекс представлен на самом деле несколкими директориями, соответствующими вышеупомянутым состояниям (эти директории называются бакетами): 

  1. Hot — директория, доступная для записи и чтения.

2-3. Warm / Cold — только чтение, записывать уже нельзя.

  1. Frozen.

  2. Thawed.

Самое главное — переход из состояния в состояние только последовательный. Из Hot можно перейти сначала в Warm, и только после этого — в Cold:

Жизненный цикл данных в индексе
Жизненный цикл данных в индексе

Для перехода используются различные триггеры (срабатывающие при достижении заданных в конфиге параметров). Например, на схеме упомянут параметр maxDataSize — соответствующий триггер срабатывает, когда директория, в которую записываются проиндексированные данные, достигла максимального, указанного в этом параметре, размера.

Далее рассматривается параметр maxHotBucket, если больше нет доступных для записи и подходящих по временному интервалу директорий; какой-то из более ранних бакетов закрывается, переходит в теплое состояние, и открывается новый Hot-бакет.

Можно задать время жизни индекса — maxHotIdleSec и maxHotSpanSecs, разница между временем создания и текущим (то есть, сколько бакет будет в горячем состоянии). Или это может быть разница между последним пришедшим событием и текущим временем. Если указанный временной интервал превышается, то индекс переходит в следующее состояние.

По сигналу Reload Splunk (если на индексере происходит reload процессов Splunk), все горячие бакеты перейдут в теплое состояние, чтобы не повредить данные записью. 

Кроме того есть другие внутренние триггеры, которые срабатывают, когда значения различных параметров состояния приближаются к заданным в конфиге пороговым значениям. Рассмотрим такие «пороги».

Параметр homePath.maxDataSizeMB показывает, какой максимальный объём может иметь директория Home Path, — общая директория для всех индексов. Если директория Home Path заполнена, то чтобы что-то записать, нужно что-то освободить — а значит, что-то переносится в Cold. При превышении этого порога срабатывает один из важных для нас триггеров.

Параметр maxWarmDBCount задаёт максимально возможное количество тёплых бакетов. При превышении этого значения срабатывает другой важный триггер. В остальных бакетах похожие триггеры. В настройках Cold-бакетов, например, есть параметры coldPath.maxDataSizeMB и frozenTimePeriodInSecs, задающие время хранения проиндексированных данных.

Мониторинг процессов

У самого Splunk внутри действительно очень мощный мониторинг состояния самого себя. Вы можете проследить весь процесс от начала и до конца: когда данные пришли на сервер и как они проиндексировались. Но, как говорится, доверяй, но проверяй: тем более, было бы очень странно, если бы мы только на мониторинг самого Splunk ориентировались. Это как сделать бэкапы и сохранить их на том же хосте.

Так что к Splunk мы приделали также очень богатый функциональностью инфраструктурный мониторинг на базе Prometheus exporter и прикрутили к нему графану.

И это при том, что все машины у нас по историческим причинам ещё и мониторятся при помощи Zabbix. В общем, мы хотели получить больше системных метрик, чтобы определиться, какие лучше и удобнее. Такой набор помогает в ситуациях, когда что-то идет не так.

Для нас самое интересное в мониторинге — количество дескрипторов, Это и коннекты форвардеров к индексеру и открытые файлы индексных директорий (поскольку, как мы знаем, в UNIX всё — файл).

Prometheus process exporter собирает характеристики выполняющихся процессов splunkd, в него можно собрать около 24 метрик. Корневые процессы splunkd порождает множество других процессов — в основном это его помощники, хелперы, которые занимаются разными задачами.

Но Splunk — это не та система, где вы один раз кластер подняли и больше его не трогаете, всё хорошо работает. При этом Splunk беспощаден — он не прощает ошибок, и это оказалось в нашей ситуации ключевым. В какой-то момент мы увидели множество разнообразных «горок» среди разных системных метрик, в частности в количествах открытых файловых дескрипторов. Я выбрала лучшие картинки из тех, которые нам удалось сохранить той зимой:

Мы наблюдали горки, которые медленно поднимались, а у пользователей это были медленные поиски
Мы наблюдали горки, которые медленно поднимались, а у пользователей это были медленные поиски

При этом в самой системе периодически, на каком-нибудь индексере, аварийно прерывался корневой процесс splunkd. Конечно, мы сделали скрипт-супервизор, автоматически поднимающий сервис Splunk, но это был уже костыль. Из-за того, что были задержки с приходом данных срабатывали ложные алерты, а злые пользователи (очень злые) каждый раз писали: «Что, Splunk умер?!»

Внутренний health check, который есть в Splunk, показал, что было создано очень большое количество маленьких бакетов:

Health check с индексера показывает, что с бакетами что-то не так
Health check с индексера показывает, что с бакетами что-то не так

Но причиной мог быть как сбой, из-за чего и увеличился поток данных, так и «исторически сложившаяся ситуация». Вопрос — что было не так? Как так исторически сложилось?

Эти новые решения класса _подставить_нужное_ – только очередная трата денег

А может построим ИБ без технических средств? Есть оценка рисков, вы вольны выбрать одну из стратегий: избегание, минимизация, передача и принятие. По какой-то логике вы выбираете минимизацию. Дальше уже не важно, как вы будете её реализовывать. Чью экспертизу задействовать – положитесь на защиту от вредоносов с помощью антивирусов, будете пытаться блокировать их на подлёте, внедрив решение типа IPS, или выберете гибридный вариант?

Будут ваши затраты входить в CAPEX из-за внедрения средства защиты в инфраструктуре предприятия или весь ЦОД, вместе с системами обеспечения безопасности, поедет в облако, попадая в OPEX? Доверитесь встроенным решениям от облачного провайдера, или, уйдя в облака, предпочтёте наложенные средства?

Хотя важен не подход, а результат, лучший вариант – соблюдение баланса между трудозатратами сотрудников и использованием систем защиты. Можно пытаться обходиться без технических решений. Но если компания развивается и растёт, то растут и риски, как качественно, так и количественно.

А вслед за ними – желание этими рисками управлять. В том числе, за счёт улучшения качества мониторинга – увеличения его «площади» (сегментов сети, тактик, техник) и «глубины» (не очевидное использование тех же техник, уменьшение порогов срабатывания).

Автоматизировать те, и только те процессы, которые достигли зрелости – хорошая идея. Да, на начальном этапе это трудозатраты и дополнительные требования к персоналу. Но после выполнения проекта подход приносит плоды в части операционных затрат. Другой ответ на вопрос «зачем» – не устраивает время реакции на инцидент.

Важно отличать полезное, новое техническое средство от ребрендинга чего-то старого. А систему, которая принесёт вам пользу уже сейчас, от той, которая будет мигать огоньками в стойке. А когда понадобится – устареет.

Перейдем к техническим средствам системы мониторинга.

Язык spl (search processing language)

SPL связывает между собой приложения и REST API, это, если угодно, высокоуровневый протокол доступа к данным внутри Splunk. Я отсортировал фичи этого языка по вау-эффекту. 

Вычисляемые на лету поля. Не знаю, имеется ли в опенсорс-решениях (Kibana, Graylog) какой-то функционал, чтобы прямо на лету в том логе, в котором ты ищешь через вебку или через API, взять и сформировать новые поля без прикручивания какого-то внешнего кода. В Splunk такое есть.

Conditions. В Splunk можно прямо в строке запроса, в отправляемом запросе через API или в создаваемых бордах и отчетах сразу реализовать программу, которая предполагает полноту по Тьюрингу.

Regex. Понятно, куда же без Regex? Опять же в том же Graylog, не знаю, можно ли сходу Regex применить или нет, в Splunk – можно.

Статистические функции. Все, что вы знаете о статистике, реализовано в поисковом ядре Splunk.

Relational operators. В ванильных Kibana или в Graylog, мы не сможем сджойнить таблицы на лету, а Splunk это умеет.

Transactions processing. В Splunk мы можем с целыми транзакциями в логе, раскрашенными одним и тем же айдишником, работать как с отдельной сущностью, определенным образом их объединять и т.д.

Predictions. Это вообще замечательно, дальше уже идет Machine Learning. Кстати, в Splunk есть множество расширений и с функционалом ML, таким образом мы можем предсказывать что-то.

UI. UI удобный, и мы знаем, что это так. Потому что у нас огромное количество пользователей приходит каждый день и начинает его шатать. Можно сделать алерты, отчёты и реалтайм-дашборды на том самом языке SPL, даже без необходимости писать расширения, которые я описал в самом начале.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *