Создание инструмента для конфигурирования логирования

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

Оглавление

Введение

1. Техническое задание

1.1 Цель и задачи дипломной работы

2. Потребность в централизованном логировании

2.1 Cloud computing

2.2 Микросервисная архитектура

2.3 Централизованное логирование

2.4 Представление централизованного логирования

3. Требования к технологиям для построения централизованного логирования

4. Изучение логирования в системе

5. Исследование интеграции централизованного логирования

5.1 Исследование технологий

6. Создание инструмента для конфигурирования логирования

6.1 Локальное конфигурирование

6.2 Удалённое конфигурирование

7. Установка и конфигурирование централизованного логирования

7.1 Установка Fluentd

7.2 Установка Elasticsearch

7.3 Установка Kibana

Заключение

Список литературы



Введение

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

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

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

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

Под централизованным логированием понимается процесс агрегации журналов действий (логов) со всех сервисов (компонент) в единое хранилище данных (отдельный сервис). Такой подход к логированию в основном применяется в микросервисной архитектуре, развёрнутой в Cloud.



1. Техническое задание

1.1 Цель и задачи дипломной работы

Дипломная работа разрабатывалась на базе компании NetCracker.

Netcracker Technology - дочерняя компания корпорации NEC, специализирующаяся на создании, внедрении и сопровождении систем эксплуатационной поддержки (OSS), систем поддержки бизнеса (BSS), а также SDN/NFV-решений для операторов связи, крупных предприятий и государственных учреждений.

Компания также предлагает услуги в области профессионального обслуживания (включая консалтинг, внедрение и поддержку) и сервисы по управлению телекоммуникационными процессами.

Моя дипломная работа включает в себя две составляющие, которые, в свою очередь, делятся на более мелкие.

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

Вторая - это воплощение в реальность той функциональности, которая будет разработана, как проект, на первом этапе.

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

1) Узнать, как логирование работает в системе, где разрабатывается инструмент;

2) Предоставлять выбор пакетов для настройки логирования (в этом пункте подразумевается наличие некой страницы, которая будет отображать настройки для компоненты);

3) Уметь отслеживать включенное логирование и предоставлять заранее заданные паттерны логирования для включения (на странице конфигурирования будет изображён паттерн, который обычно используется для конфигурации логирования пакета);

4) Применять настройки логирования к инстансу;

5) Агрегировать логи в центральном или внешнем хранилище (в данном пункте подразумевается собирать все логи с сервисов, и сохранять их на отдельном сервере, сортируя по этим инстансам);

6) Делать это, как минимум, асинхронно и многопоточно;

7) Иметь сервис, который будет уметь выкачивать сротированные логи в центральное хранилище в фоне.



2. Потребность в централизованном логировании

В связи с возрастанием популярности облачных технологий компания NetCracker планирует разворачивать одну из своих платформ с использованием технологии Cloud.

2.1 Cloud computing

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

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

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

Преимуществами данной концепции являются:

1) Хранение и масштабируемость;

2) Резервное копирование и аварийное воcстановление;

3) Мобильность;

4) Эффективность затрат;

5) Удобство и постоянная доступность.

Как и у любой другой технологии, у Cloud Computing есть свои недостатки, которые затрагивают такие функции, как:

1) Контроль и надёжность;

2) Безопасность и конфиденциальность;

3) Непредвиденные затраты;

4) Трудности, связанные с логированием сервисов.

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

2.2 Микросервисная архитектура

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

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

Рис.2. Представление микросервисной архитектуры.



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

На представленной ниже схеме наглядно изображены две упомянутые выше архитектуры:

Рис. 3. Сравнение монолитной и микросервисной архитектур.

Сложность в использовании монолитной архитектуры привела к использованию микросервисной (компонентной) архитектуры.

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

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

· Удалённые вызовы процедур (remote procedure call) работают медленнее, чем вызовы, которые происходят в рамках процесса в монолитной архитектуре.

Удалённые вызовы процедур - технология, которая позволяет компьютерным программам вызывать различные процедуры или функции из другого адресного пространства (например, на удалённом ПК).

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

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

Эти недостатки необходимо учитывать при использовании данной архитектуры.

