Размещено на http://www.allbest.ru/

Оглавление

• Введение
• Глава 1. Анализ процессов и существующих программных средств мониторинга и управления событиями
• 1.1 Транзакционные и потоковые системы
• 1.2 Мониторинг информационных систем
• 1.3 Журналирование событий ИТ-инфраструктуры
• 1.4.1 Adiscon LogAnalyzer
• 1.4.2 Splunk Enterprise
• 1.4.3 IBM InfoShpere BigInsights
• 1.4.4 Комплекс Fluentd/Logstash, ElasticSearch, Kibana
• 1.5 Выводы по главе 1
• Глава 2. Основные принципы, модели и методы выявления причинно-следственных отношений между событиями в ИТ-инфраструктуре
• 2.1 Архитектура централизованного журналирования
• 2.2 Выявление шаблонов сообщений
• 2.3 Машинное обучение
• 2.4 Выводы по главе 2
• Глава 3. Программное обеспечение информационно-аналитической системы выявления причинно-следственных связей между событиями
• 3.1 Архитектура информационно-аналитической системы
• 3.2 Технологии и средства программной реализации информационно-аналитической системы
• 3.2.1 Rsyslog
• 3.2.2 Java Standard Edition
• 3.2.3 Standard Widget Toolkit
• 3.2.4 JSON. Simple
• 3.2.5 WEKA
• 3.3 Компоненты информационно-аналитической системы
• 3.3.1 Настройка сервера Rsyslog
• 3.3.2 Обучаемый парсер
• 3.3.3 Аналитическая модель в WEKA
• 3.3.4 Пользовательский компонент инженера
• 3.4 Выводы по главе 3
• Глава 4. Опытная эксплуатация информационно-аналитической системы выявления причинно-следственных связей между событиями
• 4.1 Апробация централизованного журналирования
• 4.2 Апробация обучаемого парсера
• 4.3 Апробация ядра логического вывода в пользовательском компоненте инженера
• 4.4 Выводы по главе 4
• Заключение
• Литература

Введение

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

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

· обнаружение факта существования проблемы;

· диагностика, определение затронутых сервисов и систем, а также возникающих эффектов;

· поиск причины, вызвавшей проблему;

· поиск возможных решений;

· определение необходимых действий для устранения проблемы;

· выполнение операций, необходимых для устранения проблемы.

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

Современные информационные системы, предоставляющие необходимые бизнесу сервисы, отличаются большим уровнем сложности: они многокомпонентны, зачастую компоненты распределены в вычислительной сети и взаимодействуют друг с другом при помощи различных технологий и протоколов передачи данных. Кроме того, работа одних систем, как правило, опирается на работу других систем, например, доступ к веб-ресурсам по URI опирается на систему DNS, а также на систему, предоставляющую эти ресурсы - веб-сервер, который в свою очередь опирается на сервер приложений, запрашивающий информацию в базах данных сервера баз данных (классическая веб-система). Как видно из приведённого примера, несмотря на определённую автономность и модульность, информационные системы очень тесно связаны между собой, что делает поиск причин неисправностей, поиск решений и другие задачи достаточно трудными, под силу лишь высококвалифицированным инженерам с обширным опытом.

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

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

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

Указанные выше особенности: большое количество анализируемой информации, неструктурированные тексты журналов, полнотекстовый поиск, необходимость в предсказании неисправностей - делают проблематичным применение привычных подходов к автоматизации. С другой стороны, именно из-за этих особенностей применение технологий обработки больших данных (Big Data) и машинного обучения (Machine Learning) видится целесообразным и эффективным.

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

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

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

Для достижения поставленной цели в диссертационной работе сформулированы следующие задачи:

1. Провести анализ процессов управления событиями.

2. Провести обзор и сравнение существующих средств обработки и анализа информации о событиях в ИТ-инфраструктуре.

3. Разработать методы сбора информации о событиях в ИТ-инфраструктуре, а также структуру единичного события.

4. Разработать методы по извлечению данных из сообщений о событиях.

5. Разработать модель выявления причинно-следственных связей между событиями.

