Файл: Удаленные программные средства первичной.pdf

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 – Технический аспект сравнительного анализа

15
В ходе проведения сравнительного анализа было выявлено, что все рассмотренные аналоги имеют поддержку Push-метода обмена сообщениями вида JSON. Prometheus также имеет поддержку Pull-метода обмена сообщениями. Ganglia поддерживает обмен сообщениями вида CSV.
Prometheus и Ganglia имеют модули анализа данных. Однако все три сервиса поддерживают только ограниченную коллекцию типов событий, что накладывает ограничение на область их применения.
1.3 Постановка задачи на разработку
Целью выпускной квалификационной работы является разработка удаленных программных средств (ПС) первичной обработки и передачи сообщений в составе платформы журнализации. Система доставки сообщений должна быть спроектирована с использованием клиент-серверной архитектуры. Для ПС необходимо разработать API для взаимодействия с сервером. Разработку системы осуществить с применением объектно- ориентированного языка программирования высокого уровня с кроссплатформенной реализацией.
Данную систему предполагается использовать в качестве сервера доставки сообщений в составе платформы журнализации EventPlatform.
Основной целью разрабатываемого программного комплекса является обеспечение надежного канала связи между удаленными подсистемами и журналом сообщений, используемым при дальнейшем анализе поступающей информации.
Компоненты данной платформы включают в себя сервер приема и обработки сообщений и API для прикладных систем. Требуется спроектировать сетевой протокол для обмена данными между API и сервером приема сообщений.
Так как система, над которой производится наблюдение, не определена – то формат сообщения должен быть максимально прост, гибок и

16 его формирование не должно требовать большого количества вычислительных ресурсов. Предпочтительно использовать общедоступный формат сериализации сообщения для как можно большего охвата операционных систем и устройств для наблюдения.
В связи с сетевой направленностью разрабатываемого комплекса программных средств необходимо уделить должное внимание сохранности передаваемых данных для исключения компрометации и изменения информации в процессе пересылки. Защита может быть обеспечена протоколом SSL (англ. Secure Sockets Layer — уровень защищенных cокетов) или TLS (англ. Transport Layer Security — безопасность транспортного уровня).
В целях обеспечения приемлемой скорости приема и обработки сообщений требуется использовать асинхронную модель обработки данных.
Сообщения необходимо выгружать в журнал сообщений EventPlatform на основе СУБД InterSystems Cache.
Программное средство должно работать под управлением операционных систем (ОС) Windows 7/8/8.1/10 и ОС Linux.
Требуется уделить особое внимание отказоустойчивости платформы.
Платформа должна сохранять работоспособность и обеспечивать восстановление функций в случае отказа или временной недоступности сервера журнализации. Отказ или ошибка в обработке сообщений от одной прикладной системы не должны влиять на работу других цепочек обработки сообщений.
Так как к серверу журнализации EventPlatform может подключаться неограниченное количество экземпляров платформы, то необходимо позаботиться о снижении нагрузки с сервера. Одним из возможных вариантов снижения нагрузки может являться агрегация входящих сообщений по каким-либо признакам.

17
Готовый продукт должен иметь документацию пользователя.
Правильность работы программного средства должна проверяться как с помощью юнит-тестов, так и с помощью ручного тестирования.
Разработка программного средства должна происходить с использованием модульных тестов, проверяющих работу системы с различными тестовыми наборами данных. Необходимо обеспечить как можно большее покрытие кода юнит-тестами.
Для проверки корректного выполнения задач в режиме ручного тестирования должен быть разработан пример прикладной системы, отправляющей различные типы сообщений.
Ручное тестирование программного средства должно осуществляться путем выполнения тестовых примеров и сравнения выходных данных с ожидаемыми результатами.
1.4 Планирование разработки и оценки бюджета
1.4.1 Планирование разработки проекта
Для планирования разработки проектов отлично подходит диаграмма
Ганта. Диаграмма Ганта до сих пор остается важным инструментом управления. Она обеспечивает графическое отображение плана работ, удобное для контроля и отслеживания прогресса выполненных задач [6].
Диаграмма Гантта (англ. Gantt chart, также ленточная диаграмма, график Гантта, календарный график) — это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов. Используется в приложениях по управлению проектами [6].
На данном этапе была построена диаграмма Ганта, отображенная на рисунке 2.