2.3 Централизованное логирование

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

Централизованное логирование включает в себя следующие основные компоненты:

· Локальный агент (в данном контексте под локальным агентом понимается такой процесс в сервисе, который будет из определённого места брать логи и отправлять их в центральное хранилище с определённой периодичностью);

· Сборщик логов (этот компонента, которая принимает от всех агентов логи, сортирует их, и отправляет на дальнейшую обработку, при необходимости).

И дополнительные:

· Анализатор логов (программа, которая будет заниматься обработкой логов, предоставлять возможность поиска по логам);

· Визуализатор (компонента, которая будет представлять пользователю (разработчику) графическое изображение, после анализа логов).

2.4 Представление централизованного логирования

Рис. 1. Модель представления централизованного логирования.

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

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

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

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



3. Требования к технологиям для построения централизованного логирования

Существует ряд требований, предъявляемых к технологиям, которые будут задействованы при реализации централизованного логирования, а именно:

Требования относительно агрегации логов с сервисов (сборщик логов):

1) гибкость технологии;

2) простота в использовании;

3) с открытым исходным кодом;

4) наличие агентов (отправителей логов);

5) возможность добавления собственных/существующих плагинов;

6) унифицирование полученных данных;

7) масштабируемость.

Требования относительно анализа логов и поиска информации по ним (анализатор логов):

1) скорость поиска по большим объёмам информации;

2) асинхронная работа;

3) высокая надёжность и доступность;

4) масштабируемость;

5) с открытым исходным кодом.

Требования относительно отображения статистики и иной информации после анализа полученной информации (логов) (визуализатор):

1) лёгкость в конфигурации;

2) гибкий интерфейс;

3) возможность добавления собственных/существующих плагинов;

4) лёгкая интеграция с другими компонентами сервиса.



4. Изучение логирования в системе

В бизнес приложении основной библиотекой логирования является Log4j, а также используется его надстройка - это slf4j. Некоторые компоненты используют такую библиотеку, как commons-logging.

Log4j API является полезной, эффективной и простой в использовании утилитой, которая служит для упрощения процесса логирования. Log4j обеспечивает надежный, полностью настраиваемый, легко расширяемой и легко реализуемый фреймворк для логирования Java-приложений. Работа данной библиотеки включает три концепции: logger, appender and layout.

Logger используется для регистрации сообщений для конкретной системы или компонента приложения.

Logger'ам могут быть назначены различные уровни приоритетов:

· All (Все уровни, включая пользовательские уровни);

· DEBUG (Обозначает детализированные информационные события, которые наиболее полезны для отладки приложения);

· ERROR (Обозначает ошибки, которые позволяют приложению продолжать работать);

· FATAL (Обозначает очень серьезные ошибки, которые предположительно приведут приложение к некорректной работе);

· INFO (Обозначает информационные сообщения);

· OFF (предназначен, чтобы отключить ведение журнала);

· TRACE (Обозначает более детализированные информационные сообщения, чем DEBUG);

· WARN (Обозначает потенциально опасные ситуации).

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

slf4j ( Simple Logging Facade for Java) - представляет из себя библиотеку для логирования, которая ставит перед собой задачу предоставить максимально простой и в то же время мощный «фасад» для библиотек логирования.



5. Исследование интеграции централизованного логирования

5.1 Исследование технологий

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

Выбор сборщика логов.

Для агрегирования логов в центральное или внешнее хранилище необходимо использовать инструмент - сборщик логов. Наиболее распространёнными инструментами являются Fluentd и Logstash.

Logstash является «сборщиком данных» с возможностью их обработки в режиме реального времени. Logstash может динамически объединить данные из разнородных источников и нормализовать их в зависимости от выбранного заранее критерия.

Преимущества Logstash:

1. Централизация обработки данных.

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

2. Нормализация выбранных данных.

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

3. Расширение до кастомного формата логов.

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

4. Добавление плагинов для кастомного потока данных.

Logstash предоставляет API для быстрой разработки плагинов со стороны пользователей.

5. Имеет открытый исходный код.

Следующий инструмент «сбора данных» - это Fluentd.

