Трейсинг информационных потоков распределённого приложения и другие подходы к мониторингу
Специально для телеграм-канала Мониторим ИТ.
Дикий какой-то заголовочек получился. Нет, вы можете спросить не мог ли я придумать чего попроще. Не мог, потому что по-английски это звучит как Application Performance Tracing. Поди тут переведи. Переход на микросервисную (читай распределённую) архитектуру начинает требовать учитывать производительность сетевого взаимодействия внутри приложения. Отсюда и рост количества систем мониторинга с визуализацией информационных потоков.
Статья родилась просто потому что я наткнулся на вендора, о котором раньше не слышал — Netsil. Случайно обнаружил блог и посмотрел на сайте их интересное решение.
Немного о Netsil
Поставляют решение Application Operations Center (AOC) для мониторинга распределённых приложений, которое классифицируют как Application Performance Tracing. Компания перестала быть независимой в марте этого года, её приобрёл широко известный в узких кругах Nutanix.
Принцип работы прост: на серверы устанавливается агент, который производит глубокий анализ трафика между частями приложения. Автоматически распознаётся сетевой трафик между Kubernetes, Docker, RabbitMQ, Apache и многими другими. Контролируется, конечно, не только трафик, но и внутреннее состояние компонентов приложения. Это было небольшое предисловие.
Немного об анатомии приложения
В своём блоге Netsil опубликовал интересный пост о подходах к мониторингу приложений. Для начала рассмотрим обычное такое приложение.
На верхнем уровне пользователь взаимодействует с фронтэндом через браузер, мобильное приложение на своём гаджете или какой-то другой интерфейс. Пользовательские запросы передаются на бэкэнд через API (обычно REST). Сервисы тут выступают как объединение инстансов в логический пучок. Например, несколько инстансов могут предоставлять сервисы Shopping cart, Checkout (если мы говорим о e-commerce) или какие-то ещё. Инстансы, объединённые в сервисы выполняются внутри элементов инфраструктуры: виртуальных машин, контейнеров или физических серверов. Инфраструктура, соответственно, самый нижний уровень абстракции.
Немного о подходах к мониторингу
На схеме показаны 4 подхода к мониторингу:
- Black-box — подход, при котором мониторинг осуществляется из внешнего периметра приложения, т.е. метрики собираются извне;
- White-box — встраивание модуля мониторинга в код приложения, например, установка агента для инструментации Java-кода;
- Instance-level — мониторинг с точки зрения доступности конкретного запущенного экземпляра сервиса. Экземпляров может быть несколько;
- Service-level — мониторинг с точки зрения доступности сервиса, при этом даже если какой-то экземпляр сервиса не работает, сервис всё равно считается доступным.
Только не нужно понимать эту схему буквально. Очевидно, что вендоры находятся в постоянном развитии и некоторые из них залезают на соседние поляны. Например, Riverbed (которого тут почему-то нет), умеет инструментировать код и прослушивать трафик.
Схема выше нужна для плавного перехода к следующей схеме — схеме с пользователями систем мониторинга.
Мы знаем, что есть группы Dev и Ops, каждая из которых понятно чем занимается. Считается, что подход Black-box больше подходит команде Ops, которой нужно следить за приложением с точки зрения доступности сервисов и код их не сильно интересует. Команде Dev важнее следить за кодом и для них более эффективен подход White-box с глубокой трассировкой вызовов внутри приложения и наблюдение с точки зрения доступности инстансов.
Запомнить
Если вы находитесь в процессе выбора системы мониторинга — определитесь кто будет её ключевым пользователем: разработчики или эксплуатация.
Методика Black-box не требует модификации кода. Иногда это критически важно, когда вам нужен близкий к нулевому оверхед.
Все подходы могут существовать совместно в одной системе мониторинга. Вполне вероятен переход (drill-down) внутри этой системы от сервисов к инстансам и смешанный мониторинг: как снаружи так и внутри приложения. Это вообще идеальный вариант.