Не секрет, что микросервисы мало запустить. За их работой нужно следить, чтобы не было сбоев, а следовательно и недовольных пользователей. Для этого, нужны системы мониторинга и логирования. Системы собирают различные метрики (начиная от температуры, напряжения, скорости вращения вентиляторов, информации с датчиков серверного и сетевого оборудования и заканчивая бизнес‑метриками самого приложения) и выводят их на дашборды, а также фиксируют логи контейнеров, журналов и системной информации, обрабатывают данные и помогают в анализе инцидентов. Команда платформы dBrain.cloud собрала свой универсальный стек системы мониторинга. Сегодня расскажем, какие проблемы возникают с мониторингом и как их решить.
Все познается в сравнении
В платформе dBrain для мониторинга наша команда использует стек VictoriaMetrics. Но пришли мы к этому решению не сразу. Путь был извилист и лежал через InfluxDB, который съедал непомерно много ресурсов и имел далекую от совершенства архитектуру, и стек Prometheus, где не хватало встроенных средств репликации, шардирования данных на уровне сбора метрик, возникали проблемы с согласованностью данных после сбоев и разграничением прав доступа между пользователями разных тенантов.
До недавнего времени для мониторинга платформы dBrain и сбора различных метрик с компонентов мы использовали Prometheus с интеграциями экспортеров. Система собирает большое количество метрик, что позволяет глубоко погружаться в проблему при траблшутинге инцидентов. Мы использовали ванильный Prometheus. Для него специально разработали конфигурацию на динамических джобах, которые применяют автодискаверинг Kubernetes. Как это работало? Если на каких‑либо подах, нодах, сервисах значился заранее известный набор аннотаций, то эта цель отмечалась как необходимая для сбора под определенные джобы. Таким образом, Prometheus сам, без участия DevOps, собирал с них метрики. Такая настройка позволила исключить шаг с написанием тикета на хелпдеск о старте мониторинга конкретного приложения. Процесс стал автоматизированным: конечный пользователь «повесил» нужную аннотацию — получил свои метрики.
Кроме классических экспортеров, таких как Node exporter (для общего понимания того, что происходит с нодами), в платформе dBrain также используется ряд нетривиальных экспортеров — например, DCGM‑Exporter, который работает «под капотом» у NVIDIA Exporter. Помимо этого есть интеграции с различными протоколами — OpenTelemetry Metrics, Statsd, Prometheus Metrics, Influx line. Практически все ходовые интеграции мы предоставили конечному пользователю, поэтому dBrain сможет получать и отображать эти метрики.
Несомненным плюсом VictoriaMetrics стала возможность долговременного хранения метрик. У Prometheus тут проблемы, связанные с непомерным потреблением оперативной памяти и отсутствием встроенного механизма репликации. Оставляет желать лучшего и быстродействие системы. VictoriaMetrics же не только работает в отказоустойчивом режиме минимум в трех репликах, но и шардирует данные. За счет этого повышается отказоустойчивость и масштабируемость решения. VictoriaMetrics поддерживает multitenancy: пользователи dBrain изолированы друг от друга, видят метрики только своего проекта. Такой подход позволяет нам обеспечить на одном кластере с помощью одного стека мониторинг всех проектов пользователей и самого кластера. В dBrain для каждого клиента заведено отдельное пространство со своим паролем и подключением к VictoriaMetrics.
Также мы используем компонент vmauth кластерной версии VictoriaMetrics, который позволяет включить авторизацию на доступ. Для получения метрики каждый пользователь должен знать свой идентификатор, имя и пароль. В Grafana все автоматизировано: пользователь заходит в систему и сразу получает доступ к своим метрикам и дашбордам.
Кто лучше?
Задача наших разработчиков — обеспечить отказоустойчивость платформы dBrain. Prometheus решает это с помощью Thanos, дополнительных оберток или полного дублирования, но потребляет при этом огромное количество ресурсов. Компонент стека VictoriaMetrics vmagent заменяет функциональность Prometheus и обеспечивает отказоустойчивость платформы. vmagent запускается и работает в отказоустойчивом кластерном режиме: когда несколько реплик синхронизируются между собой, страхуют друг друга, собирают метрики.
vmagent разбивает общий пул задач на куски и делит их между репликами, чтобы обеспечить не только отказоустойчивость, но и распределение нагрузки. Различие в потреблении ресурсов Prometheus и vmagent значительно: там, где Prometheus в тестовой среде потреблял 12 Гб оперативной памяти, vmagent в три реплики — в четыре раза меньше.
Миграция на vmagent для нас прошла достаточно легко. Все благодаря полностью совместимой с Prometheus конфигурации. VictoriaMetrics изначально разрабатывалась на микросервисной архитектуре с учетом рекомендаций Twelve‑Factor App (подробнее можно почитать тут), поэтому в ней реализованы оптимальные архитектурные решения. При задержках и перерывах в работе системы происходит буферизация данных. Как только работа сетевых устройств нормализуется, данные восстанавливаются. Таким образом информация не теряется.
Prometheus не только «ест» много памяти, но и занимает много места на диске. VictoriaMetrics гораздо экономичнее. Допустим, метрики на месяц с достаточно большим количеством уникальных рядов могут занимать всего 10 Гб из целого кластера на 20–30 нод.
Ищем неполадки
Кроме системы мониторинга метрик, у нас внедрена система для трассировок — отображение и сбор трейсов. Пользователь может подключить систему трассировок на своем приложении. Она позволит определить на уровне взаимодействия микросервисов и даже отдельных кусков кода, как быстро они выполнялись и сколько времени занимали в общем контексте.
Все метрики и трассировки в dBrain отсылаются в Tempo — это компонент, выпущенный Grafana Labs. Разработчики Tempo делают тесную интеграцию с самой Grafana для интуитивно понятного отображения, чтобы использовать показатели для перформанс‑анализа. Ведь во многих случаях клиентское приложение выглядит как черный ящик: есть входные данные, какой‑то выходной результат, а что, как и почему происходило внутри для систем мониторинга обычно остается загадкой. Трассировка помогает увидеть изнутри, как приложение обработало конкретный запрос пользователя и сколько времени на это ушло на каждом из этапов. В момент сбоя все отображается на графиках, что позволяет быстро определить проблемную точку.
В обычном случае мониторинга видна общая задержка отдельных компонентов (микросервисов), а с помощью Grafana Tempo можно оценить временные интервалы выполнения, наличие ошибок в процессе и т. д.
Приведем простой пример, почему система трассировок необходима для качественного и всестороннего мониторинга. Думаем, с подобными ситуациями сталкивались многие разработчики: после обновления приложения какой‑то из его компонентов стал отрабатывать, к примеру, на 40 процентов медленнее. Без трассировки выявить отстающего невозможно, т.к. все сервисы завязаны друг на друга и ждут ответ от других компонентов. Особенно, если это не сервисы, а отдельные куски кода приложения. Если же грамотно распоряжаться трассировками, можно отслеживать критически важные участки кода, помечать их span и отправлять в Tempo, чтобы они отображались на графиках. С помощью трассировок время на поиск и устранение проблем в работе микросервисов сокращается в разы.
Где слабое звено?
Чтобы охватить все аспекты мониторинга работы микросервисов, используем несколько решений от Grafana. Одно из них — Grafana Phlare. Решение предоставляет по сути real time профилирование приложений. Grafana Phlare и Grafana Tempo позволяют вычислять отдельные процессы и потоки, которые замедляют работу приложения.
Как это реализовать? SDK внедряется со стороны клиента (у нас есть возможность подключения такого функционала). Если клиент решит его использовать, он сможет в режиме реального времени на графиках видеть профилирование своего приложения.
Например, у нас был случай, когда приложение Java почему‑то давало большую задержку. Около двух дней мы пытались разобраться, члены команды выдвигали много теорий, но однозначный ответ сразу найти не получилось. Пришлось останавливать контейнер, тюнить параметры, снимать дамп JVM, стаскивать его с кластера, вручную разбирать. С Grafana Tempo то же самое можно сделать онлайн, просто зайдя в систему.
Что с фронтендом?
Со стороны бэкенда мы мониторим сам Kubernetes, видим бэкенд клиентского приложения, которое отсылает метрики, а также трассировки. А что делать с фронтендом? Ведь конечное приложение — это не только бэкенд, развернутый в кластере. Когда выходят новые версии приложений, происходят сбои, что‑то не работает, пользователи жалуются, но описать проблему толком не могут. Как правило, все сводится к малоинформативному «у меня не работает». Нужен посредник, с этой ролью отлично справляется компонент Grafana Faro. Он также подключается с помощью SDK. Этот подход называется Real user monitoring, когда статистика по перфомансу приложения, логам, эксепшенам, ивентам, трассировкам собирается внутри клиентской части приложения.
Например, при сохранении приложение зависло, но изменения не сохранило, а ошибку не выдало. Как разбираться в проблеме? Без Grafana Faro нужно разворачивать локально клиентскую часть приложения и искать проблему. Если же SDK подключена, то придет отчет об эксепшене и действиях, которые ему предшествовали. По сути, это traceback и логи, но со стороны реальных пользователей. Такой подход позволяет в клиентской части собирать данные мониторинга и фиксить проблемы на лету. Для разработчиков это Святой Грааль. Без подобных программ решение проблем и устранение багов затягивается. Ведь у пользователей нет технического образования и опыта в тестировании для развернутого описания проблемы, чтобы разработчик моментально понял и мог ее пофиксить.
Все под надзором
«Не только состояние кластера и серверов нужно отслеживать, — скажете вы. — А как же доступность нод и метрик snmp»? Без этого никуда, согласны. В dBrain добавили специфичные интеграции — SNMP и gNMI, чтобы отслеживать метрики сетевого оборудования. Система мониторинга обеспечивает наблюдение за всеми аспектами кластера. Если проблема инфраструктурная, мы ее видим и понимаем, что, где и почему пошло не так. Если проблема сетевая или на стороне клиентского приложения — то же самое.
Метрики с сетевого оборудования, серверов и клиентского приложения дают полную картину происходящего для поддержки работоспособности и перформанса системы. Кроме того, это ценная информация для девелоперов, потому что они могут видеть, как их приложение ведет себя под разной нагрузкой, в различных ситуациях, сетапах. Это является отличным подспорьем для разработки.
Внимание! Тревога!
Чтобы дежурные инженеры устранили баг, отработала система по трекингу времени и SLA, о проблеме для начала нужно сообщить. Как это сделать? В dBrain мы используем полностью совместимую с VictoriaMetrics часть Prometheus стека — alertmanager, а из стека VictoriaMetrics — vmalert.
Принцип работы vmalert: сервис входит в базу, сравнивает данные, если условие удовлетворено, посылает сигнал тревоги на alertmanager. Свое состояние vmalert хранит внутри vmstorage, поэтому для обеспечения отказоустойчивости этого компонента достаточно просто поднять количество реплик. Это надежно, легко и эффективно, не требует дополнительных зависимостей — проверено на себе.
Alertmanager работает в отказоустойчивом режиме в кластере из минимум трех реплик, каждая из них общается между собой и отслеживает состояние друг друга. Alertmanager будет доблестно сражаться, чтобы отправить оповещение, даже если две из его трех нод выйдут из строя.
Куда же приходят сигналы? В Telegram, на почту и по вебхукам. Таков функционал dBrain для алертинга из коробки. Эти три кейса задаются несколькими строчками в конфиге. Но это не все. Предусмотрено расширение, отправляющее оповещения в отдельные чаты, а также в несколько дублирующих конечных точек. У нас есть похожая по функционалу система на Service Desk. Она предназначена для автоматизации процесса создания и назначения тикетов, а также тайм‑трекинга с SLA. Человеческий фактор здесь исключается: алерт отослан — автоматически создается тикет.
В dBrain есть также стандартные интеграции alertmanager и с другими мессенджерами. В списке интеграций порядка 30 самых распространенных в мире чатов, есть даже китайский WeChat. Кроме того, наши инженеры могут настроить интеграцию с практически любым корпоративным мессенджером, который использует компания заказчика.
Вот таким образом мы собираем продуктивный стек. Наша цель — сделать работу с платформой простой и удобной, чтобы в одном месте пользователь мог получить всю необходимую информацию о своем приложении. В следующем материале вы увидите, какие продукты мы подобрали в стек для сбора логов. А пока инженеры dBrain ждут ваши вопросы по теме мониторинга и логирования, а также предложения по новым темам.