Преимущества Fluentd:

1) Унифицированный уровень протоколирования (Unified Logging Layer).

Унифицированное логирование позволяет более эффективно использовать данные и перебирать их быстрее на программном обеспечении.

Fluentd в основном использует структуру данных JSON: это позволяет ему объединять все аспекты обработки данных журнала: сбор, фильтрацию, буферизацию и вывод журналов по нескольким источникам. Обработка полученных данных намного проще с JSON, так как он является достаточно структурированным, сохраняя при этом гибкость.

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

2) Быстро развёртывается на оборудовании, имеет большое количество плагинов, а также есть возможность для разработчиков писать собственные плагины.

3) Надёжность и масштабируемость

a) Горизонтальная масштабируемость

Unified Logging Layer должен обеспечить простой механизм для добавления новых входов / выходов данных без огромного влияния на его работу.

b) Повторное выполнение передачи данных

Unified Logging Layer должен предвидеть сбои сети, что не должно привести к потере данных.

4) Минимальность затрат при расширении системы в целом

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

Требования	Fluentd	Logstash
Гибкость технологии	+	+
Простота в использовании	+	-
С открытым исходным кодом	+	+
Наличие агентов (отправителей логов)	+	+
Возможность добавления собственных/существующих плагинов	+	+
Унифицирование полученных данных	+	+
Масштабируемость	+	-

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

Выбор анализатора логов

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

Преимущества Elasticsearch:

1) Данные в реальном времени.

2) Massively Distributed

Elasticsearch позволяет масштабировать по горизонтали по мере роста.

3) Высокая надёжность и доступность данных

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

Выбор визуализатора.

При выборе визуализатора можно было использовать решение, написанное внутри компании, с визуалицией графиков через highchart (отдельная библиотека для создания различных графиков, диаграмм, с использованием языка JavaScript), но это накладывала время не её разработку. Но решили использовать готовые продукты, которые используются в современной индустрия, поэтому решили взять kibana.

Kibana служит для отображения каких-либо метрик, графиков, статистики данных, хранящихся на сервере.

Он обладает следующим функционалом:

1) Простая интеграция с Elasticsearch.

Благодаря разработке архитектуры для работы с Elasticsearch, Kibana даёт представление любому виду данных (структурированных, неструктурированных индексируемых в Elasticsearch).

2) Гибкий интерфейс

Быстрое создание, сохранение и использование визуализированных данных.

3) Простая настройка



6. Создание инструмента для конфигурирования логирования

Цель создания данного инструмента была упрощение создания конфигурации настроек журналирования в системе.

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

6.1 Локальное конфигурирование

Для того, чтобы конфигурация журналирования работала на сервере, необходимо иметь специальный файл. Это может быть, как log4j.xml, так и log4j.properties. На данной платформе применялся файл log4j.properties.

Данный инструмент работал следующим образом.

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

Для того чтобы инструмент функционировал на сервере, необходимо предварительно установить его.



6.2 Удалённое конфигурирование

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

Конфигурирование настроек логирования по сети выглядело следующим образом:

1) На своём сервере я загружал конфигурацию логирования с другого сервера.

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

3) Отправлял новую конфигурацию POST-запросом на удалённый сервер. Конфигурация сразу применялась.

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

Так как данные с другого сервера приходилось получать непосредственно с web-страницы, необходимо было парсить (термин означает автоматическую обработку, связанную с получением данных, которые необходимы, для этого используется специальная программа) эти данные, для получения только нужной информации, а именно, самой конфигурации. Для этого я использовал один из разновидностей DOM-парсера (такой парсер, который получает всю страницу и записывает её в коллекцию, которая хранится как «дерево», разбитая по заголовкам, которые есть на HTML странице) - Jsoup-парсер

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



7. Установка и конфигурирование централизованного логирования

7.1 Установка Fluentd

Рассмотрим последовательность действий установки Fluentd:

1) Установка агрегатора логов выполняется следующей командой:

curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh

2) Проверка работы. Для этого необходимо выполнить запуск и посмотреть его статус:

/etc/init.d/td-agent start

После выполнения команды должно появится следующее сообщение, показывающее успешный запуск td-agent'а:

Starting td-agent: [OK]

Следующей командой проверяем статус работы:

/etc/init.d/td-agent status

Исходя из сообщения ниже видно, что Fluentd запущен и работает:

td-agent (pid 21678) is running...

3) Устанавливаем Elasticsearch плагин, чтобы связать Fluentd и Elasticsearch.

$ sudo /usr/sbin/td-agent-gem install fluent-plugin-secure-forward

$ sudo /usr/sbin/td-agent-gem install fluent-plugin-elasticsearch

Настраиваем конфигурационный файл:

/etc/td-agent/td-agent.conf

4) Перезагружаем td-agent для применения конфигурации:

$ sudo service td-agent restart

На компоненту необходимо установить форвадер (агент, который будет отправлять логи):

1) Устанавливаем агента:

$ sudo curl -L http://toolbelt.treasuredata.com/sh/install-ubuntu-precise.sh | sh

2) Разрешаем Fluentd читать логи:

$ sudo chmod og+rx /var/log/httpd

$ sudo chmod og+r /var/log/messages /var/log/secure /var/log/httpd/*

3) Добавляем запись в файл /etc/rsyslogd.conf для того чтобы начать отправку системных логов, чтобы Fluentd мог слушать порт:

*.* @127.0.0.1:42185

4) Перезагружаем rsyslogd:

sudo service rsyslog restart

5) Изменяем конфигурационный файл /etc/td-agent/td-agent.conf.

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

Можно использовать несколько вариантов установки агентов:

· Автоматическая установка через менеджер конфигураций. Здесь могут использоваться различные инструменты, такие как: Salt, Puppet.

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

· Установка внутри контейнера. Здесь применяются такие технологии, как docker-контейнер или CoreOs-контейнер.

· Установка агента непосредственно из кода компоненты. Минусом данного подхода является зависимость на выбранную библиотеку и на её конкретную версию.

7.2 Установка Elasticsearch

1) Скачиваем заархивированный файл

curl -L -O https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/tar/elasticsearch/2.3.3/elasticsearch-2.3.3.tar.gz

2) Следующим шагом мы распаковываем скаченный файл:

tar -xvf elasticsearch-2.3.3.tar.gz

3) Третьим шагом вы переходим в репозиторий Elasticsearch и запускаем его:

cd elasticsearch-2.3.3/bin

./elasticsearch

После этого будет видно, что Elasticsearch запустился и будет работать в фоновом режиме.

7.3 Установка Kibana

1) Загружаем и устанавливаем специальный ключ

rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

2) Создаём файл с именем kibana.repo в каталоге /etc/yum.repos.d/, после этого добавляем в файл строки:

[kibana-4.5]

name=Kibana repository for 4.5.x packages

baseurl=http://packages.elastic.co/kibana/4.5/centos

gpgcheck=1

gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch

enabled=1

3) Следующим шагом мы устанавливаем kibana:

yum install kibana

4) И запускаем kibana командой:

sudo service kibana start

5) Заходим на http://localhot:5601/ и увидим следующий результат:



Заключение

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

Рост популяризации данных инструментов обусловлен постоянным развитием технологий. Также растёт и сложность данных технологий.

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

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

Большую роль при выборе технологий определило преимущественное использование технологий в современной индустрии.



Список литературы

1. Namiot D. On Micro-services Architecture / Namiot D., Sneps-Sneppe M. // International Journal of Open Information Technologies. - 2014. - № 9. - P. 24-27.

2. Namiot D. On IoT programming / Namiot D., Sneps-Sneppe M. // International Journal of Open Information Technologies. - 2014. - № 10. - P. 25-28.

3. Namiot D. Micro-service Architecture for emerging telecom applications / Namiot D., Sneps-Sneppe M. // International Journal of Open Information Technologies. - 2014. - № 11. - P. 34-38.

4. Kirkegaard C., Moller A. Static Analysis for Java Servlets and JSP. In Yi K. (ed.) SAS 2006. LNCS vol. 4134, pp336-352. Springer, Heidelberg (2006).

5. Kwangkeun Yi. (2006). «Static Analysis».

Размещено на Allbest.ru

...