18
Рисунок 2 – Диаграмма Ганта
Из построенной диаграммы видно, что основную часть разработки проекта составляют кодирование и тестирование.
1.4.2 Функционально-стоимостной анализ разработки проекта
Функционально-стоимостной анализ предназначен для описания существующих процессов в некоторой области, взаимодействий объектов, участвующих в таких процессах и расчета стоимости процессов.
Методология и графическая нотация IDEF0 описывает один из способов формализации и описания бизнес-процессов. Существует множество специальных программных пакетов для анализа и построения диаграмм; в данной работе использовалась программная среда для построения диаграмм
AllFusion Process Modeler r7 (также известная как BPWin).
На рисунке 3 представлена контекстная диаграмма бизнес-процесса
«Выполнение дипломного проектирования» и определена его стоимость.
Для дальнейшей формализации процесса «Дипломное проектирование» необходимо провести его декомпозицию. Результаты декомпозиции изображены на рисунке 4.
В процессе проектирования было выделено шесть составляющих бизнес-процессов: «Анализ существующих систем», «Анализ технического задания», «Проектирование», «Разработка и написание ПЗ», «Тестирование» и «Защита». Для каждого процесса были определены статьи затрат и стоимость проведения процесса.

19
Рисунок 3 – Контекстная диаграмма «Дипломное проектирование»
Рисунок 4 – Диаграмма декомпозиции процесса «Дипломное проектирование»

20
Был проведен анализ затрат времени на каждый этап для одного работника. Работник выступает в качестве системного аналитика, разработчика и тестировщика программного обеспечения. Основные средства были затрачены на этапах анализа и разработки, т.к. на данных этапах использовалось платное программное обеспечение. Результаты вычислений представлены в таблице 3.
Таблица 3 – Результаты функционально-стоимостного анализа
Этапы
Израсходовано средств
Анализ предметной области и постановка задачи
6150 руб
Анализ требований на разработку
4700 руб
Разработка ПО
7850 руб
Тестирование
2800 руб
Предзащита
0 руб
Итого:
21500 руб
В итоге на разработку удаленных программных средств сервера первичной обработки и передачи сообщений для платформы журнализации
EventPlatform было затрачено 21500 руб.

21
2 Анализ требований к программным средствам
2.1 Архитектура программных средств платформы
журнализации
Платформа журнализации включает в себя следующие элементы:
ー прикладная система;
ー сервер обработки сообщений;
ー сервер журнализации;
ー портал управления.
Сервер обработки сообщений, соединившись с прикладными системами, принимает от них сообщения согласно протоколу по сокету.
Инициатором данного соединения может быть как прикладная система, так и сам сервер обработки сообщений. Далее после первичной обработки сообщений данным сервером и установления соединения с БД журнала событий сообщение через интерфейс БД записывается в БД.
Параллельно с вышеописанным процессом клиенты портала управления могут отправлять запросы серверу CSP согласно протоколу прикладного уровня HTTP и получать обработанные данные из БД в формате HTML.
На рисунке 5 изображена диаграмма развертывания программного средства в нотации UML. Данная диаграмма учитывает взаимосвязи между объектами программного средства и внешними системами. Также данная диаграмма отображает размещение компонентов программного средства относительно физических ЭВМ.
Диаграмма развертывания отражает наиболее типичный сценарий развертывания платфомры, однако возможен вариант, когда любая комбинация систем (в том числе все системы сразу) работает на одной физической ЭВМ.