6. Разработать компоненты информационно-аналитической системы выявления причинно-следственных связей между событиями и обеспечить их связную работу.

7. Исследовать и верифицировать теоретические положения в ходе опытной эксплуатации разработанной информационно-аналитической системы на данных сетевого и серверного оборудованиях Дирекции ИТ НИУ ВШЭ.

Диссертация состоит из введения, четырех глав и заключения.

Введение содержит сформулированные цели и задачи диссертационной работы, обоснование ее актуальности; в нем определены научная новизна, теоретическая и практическая значимость работы, используемые методы проведения исследований, положения, выносимые на защиту. Рассмотрено текущее состояние ряда аспектов исследуемой предметной области, введены основные термины и понятия.

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

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

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

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

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

событие сбор информация инфраструктура

Глава 1. Анализ процессов и существующих программных средств мониторинга и управления событиями

1.1 Транзакционные и потоковые системы

Для обеспечения своей деятельности современные организации создают и используют ИТ-инфраструктуру. Согласно библиотеке ITIL [1] (Information Technology Infrastructure Library - библиотека инфраструктуры информационных технологий), ИТ-инфраструктура включает в себя всё аппаратное и программное обеспечение, сети, инженерное обеспечение и т.п., необходимые для разработки, тестирования, предоставления, мониторинга, контроля или поддержки ИТ-услуг, при этом ИТ-инфраструктура включает в себя все компоненты информационных технологий, но не включает связанные с ними персонал, процессы и документацию.

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

В основе работы транзакционных систем лежит понятие транзакции [1] - набор связанных операций, переводящих систему в новое состояние, причём выполниться должны все операции или не выполниться ни одной. Схема процесса работы такой системы в нотации BPMN 2.0 [2] показана на рисунке 1.

Рисунок 1. Схема процесса работы транзакционной системы

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

Примерами транзакционных систем являются СУБД и системы, построенные на их основе: Интернет-магазины, системы электронных платежей, и др.

Потоковые системы характеризуются работой с потоками сообщений: входящие сообщения обрабатываются системой и передаются далее другим системам. Схема процесса работы такой системы в нотации BPMN 2.0 показана на рисунке 2.

Рисунок 2. Схема процесса работы потоковой системы

Здесь задача "Выбрать действие" обычно реализуется в виде набора правил, на соответствие которым проверяется входящее сообщение и выбирается действие по обработке.

Примером потоковых систем является всё сетевое оборудование: коммутаторы, маршрутизаторы, сетевые фильтры.

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

Управление же потоковыми системами производится в транзакционном режиме (рисунок 1) со всеми его особенностями.

1.2 Мониторинг информационных систем

Состояние систем обоих типов необходимо постоянно отслеживать, чтобы оперативно решать возникающие инциденты. Для этого организуются системы мониторинга. Данные системы являются клиент-серверными [3], клиентская часть называется агент мониторинга, устанавливается на наблюдаемую систему и занимается отслеживанием этой системы и выполнением команд серверной части - узла управления - для управления наблюдаемой системой. Системы мониторинга можно разделить на системы пассивного мониторинга и системы активного мониторинга.

Пассивный мониторинг, согласно [1], это мониторинг конфигурационной единицы, ИТ-услуги или процесса, который основывается на оповещениях или уведомлениях о текущем состоянии. Схема процесса пассивного мониторинга в нотации BPMN 2.0 представлена на рисунке 3.

Рисунок 3. Схема процесса пассивного мониторинга

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

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

Активный мониторинг, согласно [1], это мониторинг конфигурационных единиц или ИТ-услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объекта мониторинга. Схема процесса активного мониторинга в нотации BPMN 2.0 представлена на рисунке 4.

Рисунок 4. Схема процесса активного мониторинга

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

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

1.3 Журналирование событий ИТ-инфраструктуры

Зачастую мониторинг ИТ-инфраструктуры заканчивается на развёртывании систем активного и/или пассивного мониторинга и оповещении ответственных.

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

Они не могут сказать ничего о внутреннем состоянии наблюдаемой системы, так как аспекты её работы сокрыты внутри неё. Чтобы всё же иметь возможность как-то отслеживать внутреннюю работу информационной системы, разработчик встраивает в неё подсистему журналирования и оповещения. Тогда, по мере работы информационной системы, возникающие в ней события заносятся в системный журнал и/или передаются на центральный сервер журналирования [4]. Схема такого централизированного процесса журналирования в нотации BPMN 2.0 показана на рисунке 5.

Рисунок 5. Схема процесса централизованного журналирования

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

1.4 Существующие средства анализа информации о событиях

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

Рисунок 6. Схема процесса работы инженера по восстановлению нормального состояния

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

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

1.4.1 Adiscon LogAnalyzer

Adiscon LogAnalyzer [5] - система построения отчётности на основе информации, полученной по протоколу Syslog [4]. Интерфейс системы показан на рисунке 7.

Рисунок 7. Интерфейс Adiscon LogAnalyzer

Данная система позволяет просматривать зарегистрированные события, производить поиск в собранной информации и строить несложные графики. Основное преимущество системы - наличие базы знаний [6] (ссылка на http://kb. monitorware.com/), представляющую собой Интернет-форум.

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

1.4.2 Splunk Enterprise

Splunk Enterprise [7] - система мониторинга поступающих сообщений, построения отчётности и аналитики от компании Splunk.

Данная система является платной, однако имеет приятный веб-интерфейс (рисунок 8), поддерживает большое количество источников информации о событиях, позволяет строить различные графики, отчёты и панели индикаторов (dashboard).

Кроме этого в Splunk встроен гибкий полнотекстовый поиск, позволяющий выполнять гранулированный поиск и фильтрацию информации.

Рисунок 8. Интерфейс Splunk Enterprise

Так же, как и Adiscon LogAnalyzer, Splunk не имеет встроенных средств для выявления причинно-следственных связей или проведения корреляционного анализа.

1.4.3 IBM InfoShpere BigInsights

IBM InfoSphere BigInsights [8] является платформой для распределённых вычислений на базе Apache Hadoop [9], обработка информации на которой выполняется согласно парадигме MapReduce. По сравнению с стандартной платформой Apache Hadoop IBM InfoSphere BigInsights включает в себя графический веб-интерфейс для администрирования кластера серверов Hadoop, работой с распределённой файловой системой (Hadoop Distributed File System, HDFS), приложениями и дополнительным инструментом для проведения предварительной аналитики BigSheets. На рисунке 9 показан стартовый экран веб интерфейса IBM InfoSphere BigInsights.

Рисунок 9. Стартовый экран веб-интерфейса IBM InfoSphere BigInsights Enterprise Edition

В дополнение к указанным преимуществам используемый IBM InfoSphere BigInsights Enterprise Edition поставляется с комплектом программ ускорения анализа машинных данных (Machine Data Accelerators). Данные программы позволяют организовать разбор загруженных в BigInsights системных журналов определённых типов, строить индексы и выполнять полнотекстовый поиск, выполнять частотный и корреляционный анализ. В стандартную поставку IBM InfoSphere BigInsights Enterprise Edition входят разборщики следующих типов журналов:

· Delimiter Separated Value

· Hadoop Data Node

· Data Power

· Generic

· Hadoop Jobtracker

· Hadoop Name Node

· Hadoop Secondary Name Node

· Syslog

· Hadoop Task Attempt

· Hadoop Task Tracker

· WebSphere Application Server

· Apache Webaccess

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

Как можно заметить, список поддерживаемых "из коробки" типов журналов весьма ограничен и специфичен. Опыты с различными журналами операционной системы IBM z/OS показали, что применение IBM BigInsights для анализа произвольных журналов весьма затруднительно, а получаемые результаты не позволяют делать каких-либо выводов о причинно-следственных связях (рисунок 10).

Рисунок 10. Таблица сопряжённости значений параметров Pattern и RecordType

1.4.4 Комплекс Fluentd/Logstash, ElasticSearch, Kibana

Данный комплекс открытых программных средств представляет собой альтернативу решению Splunk, рассмотренному в пункте 1.4.2.

Программное обеспечение Fluentd [10] - гибкое расширяемое за счёт плагинов решение по сбору журналов с конечных информационных систем и передаче их на центральный сервер.

Программное обеспечение Logstash [11] является аналогом Fluentd и так же обеспечивает транспорт сообщений от конечной системы к центральному серверу журналирования.

ElasticSearch [12] - программное обеспечение индексации и полнотекстового поиска на базе движка Apache Lucene [13].

Kibana [14] - веб-интерфейс к ElasticSearch, позволяющий просматривать информацию, применять к ней фильтры, выполнять поисковые запросы и строить графики.

Общая схема работы комплекса показана на рисунке 11.

Рисунок 11. Схема потоков данных комплекса Fluend/ElasticSearch/Kibana

Комплекс работает следующим образом: с помощью агента Fluentd/Logstash забирают сообщения о событиях с целевых систем и доставляют на центральный узел журналирования, где они отдаются ElasticSearch для индексации. Доступ к данным производится через интерфейс Kibana (рисунок 12).

Рисунок 12. Интерфейс Kibana

Так же, как Adiscon LogAnalyzer и Splunk, описанный комплекс не имеет встроенных средств для выявления причинно-следственных связей или проведения корреляционного анализа.

1.5 Выводы по главе 1

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

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

Учитывая вышесказанное, для повышения эффективности работы ответственных инженеров, сокращения времени на выявление причин возникновения событий в ИТ-инфраструктуре и выработки ответных действий было принято решение собственную создать информационно-аналитическую систему (ИАС) обработки сообщений о событиях, схема работы которой показана на рисунке 13.

Рисунок 13. Схема процесса работы инфрмационно-аналитической системы обработки сообщений о событиях

Глава 2. Основные принципы, модели и методы выявления причинно-следственных отношений между событиями в ИТ-инфраструктуре

2.1 Архитектура централизованного журналирования

Построение ИТ-инфраструктуры с централизованным журналированием означает создание некоторого узла, на который будут стекаться сообщения всех информационных систем и сервисов для хранения, обработки и доступа к ним. Различные вопросы, связанные с журналирование хорошо рассмотрены в работе [15]. Очевидным плюсом централизованного подхода является создание "единой точки входа" для системных администраторов и аналитических систем - вся информация хранится в одном месте. Так как в единицу времени в любой ИТ-инфраструктуре происходит огромное количество событий, централизация влечёт за собой повышенные требования к аппаратному и программному обеспечению центрального хранилища в отношении отказоустойчивости и производительности, требование постоянной доступности и надёжной передачи сообщений журналов.

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

Уже было упомянуто, что одним из требований к централизованному журналированию является надёжный протокол транспорта сообщений. С другой стороны, этот надёжный протокол должен поддерживаться широким спектром программного обеспечения, операционных систем и аппаратных систем. Исторически же сложилось так, что широко распространённым протоколом транспорта сообщений журналов стал ненадёжный протокол прикладного уровня Syslog [4], т.к. он работает поверх протокола UDP для обеспечения производительности и скорости передачи. Протоколы надёжной передачи сообщений журналов существуют, но широкого распространения не получили. Поэтому, несмотря на уже перечисленные недостатки протокола Syslog, а также недостатки, описанные в последующих пунктах, основой централизованного журналирования в данной работе выбран именно протокол Syslog.

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

1. Немедленная отправка сообщений конечной системой.

2. Периодический сбор журналов центральным сервером.

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

Рисунок 14. Централизация путём немедленной отправки сообщений конечной системой

Второй подход - с периодическим сбором журналов - показан на рисунке 15. Здесь центральный сервер раз в некоторый период времени по защищённому протоколу, например FTP/S, SSH, SFTP, подключается к конечной системе и забирает накопившиеся сообщения в хранилище. Так как соединения инициируются сервером изнутри, то они беспрепятственно проходят через сетевой фильтр, таким образом ликвидируется необходимость в потенциально опасном разрешающем правиле для сообщений Syslog. Также появляется возможность отслеживать доступность конечных систем. С другой стороны, данный подход требует постоянного обновления конфигурационной информации центрального - списка опрашиваемых конечных систем; первый подход напротив предполагает настроить центральный сервер один раз, а на конечных системах указывать IP-адрес сервера журналирования.

Рисунок 15. Централизация путём периодического сбора сообщений центральным сервером

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

Рисунок 16. Смешанная схема централизации журналирования

2.2 Выявление шаблонов сообщений

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

Однако задачу разбора сообщений журналов и выявления из них важных значений - парсинг (parsing) - решать нужно. Для того, чтобы из некоторой строки выделить необходимую информацию, нужно знать структуру этой строки, т.е. её шаблон. Шаблоном называется строка, состоящая из неизменяющихся, постоянных для однотипных строк участков, и переменных подстрок - местозаполнителей (placeholder). Для того, чтобы различать местозаполнители, их обычно именуют. В рамках данной работы шаблоны будут иметь следующий вид:

" {sophos_internal_id}: client=unknown [{ip_address}] "

где {sophos_internal_id}, {ip_address} - именованные местозаполнители, остальная показанного часть шаблона неизменна.

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

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

Для оценки похожести строк существует ряд широко известных метрик, алгоритмов их расчёта и кодов, реализующих эти алгоритмы на разных языках программирования. Вся эта информация представлена соответствующем разделе открытой энциклопедии Википедия [18]. Ввиду необходимости сравнения строк разной длины подходящими метриками оказались расстояние Левенштейна [19] и коэффициент перекрытия (мера Шимкевича-Симпсона) [20]. Ввиду того, что расстояние Левенштейна плохо работает на длинных строках и хорошо на коротких, а коэффициент перекрытия наоборот - хорошо на длинных и плохо на коротких, то было принято решение использовать обе метрики: расстояние Левенштейна на строках длиной менее 200 символов (округлённая средняя длина сообщения) и коэффициент перекрытия на строках длиной более 200 символов.

Для выявления общей части для группы похожих строк предлагается использовать вычисление наибольшей общей подпоследовательности символов (longest common subsequence, LCS) [21] в строках группы.

Таким образом, для выявления шаблона сообщений имеем следующий алгоритм:

1. Среди полученных на центральный сервер сообщений формируем группу похожих, для расчёта "похожести" сообщений используем описанные выше метрики - расстояние Левенштейна и коэффициент перекрытия.

2. Для группы похожих строк вычисляется LCS.

3. Путём посимвольного сравнения LCS и строк группы формируем шаблон группы сообщений, в качестве местозаполнителей используем последовательность {i}, где i - порядковый номер (индекс) местозаполнителя начиная с 0.

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

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

2.3 Машинное обучение

После того, как сформировано ядро разбора, из поступающих сообщений можно выделить значимые данные: IP-адреса, имена узлов, названия приложений и прочее. Кроме этого сам шаблон сообщения позволяет судить о семантике группы сообщений. Эти данные вместе с служебными данными протокола Syslog (временные метки, приоритет/важность, пользовательские метки и пр.) формируют массив данных для анализа, целью которого является обнаружить причинно-следственные отношения между зафиксированными событиями.

Вопрос определения причинности уходит своими корнями в античную философию и до сих пор является актуальным. Для данной работы существенным являются его следующие аспекты:

1. Причина всегда предшествует следствию. Это означает, что поиски причины конкретного события следует искать лишь в предшествующих событиях.

2. Причиной может быть как наличие, так и отсутствие одного или ряда событий.

3. Отношение причинности регулярно и объективно. Это значит, что если событие А вызвало событие В один раз, то повторение события А в тех же условиях должно вновь вызвать событие В. Таким образом корреляция событий А и В позволяет предположить, но не гарантирует наличие между ними причинно-следственной связи.

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

5. Часть событий не будет иметь зажурналированного события-причины, так как порождены внешними воздействиями - неподконтрольными системами или человеком.

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

В качестве основного здесь выступают пункты 1 и 3, т.е. в рамках работы предлагается обнаруживать регулярные связи между событиями и однотипные регулярные последовательности событий. Соответствующий механизм предлагает раздел машинного обучения без учителя "Поиск ассоциативных правил" [22]. Задача поиска ассоциативных правил (association rules learning) формулируется следующим образом: исходные данные представляются в виде признаковых описаний. Требуется найти такие наборы признаков, и такие значения этих признаков, которые особенно часто (неслучайно часто) встречаются в признаковых описаниях объектов. Набор правил, полученный по доступным аналитическим моделям, будет использован в построении цепочек событий и выявлении событий-причин.

Очевидно, что одних статистически подтверждённых связей недостаточно - нужна база экспертных знаний в области построения информационных систем и их взаимодействия. Основы для такой базы знаний в виде онтологии заложены в работе [23]. Однако создание этой базы знаний - отдельный большой проект, поэтому не включён в данную работу.

2.4 Выводы по главе 2

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

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

Было дано определение понятия "шаблон" строки и описан алгоритм по его генерированию, а также ряд сопутствующих рекомендаций.

Кратко рассмотрены особенности отношения причинности. В качестве механизма выявления причинно-следственных связей выбран подход на основе поиска ассоциативных правил.

Одним из дальнейших направлений развития данной работы обозначена разработка собственной модели ассоциативных правил с учётом экспертных знаний об устройстве и взаимодействии информационных систем и их компонент.

Глава 3. Программное обеспечение информационно-аналитической системы выявления причинно-следственных связей между событиями

3.1 Архитектура информационно-аналитической системы

Как уже ранее было сказано в пункте 1.2 для отслеживания существующих информационных систем и сервисов в организациях выполняют развёртывание системы мониторинга. Схематично потоки информации для этого случая показаны на рисунке 17.

Рисунок 17. Мониторинг и анализ журналов без ИАС

Для повышения эффективности работы ответственных инженеров, сокращения времени на выявление причин возникновения событий в ИТ-инфраструктуре и выработки ответных действий была создана информационно-аналитическую система (ИАС) выявления причинно-следственных отношений между событиями.

Данная система предполагает работу совместно с существующими системами мониторинга: мониторинг отслеживает состояние, а ИАС выявляет цепочки событий, связанных отношением причинности. Общая схема работы системы показана на рисунке 18.

Рисунок 18. Общая схема работы информационно-аналитической системы

Как следует из схемы работы ИАС владеет сведениями о событиях во всей ИТ-инфраструктуре и обучается по мере работы. Обученная система используется в работе инженеров технической поддержки.

В своей работе ИАС опирается на три основных компонента: централизованное журналирования событий, обучаемый парсер и аналитическая модель. Архитектура ИАС и используемые протоколы изображены на рисунке 19.

Рисунок 19. Архитектура ИАС и используемые протоколы

Как показано на рисунке 19 ИАС выступает в качестве сервера журналирования в централизованной архитектуре журналирования, выполненной в соответствии с подходом "немедленной отправки" (раздел 2.1). Кроме этого стандарт RFC 5675 [24] определяет правила трансляции сообщений SNMP в сообщения Syslog позволяя транслировать информацию от систем мониторинга в ИАС, чем дополняет информацию о событиях ещё и информацией о состоянии параметров наблюдаемых систем.

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

3.2 Технологии и средства программной реализации информационно-аналитической системы

3.2.1 Rsyslog

Программное обеспечение Rsyslog [25] - популярный Syslog-сервер, являющийся стандартным демоном журналирования в операционных системах Unix и Linux. Своё широкое распространение получил за счёт высокой скорости работы - по утверждению разработчиков "Rocket-fast syslog server" - большому количеству модулей получения сообщений журналов (input module, im, например imtcp - получение стандартных syslog-сообщений по протоколу TCP) и модулей вывода информации (output module, om, например omelasticsearch - передача обработанных сообщений серверу ElasticSearch). Кроме этого Rsyslog может быть расширен самостоятельно разработанными фильтрами и парсерами заранее известных сообщений.

3.2.2 Java Standard Edition

Java Platform, Standard Edition [26] - стандартная версия платформы Java 2, предназначенная для создания и исполнения апплетов и приложений, рассчитанных на индивидуальное пользование или на использование в масштабах малого предприятия. Компания Oracle разрабатывает и поддерживает язык Java, а также предоставляет Java Development Kit (JDK) - набор разработчика на языке Java, для создания кросс-платформенных программ. Кросс-платформенность достигается за счёт использования концепции "виртуальной машины Java" (Java Virtual Machine, JVM) - среды в которой исполняются программы, написанные на языке Java. Поэтому если для платформы (Windows, Linux, Mac OS X, IBM System/z и др.) существует JVM, то код на ней будет исполняться так же, как и в JVM других платформ без необходимости его переработки под целевую платформу.

3.2.3 Standard Widget Toolkit

Открытая библиотека элементов для создания графического пользовательского интерфейса Standard Widget Toolkit (SWT) [27] от Eclipse Foundation является альтернативой стандартным Java-библиотекам графических интерфейсов: Abstract Widget Toolkit (AWT) и Swing. В отличии от перечисленных библиотек целью SWT является создание пользовательских интерфейсов на языке Java максимально похожих на "родные" интерфейсы конечной операционной системы, будь то Windows, Linux или Mac OS X без изменения исходного кода приложения (рисунок 20).

Рисунок 20. SWT-приложение в разных операционных системах

3.2.4 JSON. Simple

JSON. Simple [28] - небольшая (версия 1.1.1 занимает 24 Кбайт), простая и быстрая [29] Java-библиотека для чтения и записи документов в формате JSON [30], работой с JSON-объектами и коллекциями. В отличии от других Java-библиотек для работы JSON не требует установления соответствия JSON-объектов Java-объектам, что позволяет быстро внедрять в приложение работу с JSON без создания дополнительных POJO-классов (Plain Old Java Object, POJO).

3.2.5 WEKA

WEKA [31] - программное обеспечение, разработанное в университете Уайкато Новой Зеландии, для решения задач машинного обучения. Данное ПО является открытым, хорошо документированным аналогом IBM SPSS Statistics [32], разработано на Java, ввиду чего является кроссплатформенным, хорошо интегрируется с другими Java-системами путём подключения только одной библиотеки weka. jar. Кроме этого WEKA может быть запущено как настольное Java-приложение в четырёх режимах:

1. WEKA Explorer.

2. WEKA Experimenter.

3. WEKA Knowledge Flow.

4. WEKA Simple CLI.

Режим "WEKA Explorer" предназначен для выполнения единичных задач анализа данных, таких как прогнозная аналитика, кластеризация. Исходными данными могут быть локальные файлы и файлы в сети, а также базы данных с поддержкой подключения JDBC (Java Database Connectivity). Присутствует функциональность оценки прогнозных моделей, кросс-валидация. Интерфейс режима "WEKA Explorer" показан на рисунке 21.

Рисунок 21. Интерфейс WEKA Explorer

Вторым режимом является "WEKA Experimenter", предназначенный для проведения экспериментов путём задействования нескольких прогнозных моделей и сравнения их между собой. Подготовленный для названных целей интерфейс "WEKA Experimenter" показан на рисунке 22.

Рисунок 22. Интерфейс WEKA Experimenter

Режим "WEKA Knowledge Flow" предназначен для графического моделирования и анализа данных, которое аналогично по функциональности режиму "WEKA Explorer", однако следует идеологии потока исполнения: элементы модели объединяются в цепочку, образуя поток информации, - аналогичный принцип моделирования заложен в IBM SPSS Statistics. Интерфейс "WEKA Knowledge Flow" и пример модели показаны на рисунке 23.

Рисунок 23. Интерфейс WEKA Knowledge Flow

Последним, наиболее аскетичным, но не менее функциональным является режим командной строки (Command Line Interface). Данный режим предполагает непосредственный ввод команд, запускающих прогнозные модели на указанных данных и с указанными параметрами. Выходная информация, выдаваемая в консоль, аналогична представляемой графическими интерфейсами WEKA. Именно этот режим следует использовать для интеграции с другими, не-Java системами.

Рисунок 24. Интерфейс WEKA Simple CLI

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

3.3 Компоненты информационно-аналитической системы

3.3.1 Настройка сервера Rsyslog

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

1. Активирован приём сообщений по сети по протоколам TCP/UDP. Для этого в раздел "MODULES" внесены/разблокированы следующие строки

# Provides UDP syslog reception

$ModLoad imudp

$UDPServerRun 514

# Provides TCP syslog reception

$ModLoad imtcp

$InputTCPServerRun 514

2. В том же разделе "MODULES" объявлен шаблон, преобразующий полученные сообщения в формат JSON.

# This is json-format template

template (name="json_log" type="list") {

constant (value="{") constant (value="\n")

# when

constant (value="\t\"timegenerated-rfc-3339\": \"") property (name="timegenerated" dateFormat="rfc3339" format="jsonr") constant (value="\"\n")

constant (value="\t") property (name="timegenerated" format="jsonfr") constant (value="\n")

constant (value="\t\"timereported-rfc-3339\": \"") property (name="timereported" dateFormat="rfc3339" format="jsonr") constant (value="\"\n")

constant (value="\t") property (name="timereported" format="jsonfr") constant (value="\n")

# where

constant (value="\t") property (name="hostname" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="fromhost" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="fromhost-ip" format="jsonfr") constant (value="\n")

# what component

constant (value="\t") property (name="syslogtag" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="programname" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="procid" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="app-name" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="pri-text" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="pri" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="syslogfacility-text" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="syslogfacility" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="syslogseverity-text" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="syslogseverity" format="jsonfr") constant (value="\n")

# what happend

constant (value="\t") property (name="uuid" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="msgid" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="msg" format="jsonfr") constant (value="\n")

constant (value="\t") property (name="structured-data" format="jsonfr") constant (value="\n")

constant (value="}")

constant (value="\n")

}

3. Первой строчкой в раздел "RULES" добавлена директива, сохранять все сообщения в формате, объявленном на шаге 2.

#### RULES ####

# log evetything to special special json-file

*. * /var/log/my_all_messages2. json; json_log

4. После внесения изменения сервер Rsyslog был перезагружен.

В результате описанных действий все сообщения, обрабатываемые Rsyslog записываются в указанный файл "/var/log/my_all_messages2. json" (для ОС Linux) в следующем виде:

{

"timegenerated-rfc-3339": "2016-01-09T03: 36: 03.637195+03: 00"

"timegenerated": "Jan 9 03: 36: 03"

"timereported-rfc-3339": "2016-01-09T00: 36: 04+03: 00"

"timereported": "Jan 9 00: 36: 04"

"hostname": "ms-frontend1"

"fromhost": "192.168.0.129"

"fromhost-ip": "192.168.0.129"

"syslogtag": "postfix\/smtpd [86372]: "

"programname": "postfix"

"procid": "86372"

"app-name": "postfix"

"pri-text": "mail. info"

"pri": "22"

"syslogfacility-text": "mail"

"syslogfacility": "2"

"syslogseverity-text": "info"

"syslogseverity": "6"

"uuid": "76DFD6B0820849F195D84E86640D76E9"

"msgid": "-"

"msg": " 2D3EE184B130_69055F4F: client=unknown [192.166.219.9] "

"structured-data": "-"

}

3.3.2 Обучаемый парсер

Обучаемый разборщик (парсер) построен на основе принципов, описанных в разделе 2.2 Обучаемый разборщик решает две задачи:

1. Позволяет в автоматизированном режиме выявлять шаблоны сообщений, формируя набор шаблонов - ядро разбора.

2. Выполняет разбор сообщений с помощью настроенного ядра разбора.

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

Рисунок 25. Процесс обучения разборщикаформирования ядра разбора

Процесс построения/дообучения ядра разбора также является итерационным. Схема этого процесса показана на рисунке 26. Данная схема реализуется в процессе работы шаблонопостроителя.