курсовая приближенно по серверам. Удаленные программные средства первичной
 Скачать 2.16 Mb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ Федеральное государственное бюджетное образовательное учреждение высшего образования « ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ » ПОЛИТЕХНИЧЕСКИЙ ИНСТИТУТ Факультет Кафедра вычислительной техники МОиПЭВМ Направление подготовки 09.03.02 «Информационные системы и технологии» Профиль Проектирование, разработка и эксплуатация информационных систем БАКАЛАВРСКАЯ РАБОТА на тему Удаленные программные средства первичной обработки и передачи сообщений в составе платформы журнализации событий Студент ___________ _Бахитов Альберт Мунирович_ (подпись, дата) (ФИО полностью) Руководитель ___________ ______Шибанов С.В._________ (подпись, дата) (фамилия, инициалы) Нормоконтролёр ___________ _______Попова Н.А._________ (подпись, дата) (фамилия, инициалы) Работа допущена к защите (протокол заседания кафедры от ___________№_____) Заведующий кафедрой __________________ _Макарычев П.П._____ (подпись) (фамилия, инициалы) Работа защищена с отметкой ______ (протокол заседания ГЭК от ______№____) Секретарь ГЭК __________________ ____Попова Н.А.______ (подпись) (фамилия, инициалы) Пенза, 2016 Федеральное государственное бюджетное образовательное учреждение высшего образования ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПОЛИТЕХНИЧЕСКИЙ ИНСТИТУТ Факультет Кафедра Вычислительной техники МО и ПЭВМ «Утверждаю» Заведующий кафедрой ___________П.П. Макарычев «__»_____________2016 г ЗАДАНИЕ НА ВЫПУСКНУЮ КВАЛИФИКАЦИОННУЮ РАБОТУ БАКАЛАВРА 1. Студент Бахитов Альберт Мунирович гр. 12ВИ1 факультета ВТ <Фамилия, имя, отчество полностью> 2.Тема работы Удаленные программные средства первичной обработки и передачи сообщений в составе платформы журнализации событий Тема утверждена приказом ПГУ № 566/0 от "13" 05 2016 2. Руководитель работы к.т.н. доцент Шибанов Сергей Владимирович 3. Задание на работу (назначение разработки, исходные данные и т.п.) Назначение: первичная обработка и передача сообщений серверным программным средствам платформы журнализации событий Основные функции системы: 1. Сбор сообщений от компонентов прикладных систем платформы 2. Первичная обработка сообщений 3. Управление сервером обработки сообщений 4. Передача сообщений серверным программным средствам Технология разработки: ООП Язык программирования: C# Среда программирования: MS Visual Studio 4. Перечень подлежащих разработке вопросов 1. Анализ предметной области и постановка задачи 2. Анализ требований на разработку 3. Разработка программных средств 4. Тестирование программных средств 5. Календарный график выполнения работы № п/п Наименование этапов работы Объем работы Срок выполнения Подпись руководителя 1 Анализ предметной области и постановка задачи 15% С 11 по 13 мая 2 Анализ требований на разработку 10% С 13 по 18 мая 3 Разработка программных средств 40% С 18 по 25 мая 4 Тестирование программных средств 15% С 25 мая по 3 июня 5 Оформление пояснительной записки 20% С 3 по 6 июня Дата выдачи задания "___"_________________20_____ Руководитель бакалаврской работы ____________________________ (подпись, дата) Задание к исполнению принял студент ________________________ (подпись, дата) Работу к защите допустить Декан факультета _____________________________________ (подпись, дата) Реферат Пояснительная записка содержит 85 листов, 22 рисунка, 14 использованных источников, 15 таблиц и 3 приложения. ПРИКЛАДНАЯ СИСТЕМА, ПРОТОКОЛ, СЕРВЕР, ОБМЕН ИНФОРМАЦИЕЙ, ИНТЕРФЕЙС ПРОГРАММИРОВАНИЯ ПРИЛОЖЕНИЙ, СОБЫТИЕ,АСИНХРОННОСТЬ, СИСТЕМА АКТОРОВ, СУБД, CACHE, С#, КОМПОНЕНТ. Объект исследования: удаленные программные средства первичной обработки и передачи сообщений для платформы журнализации событий. Цель работы: разработать удаленные программные средства первичной обработки и передачи сообщений для платформы журнализации событий. Технологии и средства разработки – ООП, СУБД Cache, C#, Visual Studio, MonoDevelop, NUnit. Результат работы: спроектированы и разработаны удаленные программные средства первичной обработки и передачи сообщений серверным программным средствам. Изм. Лист № докум. Подпись Дата Лист 3 ПГУ 09.03.02-8БР121.01 ПЗ Разраб. Бахитов А.М. Провер. Шибанов С.В. Н. Контр. Попова Н.А. Утв. Удаленные программные средства первичной обработки и передачи сообщений в составе платформы журнализации событий Лит Листов 85 гр. 12ВИ1 Содержание Введение ........................................................................................................................ 6 1 Анализ предметной области и постановка задачи ................................................ 8 1.1 Концептуальный анализ предметной области ................................................ 8 1.2 Сравнительный анализ существующих систем удаленной журнализации ............................................................................................................. 10 1.3 Постановка задачи на разработку ................................................................... 15 1.4 Планирование разработки и оценки бюджета .............................................. 17 1.4.1 Планирование разработки проекта................................................................. 17 1.4.2 Функционально-стоимостной анализ разработки проекта .......................... 18 2 Анализ требований к программным средствам .................................................. 21 2.1 Архитектура программных средств платформы журнализации ................. 21 2.2 Функциональные требования ......................................................................... 22 2.3 Выбор технологий и средств разработки ...................................................... 26 2.4 Взаимодействие сервера обработки сообщений с прикладными системами ............................................................................................................. 27 2.4.1 Стратегия получения сообщений от прикладной системы ......................... 27 2.4.2 Выбор формата передаваемого сообщения ................................................... 29 2.4.3 Защита данных при передаче сообщений ...................................................... 30 2.5 Взаимодействие с серверными программными средствами платформы журнализации ............................................................................................................. 33 3 Разработка программных средств сервера сообщений ...................................... 37 3.1 Разработка архитектуры программных средств ........................................... 37 3.1.1 Модель акторов ................................................................................................ 39 3.1.2 Разработка архитектуры сервера на основе модели акторов ...................... 40 3.2 Разработка программных средств сервера обработки сообщений ............. 41 3.2.1 Разработка системы классов сервера ............................................................. 41 3.2.2 Разработка API для прикладных систем ........................................................ 49 3.2.3 Реализация проекта программных средств ................................................... 51 3.3 Разработка панели управления для сервера обработки сообщений ........... 53 4 Тестирование .......................................................................................................... 57 4.1 Выбор методологии тестирования ................................................................. 57 4.2 Компонентное тестирование ........................................................................... 59 Заключение ................................................................................................................. 63 Список использованных источников ....................................................................... 64 Приложение А. Глоссарий ....................................................................................... .66 Приложение Б. Листинг программы ........................................................................ 69 Приложение В. Коды модульных тестов ................................................................. 83 6 Введение В настоящее время информационные системы играют большую роль в нашей жизни. С каждым днем возрастает объем информации, и ужесточаются требования к стабильности систем. Для стабильной работы информационной системы человеку приходится постоянно следить за ее работой. Однако в силу большого объема обрабатываемой информации современные системы нуждаются в автоматизированных сервисах журнализации. Данные сервисы собирают подробную информацию о всех процессах в системе и хранят ее в течение определенного периода времени для последующего анализа и аудита в целях поддержки принятия решений. На современном рынке существует ряд подобных сервисов, однако каждый сервис подходит лишь для ограниченного круга информационных систем, к примеру, операционных систем. Целью выпускной квалификационной работы является разработка программных средств приема и первичной обработки сообщений для платформы журнализации событий. Платформа журнализации событий позволяет расширить круг журнализируемых информационных систем за счет поддержки универсального формата сообщений и возможности хранения правил по его обработке. Для достижения поставленной цели были определены и решены следующие задачи: ー анализ предметной области; ー анализ требований к программным средствам; ー разработка программных средств сервера обработки сообщений; ー тестирование разработанных программных средств. В ходе выполнения поставленных задач был проведен анализ существующих средств журнализации событий, исследованы подходы к 7 обмену сообщениями по сети, были определены варианты использования и разработана архитектура сервера обработки сообщений в рамках функциональности платформы журнализации событий. В результате были разработаны программные средства первичной обработки и передачи сообщений в составе платформы журнализации событий, а именно: ー сервер обработки сообщений; ー панель управления сервером обработки сообщений; ー API для прикладных систем; ー приложение прикладной системы. Разработанный прототип в дальнейшем может быть усовершенствован внедрением двусторонней связи между прикладной системой и сервером журнализации, что позволит не только журналировать информацию, но и автоматически регулировать работу прикладных систем на основе поступившей информации. 8 1 Анализ предметной области и постановка задачи 1.1 Концептуальный анализ предметной области В ходе анализа предметной области были выделены основные концептуальные классы. На рисунке 1 изображена концептуальная диаграмма предметной области. Основными классами предметной области являются прикладная система, API (англ. Application Programming Interface – интерфейс программирования приложений), обеспечивающая интерфейс между прикладной системой и платформой, сервер обработки сообщений и БД журнала сообщений, в которой сохраняется информация о поступивших от прикладных систем сообщениях. Основным процессом в анализируемой предметной области является процесс передачи, получения и сохранения данных в форме сообщений. Рисунок 1 – Диаграмма концептуальных классов предметной области Процесс инициируется прикладной системой при наступлении какого- либо события, требующего журнализации. 9 Процесс передачи сообщения включает в себя его кодирование (преобразование в форму, интерпретируемую получателем), передачу сообщения каким-либо образом к получателю и его декодирование. В информатике понятие кодирования часто замещается понятием сериализации. Сериализацией является процесс перевода какой-либо структуры данных в битовое представление, удобное для хранения и/или передачи. Обратной операцией по отношению к сериализации является десериализация. Для успешной передачи сообщения необходимо, чтобы получателю был известен способ десериализации сообщения. В случае успешной передачи сериализованного сообщения полученный объект будет идентичен исходному. Так как у каждого формата сериализации есть свои плюсы и минусы, то при проектировании ПО важно выбрать формат сериализации, максимально подходящий предметной области и предполагаемому формату сообщений. Поскольку предметная область системы журнализации, в которую входит разрабатываемая платформа, не определена, то формат сообщений, обрабатываемых системой, должен быть как можно более гибок. Каждый тип сообщения может иметь определенную структуру, но для разных типов сообщения формат и состав сообщения различны. Передача сформированного сообщения может производиться многими способами, например, через именованные каналы (в пределах одной системы), с использованием последовательного порта (от простых микроконтроллеров к компьютеру) или других интерфейсов, по сети и т.д. Так как подсистемы и их объекты могут быть территориально разделены друг от друга, то вся информация должна пересылаться по стандартным сетям обмена информацией. 10 После получения сообщения получатель десериализует его, проверяет целостность (при наличии контрольных сумм или аналога) и использует готовый объект. Как правило, системы журнализации сохраняют полученный объект в БД (специализированной или общего назначения) для дальнейшего анализа данных. Журнализацию можно считать критичным процессом. Если в какой- либо подсистеме случается фатальная для него ошибка, а журнал не успел сохранить последние данные, то понять, в какой части подсистемы случился сбой и что его вызвало, становится гораздо сложнее. Поэтому при проектировании такой платформы необходимо уделить должное внимание ее отказоустойчивости и скорости обработки сообщений. Для отказоустойчивости применяется обработка исключений и кластеризация платформы, а для обеспечения адекватной скорости – обработки сообщений используют асинхронную обработку данных (отдельных сообщений). Асинхронная обработка данных представляет собой обработку информации независимо от состояния основного потока программы. Время обработки единицы данных в асинхронном режиме не зависит от времени обработки других единиц, т.е. обработка одного сообщения может быть начата до конца обработки предыдущего. При правильной асинхронной обработке входящих данных платформа журнализации будет готова к приему следующего сообщения через микросекунды после начала приема предыдущего. 1.2 Сравнительный анализ существующих систем удаленной журнализации Сравнительный анализ аналогов позволяет повысить точность оценки объема предстоящих работ и выделить преимущества и недостатки существующих систем, а также изучить различные подходы к задаче. При 11 сравнительном анализе необходимо учитывать, что каждая система разрабатывалась со своими требованиями к функционалу и в своем контексте. Системы журнализации можно классифицировать по способу размещения на локальные системы и удаленные системы. Локальные системы предназначены для сбора и хранения информации от ПО и прикладных программ на отдельной ЭВМ. В данный момент системы данного типа наиболее распространены вследствие их простоты. Локальные системы журнализации встроены практически в каждую ОС, например, стандартная система eventlog в Windows и dmesg в Linux. Часто данные в таких системах хранятся в виде обычных текстовых файлов с целью упрощения доступа к журналу в случае критического сбоя системы. Локальные системы журнализации включают в себя особый подкласс журналов контроля целостности данных, таких, как средства журнализации транзакций СУБД. В таких системах журналы используются для восстановления баз данных в случае логических или физических отказов. Удаленные системы журнализации принимают и обрабатывают сообщения от групп ЭВМ или других устройств. Как правило, сообщения в таких системах передаются по среде связи, таких как сеть или радиоканал. В рамках класса систем удаленной журнализации были рассмотрены некоторые из наиболее популярных систем с открытым исходным кодом: StatsD, Prometheus и Ganglia. StatsD была написана Cal Henderson для Flickr в 2008 году. StatsD является системой сбора статистики и не включает в себя какие-либо средства анализа данных. Все полученные данные выгружаются в специализированные сервисы хранения и обработки данных, например, Brubeck [1]. Протокол StatsD жестко определяет типы метрик, которые прикладная система может отправлять на сервер. Они включают в себя: 12 ー «Gauge» (англ. датчик) – значение какого-либо измерения в момент времени; ー «Counter» (англ. счетчик) – датчик, значение которого вычисляется на сервере, значение которого определяется из дельты значения между предыдущей отправкой и текущим значением; ー «Timer» (англ. таймер) – время, потраченное на какое-либо действие, например отрисовка веб-страницы, причем значение этой метрики не может быть отрицательным; ー «Histogram» (англ. гистограмма) – таймер, частотное распределение которого рассчитывается на сервере; ー «Meter» (англ. измеритель) – измеряет частоту какого-либо события за временной промежуток [2]. Фактически, тип Meter отличается от типа Counter только запретом на отрицательные значения данных. Отправка сообщений инициируется клиентом; клиент присоединяется к серверу и отправляет сообщения согласно протоколу по сокету. Полное описание протокола было составлено Benjamin Black и доступно на GitHub. Система Prometheus была создана в 2012 году в качестве внутренней системы мониторинга проекта SoundCloud, но широкое распространение получил в 2015 году. Его разработали для работы с микросервисной архитектурой. Prometheus в режиме реального времени отслеживает состояние отдельных компонентов и системы в целом [3]. Сервер Prometheus работает автономно и сохраняет все данные в локальной базе данных. Обнаружение сервисов происходит автоматически. Сбор метрик в Prometheus осуществляется с помощью механизма pull и push, когда pull невозможен [3]. Prometheus хранит данные в виде временных рядов – наборов значений, соотнесенных с временной меткой (timestamp). Элемент временного ряда 13 (измерение) состоит из имени метрики, временной метки и пары «ключ- значение» [3]. Поддерживаются следующие типы метрик: ー счетчик (counter) – хранит значения, которые увеличиваются с течением времени (например, количество запросов к серверу); ー шкала (gauge) – хранит значения, которые с течением времени могут как увеличиваться, так и уменьшаться (например, объем используемой оперативной памяти или количество операций ввода-вывода); ー гистограмма (histogram) – хранит информацию об изменении некоторого параметра в течение определенного промежутка (например, общее количество запросов к серверу в период с 11 до 12 часов и количество запросов к этому же серверов в период с 11.30 до 11.40); ー сводка результатов (summary) – как и гистограмма, хранит информацию об изменении значения некоторого параметра за временной интервал, но также позволяет рассчитывать квантили для скользящих временных интервалов [3]. Ganglia – это система мониторинга с открытым исходным кодом, спроектированная для работы с тысячами узлов, изначально разрабатывавшаяся в университете Berkeley. Ganglia проста в установке и использовании. Отличительной ее особенностью является высокая гибкость и масштабируемость [4] Сбор метрик в Ganglia осуществляется с помощью механизма push В состав Ganglia входят следующие компоненты: ー «Ganglia метадемон» – используется для сбора информации и ее отображения на стороне пользователя. По умолчанию для получения данных от других клиентов используется TCP-порт 8651; ー «Ganglia monitoring daemon» – запускается на всех узлах, для которых необходимо собирать статистику. Результаты измерений, собранные 14 мета-демоном, записываются в структурированном виде и могут быть опубликованы произвольному набору доверенных хостов. Формат данных документирован. Эти данные используются для графиков в веб-интерфейсе и информирования событийного мониторинга об аномалиях; ー «Ganglia Web-интерфейс» – используется для отображения данных, хранящихся на gmetad, в графическом веб-интерфейсе с помощью PHP [5]. Результаты сравнительного анализа приведены в виде таблиц. В таблице 1 приведены результаты сравнения способа передачи и вида данных, пересылаемых по сети. Таблица 2 отображает результат сравнения систем с точки зрения функциональных возможностей. Таблица 1 – Технический аспект сравнительного анализа |