Нашла и перевела: Ксения Мосеенкова
Представляем вам Asserts — платформу для анализа и отслеживания метрик. Сканируя метрики вашего приложения в любой совместимой с Prometheus базе данных временных рядов (time-series database, TSDB), Asserts в реальном времени:
создаёт карту архитектуры приложения и инфраструктуры,
строит дашборды,
отслеживает цели уровня обслуживания (service level objectives, SLOs)
и запускает автоматические проверки (Assertions) для выявления изменений и потенциальных проблем.
Наша задача — снизить усталость от предупреждений и сократить время поиска первопричины.
Что такое Asserts?
Asserts помогает просто и быстро разобраться в проблемах приложений и инфраструктуры — даже в высокомасштабируемых и сложных архитектурах. Вы будете получать оповещения о ключевых показателях, которые больше всего волнуют ваших пользователей. Вы сразу узнаете, когда произойдёт что-то важное, и не будете тратить время на сортировку менее значимых или ложных предупреждений.
В дополнение к наиболее значимым оповещениям Asserts покажет всё, что нужно для решения проблемы: сбои, которые могут быть причиной проблемы, связанные изменения и аномалии — всё в одном месте. Основанный на Prometheus, Asserts работает с любыми приложениями и любой архитектурой. Для начала работы потребуются только ключевые метрики.
Почему мониторинг — это сложно?
Наша команда в Asserts прожила жизнь мониторинга в AppDynamics. Клиенты AppDynamics полагались на нашу SaaS-платформу в рамках задачи мониторинга собственных приложений, поэтому первостепенной задачей было быстрое устранение сбоев в работе. Нам нужно было как можно быстрее обнаружить суть проблем.
Когда мы создали в AppDynamics облачные нативные приложения, мы поняли, насколько сложно эффективно контролировать приложения, даже имея в своем распоряжении самые современные инструменты APM с журналами, метриками, трассировками, панелями мониторинга и оповещениями. Мы столкнулись с необходимостью принять трудное решение — настройка высокоуровневых оповещений против тонких оповещений.
Когда мы настраивали оповещения на несколько высокоуровневых показателей бизнеса или пользовательского опыта (например, Records Processed, PageRenderTime, APIAvailability) мы получали более надёжные оповещения, но тогда устранение неполадок становилось длительным и могло приводить к появлению ошибок.
Когда же мы настраивали более тонкие оповещения, (например, CPU Load, JVM GC, Request Timeouts) оповещения часто срабатывали в тривиальных случаях, которые не были видимой проблемой для пользователя. Просыпаться в три часа ночи из-за оповещения — не самое приятное занятие, особенно в случае ложного срабатывания.
Поиск иголки в стоге сена
Наши сессии по устранению неполадок состоят из просмотра многочисленных дашбордов и метрик и поиска конкретной первопричины проблемы — классическая иголка в стоге сена. Мы задались вопросом: как можно автоматизировать этот процесс?
Чтобы избежать усталости от оповещений, нам нужно настроить оповещения на высоком уровне для приложений или бизнес-показателей, чтобы оповещения были направлены на потенциальные симптомы проблем. Кроме того, нам нужен способ автоматического определения первопричины проблем, чтобы ускорить их устранение. Хотя эти автоматические проверки в какой-то степени похожи на оповещения, они отличаются от них, поскольку не разбудят вас, когда сработают. Эти проверки являются вспомогательными средствами для устранения неполадок, а не первой линией защиты от сбоев. Мы называем их утверждениями (Assertions).
Избавление от рутины
Все приложения разные. Asserts позволяет легко настроить свои собственные утверждения и цели уровня обслуживания (SLO). В ходе нашего глубокого отраслевого опыта мы заметили, что приложения имеют большое количество общих проблем. Например:
перенасыщение ресурсами, будь то заполнение диска или превышение облачным сервисом установленной мощности;
выход новой версии или обновление конфигурации, приводящее к увеличению задержек;
постепенное накопление ошибок, приводящее к нарушению SLO.
Мы создали целую библиотеку утверждений, которые можно использовать для поиска проблем в приложениях. Наша библиотека утверждений построена на таксономии под названием SAAFE, которая поможет сориентироваться в проблемах, с которыми сталкивается ваше приложение.
Когда Assertions выявляют первопричину проблем, вам не нужно быть экспертом в каждой части архитектуры приложения. Коллективные знания теперь доступны каждому члену команды — например, что изменилось; на какие метрики следует обратить внимание; что нормально, а что нет.
Чтобы понять взаимосвязь между симптомами и причинами, также необходимо понимать архитектуру приложения: сбой в одном компоненте часто вызывает проблемы в другом. При устранении неполадок с помощью одних только метрик и дашбордов необходимо строить модель этих взаимосвязей на лету. Asserts автоматически изучают архитектуру приложения на основе ваших метрик и создаёт визуализацию, что позволяет быстрее сосредоточиться на устранении проблем.
Решение проблемы
Давайте проиллюстрируем это на примере, в котором мы пьём свой собственный Kool-Aid и используем Asserts для решения проблем в нашем собственном приложении. Кратко об архитектуре приложения: мы используем базу данных временных рядов, состоящую из нескольких сервисов. vmselect отвечает за выполнение запросов, vmalert оценивает правила (запросы). grafana и другие сервисы Asserts также направляют свои запросы в vmselect.
Архитектуру vmselect и связанных с ним сервисов можно посмотреть в графе сущностей Asserts.
Чтобы контролировать работу приложения, мы установили цели уровня обслуживания для отслеживания его производительности. Мы поняли, что что-то не так, когда Asserts прислал нам предупреждение, указывающее на медленную задержку API-сервера и ухудшение способности оценивать правила записи для наших клиентов.
В оповещение встроены удобные ссылки View Impact и Start Troubleshooting, которые помогают в процессе устранения неполадок. Ссылка View Impact показывает интересующие инциденты, произошедшие в момент оповещения.
Ниже показано, что примерно в то же время, когда api-server испытывал проблемы с задержкой, в vmservice (от которого зависит выполнение временных запросов API-сервером) произошёл сбой:
Ссылка Start Troubleshooting запускает экран Top Insights. Здесь мы ранжируем службы, чтобы выявить «горячие точки» в системе, и чтобы пользователь мог сразу же приступить к работе. Утверждения обозначаются синим (изменения/поправки), желтым (предупреждение) и красным (критический) цветом.
Завершившиеся неудачей утверждения показали, что в службе vmselect произошёл сбой и она стала недоступной из-за перенасыщения памяти.
Обратите внимание, что перед началом инцидента не было синих линий (Amends) — это способ Asserts сказать, что не было обновлений правил (запросов) или сборок для любой из служб.
Логи из View Logs показывают ошибку: vmselect исчерпал память при выполнении запроса.
Мы хотели узнать:
Откуда взялись плохие запросы.
Как пострадали наши клиенты.
Как мы можем предотвратить повторение этой проблемы.
Чтобы ответить на эти вопросы, мы начали копаться в утверждениях, возникающих в других службах.
Посмотрите видео о том, как Asserts регистрирует утверждения и представляет агрегированное представление утверждений с возможностью фильтрации и детализации, чтобы сузить круг проблемных сущностей и метрик.
Когда утверждения срабатывают, они обозначаются желтой и красной линиями на этой временной шкале. У vmselect больше всего проблем, поэтому он на самой вершине.
Утверждения выявили аномальное использование сети в это время: было обнаружено необычное количество трафика между Grafana и контроллером вхоящего трафика, который направляет трафик от фронтенда браузера к бэкенд-сервисам. Это свидетельствовало о том, что кто-то должен был оценивать особенно тяжёлые запросы через интерфейс запросов Grafana.
Изучая утверждения других сервисов, мы также заметили, что во время сбоя несколько наших экземпляров vmalert выдавали ошибки. Это означает, что оценка правил завершилась неудачно, пока слой запросов базы данных временных рядов, vmselect, не работал. Поскольку мы запускаем отдельные экземпляры vmalert для каждого клиента, мы знали, какие клиенты и группы правил были затронуты, а какие — нет. (Обратите внимание, что имена клиентов на этих скриншотах скрыты).
Корень проблемы стал ясен. Пользователь создал серию запросов и выполнил их через grafana, что потребовало слишком много памяти для оценки и привело к сбою службы запросов vmselect. Это заблокировало оценку правил для некоторых клиентов. Чтобы решить непосредственную проблему, мы запустили больше модулей vmselect, чтобы повысить отказоустойчивость системы.
Смотрите видео о том, как мы определяли сбоившие модули и их использование памяти непосредственно перед сбоем.
Перед самым сбоем модули достигли предела памяти, что привело к снижению доступности сервиса vmselect до тех пор, пока не были добавлены новые модули.
Устранение неполадок без Asserts
Прежде чем решить проблему, давайте подумаем, как бы изменилась ситуация без ассертов. Стандартными инструментами для устранения неполадок с помощью метрик являются дашборды и специальное исследование с помощью PromQL. Когда мы впервые получили оповещение в начале инцидента, мы бы обратились к заранее созданному дашборду, с помощью которого быстро нашли бы проблему. Чтобы дашборд помог нам найти первопричину, мы должны были предвидеть подобную проблему и добавить все соответствующие метрики. На практике это сложно, поэтому команды обычно начинают с минимального или общего дашборда и развивают его по мере того, как узнают больше о работе своих приложений. Первая проблема с дашбордами как инструментами для устранения неполадок заключается в том, что они часто бывают неполными — чтобы накопить опыт, требуется время. В случае с Asserts у нас есть библиотека многократно используемых утверждений, из которой можно черпать информацию. Поэтому мы начинаем с гораздо более богатой базовой информации.
Во-вторых, при устранении неполадок с дашбордом вам нужно решить, стоит ли та или иная метрика дальнейшего изучения, пока вы ищете первопричину. Если дашборд большой, этот процесс становится довольно трудоёмким, поэтому в дашборд нужно включать только самые важные метрики. Как правило, дашборды неполные, что приводит к ещё более медленному специальному исследованию. При устранении неполадок с помощью утверждений вы начинаете с поиска потенциальных проблем, что приводит к значительному сокращению списка. Как только мы ограничиваем поиск наиболее важными метриками, поиск неисправностей становится намного более быстрым.
Устранение проблемы
Но как предотвратить это в будущем? Поскольку мы не собираемся блокировать выполнение пользователями ad hoc запросов, но в то же время сложно заранее предсказать потребление ими ресурсов, мы отделили ad hoc запросы от оценки правил оповещения, запустив несколько развёртываний vmselect.
Теперь для оценки правил оповещений выделены отдельные экземпляры vmselect, что обеспечивает надёжную доставку оповещений. Все запросы от дашбордов и пользователей обслуживаются vmselect-user, и самое худшее, что может случиться, если пользователь напишет дорогой запрос, — ему придётся его доработать, прежде чем он увидит результаты.
vmselect: оригинальный vmselect, отвечающий за оповещения, и vmselect-user, который обрабатывает запросы с произвольным доступом.Подведём итоги: Asserts упростит ваш рабочий процесс по устранению неполадок и избавит от ежедневной рутины по созданию и управлению дашбордами и оповещениями.
И напоследок приглашаем всех, кто занимается нагрузочным тестированием, на открытые уроки: