Б Бёрнс - Распределенные системы. Паттерны проектирования

Одна из задач адаптера — привести показатели журнала к стан-дартному набору событий. Разные приложения имеют разные форматы выходных данных, но, чтобы привести их к однород-ному формату, можно задействовать стандартный инструмент журналирования, развернутый в виде адаптера. В данном при-мере мы будем использовать агент мониторинга 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

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

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

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