Распределенные системы. Паттерны проектирования - [19]
70 Часть I. Одноузловые паттерны проектирования
могут вести журналы в разных форматах, а контейнер-адаптер может преобразовывать эти данные в общее структурированное представление, которым сможет воспользоваться агрегатор жур-налов. Адаптер и в данном случае на основе неоднородной среды приложений создает однородную среду общих интерфейсов.
его контейнера с целью обеспечения унифицированного интерфейса — хорошая идея.
Однако во многих случаях приходится пользоваться кон-тейнером, созданным другим человеком. В таких случаях создание преобразованного образа, который придется поддерживать (выпускать собственные исправления, сле-
дить за исправлениями, выпускаемыми автором исходного образа), оказывается более затратным, чем разработка собственного адаптера, который работает параллельно «чужому» контейнеру. Кроме того, выделение адаптера в отдельный контейнер позволяет использовать его по-вторно в других приложениях, что невозможно, если мо-дифицировать непосредственно контейнер приложения.
Практикум. Нормализация форматов журналов с помощью fluentd
Одна из задач адаптера — привести показатели журнала к стан-дартному набору событий. Разные приложения имеют разные форматы выходных данных, но, чтобы привести их к однород-ному формату, можно задействовать стандартный инструмент журналирования, развернутый в виде адаптера. В данном при-мере мы будем использовать агент мониторинга fluentd, а также некоторые поддерживаемые сообществом надстройки для полу-чения записей журналов из различных источников. Глава 4. Адаптеры 71
Fluentd ( https://fluentd.org/ ) — один из наиболее популярных аген-тов журналирования с открытым исходным кодом. Одно из его основных преимуществ — богатый набор поддерживаемых сообществом надстроек, которые обеспечивают гибкий монито-
ринг разнообразных приложений.
Для начала понаблюдаем за сервисом Redis. Redis — популярное хранилище типа «ключ — значение». В числе прочих он предо-ставляет команду SLOWLOG , которая перечисляет последние за-просы, превысившие определенный порог времени исполнения.
Такая информация чрезвычайно полезна при отладке проблем с производительностью вашего приложения. К сожалению, ин-струмент SLOWLOG доступен только в виде команды сервера Redis, а это означает, что такие проблемы сложно отлаживать ретро-спективно в том случае, когда нет возможности сделать это сразу. Чтобы преодолеть это ограничение, можно воспользоваться сер-висом fluentd и паттерном Adapter, добавляя тем самым в Redis возможность журналирования медленных запросов. Для этого воспользуемся паттерном Adapter, в рамках которого назначим контейнер сервиса Redis основным контейнером при-ложения, а контейнер сервиса fluentd — контейнером-адаптером. Чтобы следить за медленными запросами, мы также воспользу-емся надстройкой fluent-plugin-redis-slowlog ( https://github.com/ mominosin/fluent-plugin-redis-slowlog ). Сконфигурировать ее можно, как показано в следующем фрагменте:
type redis_slowlog
host localhost
port 6379
tag redis.slowlog
Мы используем адаптер, а контейнеры находятся в общем сетевом пространстве, — конфигурация журналирования ограничивается настройкой на сервер localhost и порт Redis по умолчанию (6379). 72 Часть I. Одноузловые паттерны проектирования
Благодаря такому приложению паттерна Adapter журнал ме-дленно выполняющихся запросов будет доступен в любой удоб-ный для их отладки момент.
В качестве похожего упражнения можно настроить наблюде-ние за записями журнала системы Apache Storm ( https://storm. apa che.org/ ). Storm предоставляет данные посредством RESTful API, что само по себе удобно, но имеет ограничения в том слу-чае, когда мы не наблюдаем за системой в момент возникнове-ния проблемы. Как и в случае с Redis, можно воспользоваться fluentd-адаптером, чтобы преобразовать данные Storm в упо-рядоченный по времени журнал, к которому можно осущест-влять запросы. Чтобы добиться этого, можно развернуть fluentd-адаптер c развернутой в нем надстройкой fluent-plugin-storm. Надстройку стоит сконфигурировать таким образом, чтобы она указывала на сервер localhost, поскольку опять-таки мы рабо-таем с группой контейнеров с общим сетевым пространством. Конфигурационный файл надстройки будет выглядеть так:
type storm
tag storm
url http://localhost:8080
window 600
sys 0
Мониторинг работоспособности сервисов
В качестве последнего примера рассмотрим применение паттерна Adapter для мониторинга работоспособности контейнера приложе-ния. Разберем задачу мониторинга работоспособности контейнера типовой СУБД. В данном случае контейнер СУБД предоставляет-ся ее разработчиками, и мне не хотелось бы модифицировать его Глава 4. Адаптеры 73
только для того, чтобы добавить в него проверку работоспособ-ности. Оркестратор контейнеров, конечно, может взять на себя несложную проверку работоспособности, чтобы убедиться, что процесс запущен и принимает подключения по определенному порту. А что, если мы хотим выполнять сложную проверку рабо-