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

apiVersion: v1

kind: Pod

metadata:

name: adapter-example

namespace: default

spec:

containers:

- image: redis

name: redis

# Предоставляем адаптер, реализующий интерфейс Prometheus - image: oliver006/redis_exporter

name: adapter

Этот пример иллюстрирует не только ценность паттерна Adapter в плане обеспечения унифицированного интерфейса, но и полез-ность контейнерных паттернов в целом как средства обеспечения модульности и повторного использования контейнеров. При-мер демонстрирует, как совместить существующий контейнер с Redis и адаптер в формат Prometheus. Совокупным эффектом Глава 4. Адаптеры 69

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

Как и в случае с мониторингом, системы очень неоднородно журналируют данные. Системы могут разделять журналы на различные уровни, например debug, info, warning и error, каж-дый из которых записывается в отдельный файл. Некоторые просто выводят информацию в потоки stdout или stderr . Это особенно критично в случае контейнеризованных приложений, когда обычно ожидается, что контейнеры выводят информацию в поток stdout , так как именно его содержимое доступно при выполнении команд docker logs или kubectl logs . Усложняет ситуацию и то, что журналируемая информация в об-щем случае имеет структурированные элементы, например дату и время записи, но эти сведения сильно различаются для разных реализаций библиотек журналирования (например, для встроен-ного в Java средства журналирования и пакета glog в Go). Записывая и читая журналы своей распределенной системы, вы, конечно же, не особо заботитесь о различиях между форматами. Вы хотите убедиться, что, несмотря на различную структуру данных, каждая запись имеет соответствующую метку времени. К счастью, как и в случае мониторинга, паттерн Adapter помогает предоставить модульную, повторно используемую архитекту-ру для ведения журналов. Контейнер приложения может вести журнал в файле, а контейнер-адаптер будет перенаправлять его содержимое в поток stdout . Разные контейнеры приложения

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