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

Пензенский государственный технологический университет

Отслеживание статуса сервисов инфраструктуры веб-приложения

Чинков М.Ю.,

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

Ключевые слова: веб-приложение, отслеживание сервисов, Consul, проверки состояния.

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

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

Решением проблемы отслеживания статуса сервисов веб-приложения является реализация дополнительного вида мониторинга в виде методологии исследования сервиса (service discovery). "Service discovery" позволяет построить на своей базе полноценную систему отслеживания сервисов, которая позволит не только обнаружить, какой именно сервис вышел из строя, но и автоматически исправить ошибки и перезапустить сервис.

Самым популярным решением в реализации практик "service discovery" является применение программного инструмента Consul. Consul является клиент-серверной системой, нацеленной на решение нескольких задач:

1) "Service discovery”. Consul обнаруживает наличие тех или иных сервисов веб-приложения, отслеживая поведение агентов по протоколам DNS и HTTP.

статус сервис приложение мониторинг

2) Проверка состояния сервисов (health check). Консул позволяет настроить в рамках кластера неограниченное число проверок сервиса любыми методами. Например, проверкой состояния сервиса база данных является попытка подключения к TCP-порту, который должна прослушивать СУБД, командой netcat.

"Health check" обычно имеет 2 состояние - проходящий (passing), в котором описывается рабочее состояние сервиса и критический (critical), которое говорит о том, что сервис в данный момент времени не работает.

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

В рамках данного исследования был спроектирован полноценный кластер Consul из нескольких нод с конечной визуализацией состояния сервисов в виде статусной страницы (status page). Реализация кластера состояла из следующих базовых шагов:

1) Скачивание и установка Consul на нодах кластера. Процесс установки Consul-агента на одной ноде достаточно прост. Необходимо лишь скачать zip-архив и распаковать бинарный файл в директорию, из которой запускаются системные команды.

2) Скачивание пакета веб-интерфейса Consul. Отдельно на Consul-сервер скачивается пакет веб-интерфейса. Интерфейс разворачивается самостоятельно при запуске Consul, не требуя дополнительной конфигурации.

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

4) Настройка системных демонов consul-agent и consul-server. По умолчанию consul запускается из командной строки как foreground-процесс. Для полноценной работы кластера необходимо запускать агенты в виде фоновых процессов. Данная задача была реализована в виде работающих системных демонов на ОС Ubuntu 16.04.

5) Конфигурация прокси-сервера. Дополнительно на сервере Consul, где планировалось развернуть веб-интерфейс, был установлен и сконфигурирован прокси-сервер Nginx, который перенаправляет все соединения со стандартного 80 порта HTTP на 8500, который прослушивает Consul. Дополнительно настроена аутентификация для предотвращения входа в систему посторонних лиц.

6) Тестовый запуск кластера. На каждой ноде был запущен агент Consul. Таким образом, мы проверили, что работает базовый функционал кластера.

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

8) Добавление триггеров состояния сервисов. На каждый сервис был прикреплен собственный триггер - "watch" - который запускает обработчик событий сразу после того, как "health check" сервиса приобрел критическое состояние.

9) Добавление обработчиков событий. В рамках исследования для каждой ноды был создан отдельный обработчик - "handler" - который проверяет доступность внутренних сервисов и пытается перезапустить тот сервиса, который был помечен, как недоступный.

10) Перезагрузка конфигурации кластера. Для вступления изменений конфигурации в силу на каждой ноде кластера была проведена перезагрузка кластера запуском команды "consul reload”.

11) Проверка работы кластера. Проверка работы кластера была проведена в два шага: запуск команды "consul members" в консоли сервиса и проверка веб-интерфейса из локального браузера.

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

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

Рисунок 1 - веб-интерфейс системы отслеживания сервисов веб-приложения

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

Хотелось добавить, что в рамках данного исследования была реализована лишь самая примитивная возможность Consul как инструмента для "service discovery”. Работая с полноценной микросервисной архитектурой, где сервисы, упакованные в контейнеры, не имеют постоянного места эксплуатации, необходима полноценная оркестрация инфраструктурой, динамически конфигурируя окружение путем изменений настроек подключения к DNS и системам мониторинга. Consul позволяет это делать автоматически и на лету. Также в Consul можно хранить данные в формате "ключ-значение”, записывая состояние о нодах кластера.

Таким образом, была рассмотрена проблема отслеживания состояния множества слабо связанных сервисов веб-приложения с описанием одного из путей решения проблемы посредством внедрения в инфраструктуру приложения практики "service discovery" в виде исследования работы такого инструмента, как Consul.

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

1. Немет Э., Снайдер Г., Хейн Т.Р., Уэйли Б. Unix и Linux. Руководство системного администратора [Текст] // Вильямс. - 2012. - С.1157-1180.

2. Limoncelli T. The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, Volume 2 [Текст] // - 2015. - С.243-275.

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