🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 134 (from laksa191)

2. Crawled Status Check

Query:

curl -X POST \
  'http://laksa134.int.ahrefs:8124/' \
  -H 'Content-Type: text/plain' \
  -H 'X-ClickHouse-Database: crawler3' \
  -H 'Authorization: Basic YXBpOg==' \
  -d 'SELECT getAhrefsURLFromUnparsed(src_unparsed) AS found_url, ifNull(toUnixTimestamp(download_stamp), 0) AS crawl_time, ifNull(toUnixTimestamp(props_url_first_seen), 0) AS first_indexed_time, download_http_code AS http_code, src_unparsed AS src_unparsed, src_root_hash AS src_root_hash, history_drop_reason AS history_drop_reason, meta_title AS meta_title, meta_descriptions AS meta_descriptions, attrs_boilerpipe_text AS attrs_boilerpipe_text, attrs_markdown AS attrs_markdown, attrs_readable_markdown AS attrs_readable_markdown, meta_canonical AS meta_canonical FROM crawler3.page_info_local FINAL PREWHERE (src_root_hash, src_unparsed) IN ((getAhrefsRootHashFromUnparsed(getAhrefsUnparsedNoserviceFromURL(\'https://habr.com/ru/companies/etpgpb_vesna/articles/946000/\')), getAhrefsUnparsedNoserviceFromURL(\'https://habr.com/ru/companies/etpgpb_vesna/articles/946000/\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/946000\/","crawl_time":1774696156,"first_indexed_time":1757586911,"http_code":200,"src_unparsed":"com,habr!\/ru\/companies\/etpgpb_vesna\/articles\/946000\/ s443","src_root_hash":"14843476518697139734","history_drop_reason":null,"meta_title":"Мониторинг и анализ производительности бэкенда с помощью ClickHouse и Grafana. Часть 3 \/ Хабр","meta_descriptions":["Ссылка на часть 1 Ссылка на часть 2 Всем привет! Я Артём Седых, работаю ведущим разработчиком команды банковского сопровождения. Проекту уже девятый год, накопилась большая функциональная база и много..."],"attrs_boilerpipe_text":"Ссылка на часть 1\nСсылка на часть 2\nВсем привет! Я Артём Седых, работаю ведущим разработчиком команды банковского сопровождения. Проекту уже девятый год, накопилась большая функциональная база и много легаси-кода с набором узких мест для возможной оптимизации. В данном наборе статей рассказываю про наш опыт разработки и внедрения собственной системы мониторинга бэкенда PHP с возможностью просмотреть, как именно проседают экшены, и даже спрогнозировать их поведение. Если не читали предыдущие части, ссылки выше. Сегодня, в третьей и заключительной части, рассмотрим мониторинг со стороны devops на дашбордах SLI\/Apdex, поколдуем над статистическими методами для прогноза снижения производительности (рубрика «эксперименты»), поговорим об автоматических уведомлениях Grafana. Оценим перспективы развития, сравнительный анализ выбранного подхода и выводы по нашему опыту. Заваривайте любимый напиток, приятного прочтения!\nРасследование проблемных параметров\nВ прошлой части было много дашбордов для изучения и оценки больше количественных показателей по проекту и экшенам с самой разнообразной агрегацией. Теперь попробуем получить информацию из метрики параметров. Дашборд покажет, какие именно параметры загружают систему дольше всего вместе с их количеством и количеством ошибок. Выполняется группировка по parameters.\nОтследить, какие именно параметры имеют больше влияния на время работы системы\nДля лучшей четкости картинки можно открыть в новой вкладке.\nДашборд расследования параметров\nТут уже вступает анализ конкретных данных, стоит обратить внимание: а всё ли нормально с этими параметрами, корректно ли обрабатываются и почему обработка так долго занимает. Добавлен фильтр по пользователю: если есть тяжелый пользователь с дашборда ТОПов, здесь увидим, какие параметры он запрашивает. На второй таблице можно точечно отследить конкретные запросы конкретного юзера с конкретными параметрами и получить по ним статистику. Часто помогает и наоборот: если на других дашбордах видно аномалию, этот дашборд покажет, при каком наборе параметров она возникает.\nДашборд SLI и Apdex\nСо стороны бизнеса и devops первое, на что стоит обратить внимание, – конкретные показатели производительности по стандартам SRE (Site Reliability Engineering) вроде\nSLI\nи\nApdex\nпо четко выставленным критериям. Это вполне реализуемо на текущих инструментах в разрезе каждого тега и экшена. До сих пор в ClickHouse использовали только одну таблицу – таблицу логов. Для удобства аналитики укажем целевые показатели SLI и Apdex по времени отклика прямо в CH в виде отдельной таблицы – это позволит приджойниться и динамически отследить соответствие метрик поставленным целям. Мы выбрали разное время для разных тегов исходя из природы операции. Например, время на загрузку списка сущностей в таблицу фронтенда должно быть довольно мало, т. к. это наиболее востребованное действие в системе. При этом на тяжелую операцию импорта или интеграции можно заложить побольше, особенно если пользователь не участвует в операции и не ждет немедленной реакции.\nПеречень колонок таблицы с целевыми показателями по времени SLI и Apdex:\nlog_target(\naction_tag\n,\nslo_percent, sli_time\n,\napdex_time\n)\nПри вычислении по формулам целевое время выбирается из этой таблицы по конкретному тегу в логе операций.\nОтследить показатели производительности сервиса по стандартам Google Site Reliability Engineering\nПример SLI\nФормула расчета показателя\nДашборд отслеживания SLI\nВидно как глобальный индекс, так и с разбивкой по тегам и экшенам. В таблице видно тяжелые экшены по показателю SLI с сортировкой по низкому %. В первую очередь стоит заняться оптимизацией красной зоны. Дополнительно планируем вычислять характеристику импакта в целом по системе: к примеру, экшен А вызвали всего 2 раза за день, он нарушил сроки и находится в красной зоне, а экшен Б вызвали 10 000 раз, но он обитает в желтой зоне – всё же оптимизировать Б до зеленого важнее, чем помочь единичным вызовам экшена А. Эта характеристика даст больше информации и понимания при выборе приоритетов для оптимизации.\nПример Apdex\nФормула расчета показателя\nДашборд отслеживания Apdex\n Apdex покажет комфорт пользователей при работе в системе относительно отдельных тегов и экшенов. Целевое время зададим ниже отметки для SLI как рекомендованное время для удобства пользователя. Покажет, где пользователи ждут больше обычного в наглядных областях «хороший», «медленный» и «плохой». Разобравшись с проблемами по SLI, можно будет приняться за улучшение показателя Apdex.\nДашборд Business Apdex\nОтследить показатели производительности сервиса метрикой Apdex с группировкой по бизнес-понятиям. Вместо специфичных для разработки понятий (тег, экшен, контроллер) отобразить информацию в виде удобных и понятных панелей-карточек. Каждая панель отображает одну из частей системы с человеческим названием и может в себе группировать один или несколько экшенов.\nДля возможности группировки и мониторинга по бизнес-понятиям заведем таблицу в ClickHouse с колонками:\nlog_business_target(\naction_tag, controller, action,\nbusiness_target, apdex_time\n,\npriority\n)\nКонфигурация поможет гибко настроить маппинг tag-controller-action => понятие + целевое время для Apdex. Выполняется группировка по понятиям и сортировка по приоритету. Список понятий формируется эмпирически, что именно необходимо отслеживать по системе. В одну карточку могут попасть как один конкретный экшен, так и целая группа, покрывающая часть логики сервиса. В Grafana используется элемент Canvas с настройкой Repeat by variable (business_target).\nПример дашборда на тестовом наборе данных, где части системы были под нагрузкой (чтобы показать разные цвета):\nДашборд отслеживания Apdex для отслеживания именованных показателей Apdex\n●      Отображает для каждого бизнес-понятия панель с состоянием Apdex за указанный период Grafana человеческими словами.\n●      Отображает динамику по сравнению с предыдущим периодом (+-0.xx).\n●      Отображает справочную информацию о целевом времени и о количестве запросов.\n●      Позволяет отфильтровать только нужные бизнес-понятия либо вывести все сразу.\nКаждая карточка нацелена на свое время Apdex, и помимо самого индекса отображает дополнительную информацию. Дашборд использовать как средство мониторинга состояния системы для менеджеров, бизнес-аналитиков, заказчиков и других заинтересованных лиц.\nДашборд оценки и прогнозирования производительности экшенов\nОднажды при наблюдении за статистикой по экшенам появилась мысль:\n«если у нас такой богатый объем данных, есть статистика производительности экшена и есть числовые показатели, на каких масштабах данных выполнялся экшен, почему бы не зайти дальше и не попытаться оценить, как себя поведет экшен в будущем при росте этих показателей?».\nСказано – сделано: кастомный инструмент очередной раз показал, насколько быстро и гибко получается накидывать дашборды, ограничиваясь лишь фантазией и здравым смыслом.\nИспользуя статистические методы, оценить зависимость используемых ресурсов от объема данных и спрогнозировать поведение экшена.\nОценка и прогнозы основаны на базовых методах математической статистики и подвержены ухудшению при аномалиях или недостаточном количестве данных. В основе стоит гипотеза о том, что потребление экшеном ресурса (время и RAM) зависит от объема данных, который представлен количеством SQL-запросов либо длительностью их выполнения. Если же экшен по природе не меняет количество или общую длительность SQL-запросов, корреляцию этим дашбордом обнаружить не получится.\nТекущий алгоритм, по которому выполняется оценка сложности O(n^x): анализ сложности на основе регрессии логарифмов или log-log regression analysis \/ plot в английской терминологии (\nссылка 1\n,\nссылка 2\n, больше про сложность и линейную регрессию при оценке алгоритмов –\nссылка 3\n). Стоит отметить, это ни в коем случае не аналитическая сложность алгоритма (экшена), а сложность в бытовом понимании – оценить, насколько увеличивается время работы от объема данных, и попытаться предсказать, сколько времени займет при увеличении этого объема.\nКлючевые моменты (под спойлером)\nДва предположительно      взаимосвязанных массива данных в отношении a => b.\nИспользуется натуральный логарифм. Логарифм превращает      сложную степенную зависимость в линейную, чтобы легко найти показатель      сложности slope через линейную регрессию.\nРасчет ковариации и дисперсии. Ковариация – это статистическая      мера того, насколько две переменные изменяются вместе. В нашем случае это      мера того, как ln(total_sql_queries) и ln(duration_s) изменяются      относительно друг друга. Дисперсия – это мера разброса значений      переменной. Здесь мы используем дисперсию ln(total_sql_queries).\nРасчет наклона (slope). Наклон линии регрессии в      log-log пространстве рассчитывается как отношение ковариации к дисперсии.      Этот наклон и есть показатель сложности алгоритма.\nИнтерпретация наклона. Если наклон близок к 1, это указывает на линейную сложность      O(N). Наклон между 1 и 2 может указывать на сложность O(N*log(N)).      Наклон около 2 указывает на квадратичную сложность O(N^2).      Другие значения наклона интерпретируются как O(N^slope).\nЭкстраполяция. Используя полученный      наклон (slope), мы можем предсказать время выполнения для больших      объемов данных.\nДашборд в альфа-версии. Список улучшений на будущее: улучшить качество оценки (другие алгоритмы прогноза; нейронная сеть лучше отследит закономерности), убрать недостоверную оценку (отрицательную сложность), снизить влияние аномалий и шумов на оценку, дать возможность повысить приоритет точек на экстремумах.\nПримеры – оценка и прогноз времени отклика экшена в зависимости от объема данных\nПример импорта позиций спецификации из XLSX. Значение prediction_multipler задает, насколько далеко мы желаем увеличить объемы данных для прогноза, обычно ×1 хватает для просмотра кривой сложности.\nДашборд прогнозирования сложности времени на примере экшена типа import\nПопробуем оценить результат:\n●      Время импорта нелинейно зависит от количества SQL-запросов. Степенная сложность O(n^3) может говорить о том, что используется алгоритм вида for-for-for с тяжелой операцией во внутреннем цикле, стоит пересмотреть алгоритм импорта.\n●      Время импорта линейно зависит от длительности SQL-запросов, здесь мало пользы.\nПример экспорта списка позиций реестра платежей в XLSX\nДашборд прогнозирования сложности времени на примере экшена типа export\n●      Время экспорта не зависит от количества SQL-запросов (количество запросов не меняется, а время растет) – оценка сложности невозможна.\n●      Время экспорта почти линейно зависит от длительности SQL-запросов. Сейчас проблемы нет, однако можем спрогнозировать, при каком росте объема данных наступит лимит по времени выполнения для пользователя.\nОценка и прогноз времени CPU в зависимости от объема данных\nВ предыдущем прогнозе время отклика содержит в себе и собственно время обработки SQL-запросов (а по нему мы и пытаемся оценить зависимость). Как тогда найти сложные вычислительные алгоритмы и операции самого кода без учета запросов к БД? При оценке сложности берем общее время отклика и минус время из метрик типа Duration. Останется т. н. время CPU, не учтенное ни в каких других метриках Duration. Повышенный slope времени CPU, скорее всего, и будет означать медленный код: недостаточно эффективные алгоритмы; медленные библиотеки.\nРассмотрим на примере экспорта списка компаний заявки. Оценка времени отклика показала O(n^0.36) и O(n^0.41). Однако если оценивать время без БД и внешних запросов:\nДашборд прогнозирования сложности времени CPU на примере экшена типа export\nВремя CPU более чем линейно зависит от количества SQL-запросов. Это говорит о неэффективном использовании алгоритмов (действительно, используется медленная библиотека для генерации файла экспорта – phpspreadsheet). После перехода на собственную разработку, которая распаковывает xlsx и работает с xml, как со строками, получилось снизить сложность.\nТот же экшен после внедрения оптимизации\n \nОценка и прогноз использования RAM в зависимости от объема данных\nПример экспорта списка позиций в XLSX\nДашборд прогнозирования сложности потребления RAM на примере экшена типа export\nМаксимальный объем задействованной оперативной памяти более чем линейно зависит от длительности SQL-запросов. Это говорит о неэффективном использовании RAM (действительно, используется библиотека phpspreadsheet, которая в базовой реализации требует многократного объема оперативной памяти).\nДашбор ТОПов экшенов по оценке сложности\nТОПы по оценке сложности среди экшенов контроллера request\nАналогично разделу ТОПов дашборд составлен для быстрого поиска экшенов с высокой оценкой сложности по перечисленным критериям. Это позволит обнаружить экшены, которые в перспективе могут стать тяжелыми при увеличении объемов данных. Как и намекает JSON Statham с картинки, не стоит верить статистике: необязательно высокая оценка сложности приведет к медленному экшену в перспективе. Каждый экшен лучше дополнительно анализировать и изучать текущую статистику: может ли существенно увеличиться объем данных; как часто экшен вызывается; насколько важно заниматься оптимизацией. Оценка также может быть рассчитана неточно: повлияют аномалии, шумы или недостаток данных. С опытом и анализом по другим дашбордам придет понимание, на какие экшены действительно стоит обратить внимание при закладывании оптимизации.\nАвтоматические оповещения\nАналитики с других дашбордов уже хватает на месяцы работ по оптимизации. В перспективе понадобятся автоматические рассылки при резком снижении производительности экшена. Возможности Grafana alerts позволяют гибко настроить правила рассылок, а составление запросов с помощью SQL развязывает руки в плане вариантов событий.\nИнтерфейс Grafana для настройки автоматических уведомлений\nПример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд\nТут и пригодилась таблица с настройками по целевым показателям SLI: например, можно создать алерт со списком экшенов, которые нарушили SLO за выбранный период.\nSELECT l.controller_name || '.' || l.action_name AS action,\n       lt.slo_percent, ROUND((countIf(l.duration_s <= lt.sli_time) \/ COUNT(*)) * 100, 2) AS sli_current\nFROM logs AS l\nJOIN log_target AS lt ON l.action_group_tag = lt.action_tag\nWHERE $__timeFilter(l.start_datetime) AND l.success\nGROUP BY l.controller_name, l.action_name, lt.slo_percent\nHAVING ROUND((countIf(l.duration_s <= lt.sli_time) \/ COUNT(*)) * 100, 2) < lt.slo_percent;\nПример результата по алерту нарушения SLO\nМожно строить любые запросы и выдавать в уведомлении всё, что выдаст этот запрос. Можно запросом получать некоторую метрику и в автоматическом режиме задать правила и значения, при которых оповещение будет рассылаться. Поддерживаются самые разнообразные экспортеры: почта, смс, телеграм и другие мессенджеры.\n Примеры условий для алертов по экшенам:\n●      Тяжелый запрос БД – % БД по времени дольше остальных %.\n●      Запросы к БД – больше 5 000 запросов в одном вызове экшена.\n●      Много итераций в интеграции – интеграция в цикле.\n●      Неоптимизированный код – долгое время вычисления CPU.\n●      Большое потребление памяти – медиана по потреблению за полчаса от 100 МБ.\n●      Триггеры на изменения – метрика по экшену выросла более 50% относительно обычного в данный период.\n●     \nНа вырост\n– прогнать\nнейронную сеть\nчерез\nбазу кейсов\n: когда потребовалась критичная оптимизация, получим рекомендации SQL-запросов по неочевидным взаимосвязям метрик.\nДальнейшее развитие инструмента\nПо мере накопления опыта и подключения других проектов появляется всё больше идей для развития и усовершенствования инструмента:\n●      Больше метрик (FS, cache, Request\/Response size, AMQP, TOP SQL, near\/far external requests …)\n●      Автоматическая конфигурация метрик (заведение любых метрик типов IDENT\/Single\/Count\/Duration) с автоинициализацией БД и дашбордов\n●      Автоматический сбор метрик в популярных фреймворках\n●      Оптимизация времени отправки (например, с демоном и posix shared memory\/UDP\/TCP)\n●      Адаптация под другие языки, поддержка микросервисов\n●      Больше дашбордов (P95\/P99…), возможность сократить дашборды для уменьшения дублирования информации, улучшение алгоритмов прогноза (нейронка)\n●      Автоматические отчеты на почту\n●      Расширение списка триггеров для Grafana alerts (+нейронка)\n●      Мониторинг статистики для отслеживания тенденций использования сервиса (тренды развития проекта для аналитиков)\n●      Связать с мониторингом железа (USE+)\n●      Добавить показатели по фронтенду\n●      Подключить отказы и прерывания – тем самым добавим метрики недоступности по экшенам\n●      Генерация аналитических запросов с помощью LLM, которая находится в контексте проекта\n●      Опциональное включение профайлинга а-ля pinba для конкретных экшенов (must have для поиска конкретных мест в коде при оптимизации)\nПутей для развития много, но кажется лишним двигаться в сторону Sentry и агрегировать вообще всё отовсюду и всегда. Вместо разработки универсального инструмента хочется сконцентрироваться на конкретной проблеме контроля производительности, помочь разработчикам быстро и плавно обнаружить и разобраться с проблемами на продакшене. Добавить уверенности в стабильной и качественной работе сервиса.\nПлюсы и минусы используемого подхода\nПреимущества используемых инструментов – большая гибкость как по метрикам, так и по методу отправки и отображаемому анализу, почти нет влияния на время отклика (чуть задерживаем fpm), малый объем для хранения, легко разрабатывать новые дашборды. SQL в качестве анализа – очень удобный язык. Текущие дашборды позволяют со всех сторон взглянуть на бэкенд и прозрачно видеть все аспекты производительности.\nТеперь по недостаткам по сравнению с аналогичными решениями:\n●      Ручное подключение статических вызовов в pipeline экшена. Вручную придется заводить БД и выполнять инициализирующие запросы. Хоть и настройка дашбордов решается импортом JSON файла в графану. Проблема ручного подключения решается разработкой версий библиотеки по сбору метрик для конкретных фреймворков.\n●      Аналоги в виде Uptrace и Sentry подключить быстрее, и они возможно дают более глубокую аналитику (например, указывают место в коде, но для этого приходится эту информацию хранить и занимать трафик\/место). Мы делаем чуть по-другому: концентрация на мониторинге небольшого набора метрик, агрегация показателей на разных аспектах производительности вкупе с аналитикой с точки зрения вызовов конкретных экшенов с помощью SQL.\n●      Пока среди языков поддерживается только PHP. При этом сама библиотека для сбора и отправки укладывается в 200 строк кода. При необходимости можно взять пример и написать реализацию для своего языка с подходящим методом сбора и отправки.\n●      Микросервисы – сложнее отследить, но можно добавить единую метрику trace_id. С группировкой по trace_id отслеживать целиком процесс затрагивающий несколько микросервисов.\n●      В текущей схеме сложно увидеть недоступность сервиса для показателей SLI по доступности (отказы регистрируются на уровне железа), тут можем поставить дополнительный сканер и отвалившиеся запросы логировать на входе балансера\/nginx и записывать в ту же БД кликхауза.\n●      Prometheus больше оптимизирован под хранение и выборку одиночных метрик в виде временных рядов, данные могут занимать меньше места, но дольше вставка, и, если не заложились на определенную структуру, возможно, будет дольше выборка данных особенно на сложных агрегациях по нескольким метрикам сразу. Вместо SQL используется свой язык PromQL, может чуть неудобен для сложных аналитических запросов и нужно отдельно знакомиться с синтаксисом.\nИтоги\nГусь наконец отстал от нас и занялся музыкой =)\n●      В больших проектах важно отслеживать производительность с прицелом на конкретные экшены – мониторинг и анализ.\n●      Можно не ограничиваться стандартами RED\/USE, SLI\/Apdex – добавлять метрики и аналитику, полезные именно вашему проекту.\n●      Не просто живые графики, но и статистика вроде таблиц ТОПов, желательно с автоматическими оповещениями + прогнозы.\n●      Своевременная оптимизация снизит тревогу пользователей и улучшит отзывы о работе системы.\nИнструмент назвали\nVESNA.Insight\n– система детального мониторинга и анализа производительности сервисов с прицелом на конкретные действия пользователей. Позволяет с легкостью мониторить аспекты производительности более тысячи экшенов: время выполнения, нагрузка на БД, CPU, ожидание HTTP-запросов, RAM, ошибки. Реализована возможность группировки действий по типам, задание критичных точек по различным аспектам и мониторинг всей группы с отслеживанием выполнения целевых показателей. Довольно быстро добавляются новые метрики, расширяются панели мониторинга и аналитики.\nБлагодаря дашборду ТОПов создаем несколько задач оптимизации для разработчиков еженедельно, сокращает время на поиск узких мест. Каждой задаче помимо описания действия дашборды сообщают ценную информацию о критичности правки, какие аспекты требуют оптимизации, оценку сложности алгоритмов и предсказание производительности, получить рекомендации по оптимизации из предыдущих кейсов работы с подобными задачами.\nClickHouse отрабатывает очень шустро, индекса по времени хватает на то, что все перечисленные дашборды загружаются менее чем за 1 секунду. Агрегации моментальные: при отрисовке глобальной статистики – даже без фильтра по времени – десятки миллионов строк логов обрабатываются за пару секунд.\nБлагодаря Grafana с плагином кликхауз можем отправлять автоматические уведомления при превышении настроенных целевых показателей по всем отслеживаемым аспектам производительности сервиса. Оценка и прогнозирование производительности дают возможность получать уведомления вида «Импорт данных превысит лимит времени\/RAM при росте объема на 200%» и заложить ресурсы на оптимизацию заранее.\nИнструмент в первую очередь разрабатывался для внутренних нужд и уже преобразовал просто ручные точечные применения улучшений на управление целым комбайном производительности сервиса. Для коллег из интеграционных систем это гарантия бесперебойности работы с самыми важными контрактами. Для компании и менеджмента – снижение рисков, улучшение показателей работы команды и впечатлений по работе с сервисами. Для разработчиков, QA и аналитиков по проекту – уменьшение неудобств при попытках исследовать проблему с продакшена, меньше отвлечений на оперативные правки, больше уверенность при доработке тяжелых экшенов. Ну и наконец, для пользователей – отсутствие подтормаживающих экшенов и увеличение комфорта позволяет спокойно работать в системе.\nЯ же с удовольствием провел время, разбираясь в тонкостях мониторинга, аспектах производительности и, аки детектив, выслеживал проблемные места в крупном легаси-проекте с помощью построения нужных дашбордов. После долгих лет ручного разбора логов наконец появилась возможность видеть, как методы оживают в продакшене и весь бэкенд становится видно насквозь. Чувствуется осуществление моей мечты, как бэкенд-разработчика, болеющего за свой проект. Несколько раз в месяц во время работы над задачами возникают идеи всё новых метрик и дашбордов и что с их помощью можно обнаружить – такой инструмент позволяет быстро и просто за считанные дни накидывать в графану всё необходимое. Весьма интересно, куда эта дорожка приведет в дальнейшем, какие нюансы производительности получится вскрыть и какие рубежи преодолеть.\nПослесловие\nОгромное спасибо всем, кто дочитал до конца и выжил! В комментариях предлагаю обсудить не только предложенный инструмент, но и ваш опыт внедрения или использования подобного мониторинга. Особенно если работали с Sentry\/Uptrace\/.. или, может, даже разработали свой аналог, прошу рассказать о впечатлениях использования этих инструментов и какой аспект больше всего пригодился. Разумеется, задавайте вопросы и пишите рекомендации по улучшению. Спасибо за поддержку и ценный фидбэк! Ещё хочется послушать, как бы пригодился подобный инструмент в вашем языке (или, может, ваш язык уже имеет мощный встроенный инструмент мониторинга и анализа производительности экшенов и подключать что-то ещё не требуется?), какие метрики 100% нужно добавить, а какие будут бесполезны.\nА так – хочется пожелать всем быстрых сервисов и безотказных экшенов, при всем этом – спокойной разработки и размеренной оптимизации. До встречи!","attrs_markdown":"[Все потоки](https:\/\/habr.com\/ru\/articles\/)\n\n[Войти](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr\/?back=\/ru\/companies\/etpgpb_vesna\/articles\/946000\/&hl=ru)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/company\/f4f\/29f\/9d3\/f4f29f9d312a85b3b1abe9bcfcad1ab8.png)](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/profile\/)\n\n[ЭТП ГПБ \/ VESNA](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/profile\/)\n\n4,37\n\nОценка работодателя\n\n46,89\n\nРейтинг\n\n27\n\nПодписчики\n\nПодписаться\n\n[![](https:\/\/habrastorage.org\/r\/w48\/getpro\/habr\/avatars\/7c1\/033\/627\/7c10336274775082efe7d847711b0f26.jpeg)](https:\/\/habr.com\/ru\/users\/chronoexp\/)\n\n[chronoexp](https:\/\/habr.com\/ru\/users\/chronoexp\/)\n\n11 сен 2025 в 10:26\n# Мониторинг и анализ производительности бэкенда с помощью ClickHouse и Grafana. Часть 3\nСредний\n\n15 мин\n\n9\\.3K\n\n[Блог компании ЭТП ГПБ \/ VESNA](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/)[Анализ и проектирование систем \\*](https:\/\/habr.com\/ru\/hubs\/analysis_design\/) [PHP \\*](https:\/\/habr.com\/ru\/hubs\/php\/) [DevOps \\*](https:\/\/habr.com\/ru\/hubs\/devops\/) [Веб-разработка \\*](https:\/\/habr.com\/ru\/hubs\/webdev\/)\n\nКейс\n\n> [Ссылка на часть 1](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/939742)\n\n> [Ссылка на часть 2](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/944148)\n\nВсем привет! Я Артём Седых, работаю ведущим разработчиком команды банковского сопровождения. Проекту уже девятый год, накопилась большая функциональная база и много легаси-кода с набором узких мест для возможной оптимизации. В данном наборе статей рассказываю про наш опыт разработки и внедрения собственной системы мониторинга бэкенда PHP с возможностью просмотреть, как именно проседают экшены, и даже спрогнозировать их поведение. Если не читали предыдущие части, ссылки выше. Сегодня, в третьей и заключительной части, рассмотрим мониторинг со стороны devops на дашбордах SLI\/Apdex, поколдуем над статистическими методами для прогноза снижения производительности (рубрика «эксперименты»), поговорим об автоматических уведомлениях Grafana. Оценим перспективы развития, сравнительный анализ выбранного подхода и выводы по нашему опыту. Заваривайте любимый напиток, приятного прочтения\\!\n\n### Расследование проблемных параметров\nВ прошлой части было много дашбордов для изучения и оценки больше количественных показателей по проекту и экшенам с самой разнообразной агрегацией. Теперь попробуем получить информацию из метрики параметров. Дашборд покажет, какие именно параметры загружают систему дольше всего вместе с их количеством и количеством ошибок. Выполняется группировка по parameters.\n\n`Отследить, какие именно параметры имеют больше влияния на время работы системы`\n\nДля лучшей четкости картинки можно открыть в новой вкладке.\n\n![Дашборд расследования параметров](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/629\/d2f\/86a\/629d2f86a7ef45cadc3a7ad7d72334ee.png)\n\n*Дашборд расследования параметров*\n\nТут уже вступает анализ конкретных данных, стоит обратить внимание: а всё ли нормально с этими параметрами, корректно ли обрабатываются и почему обработка так долго занимает. Добавлен фильтр по пользователю: если есть тяжелый пользователь с дашборда ТОПов, здесь увидим, какие параметры он запрашивает. На второй таблице можно точечно отследить конкретные запросы конкретного юзера с конкретными параметрами и получить по ним статистику. Часто помогает и наоборот: если на других дашбордах видно аномалию, этот дашборд покажет, при каком наборе параметров она возникает.\n\n### Дашборд SLI и Apdex\nСо стороны бизнеса и devops первое, на что стоит обратить внимание, – конкретные показатели производительности по стандартам SRE (Site Reliability Engineering) вроде [SLI](https:\/\/habr.com\/ru\/articles\/718796\/) и [Apdex](https:\/\/habr.com\/ru\/companies\/sravni\/articles\/802705\/) по четко выставленным критериям. Это вполне реализуемо на текущих инструментах в разрезе каждого тега и экшена. До сих пор в ClickHouse использовали только одну таблицу – таблицу логов. Для удобства аналитики укажем целевые показатели SLI и Apdex по времени отклика прямо в CH в виде отдельной таблицы – это позволит приджойниться и динамически отследить соответствие метрик поставленным целям. Мы выбрали разное время для разных тегов исходя из природы операции. Например, время на загрузку списка сущностей в таблицу фронтенда должно быть довольно мало, т. к. это наиболее востребованное действие в системе. При этом на тяжелую операцию импорта или интеграции можно заложить побольше, особенно если пользователь не участвует в операции и не ждет немедленной реакции.\n\nПеречень колонок таблицы с целевыми показателями по времени SLI и Apdex:\n\n`log_target(action_tag, slo_percent, sli_time, apdex_time)`\n\nПри вычислении по формулам целевое время выбирается из этой таблицы по конкретному тегу в логе операций.\n\n`Отследить показатели производительности сервиса по стандартам Google Site Reliability Engineering`\n\nПример SLI\n\n![Формула расчета показателя](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/f51\/94c\/ed6\/f5194ced6f26253d498ee0f5f9cdf429.png)\n\nФормула расчета показателя\n\n![Дашборд отслеживания SLI](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/65e\/62e\/a88\/65e62ea88317d5e05278327c48a441e6.png)\n\n*Дашборд отслеживания SLI*\n\nВидно как глобальный индекс, так и с разбивкой по тегам и экшенам. В таблице видно тяжелые экшены по показателю SLI с сортировкой по низкому %. В первую очередь стоит заняться оптимизацией красной зоны. Дополнительно планируем вычислять характеристику импакта в целом по системе: к примеру, экшен А вызвали всего 2 раза за день, он нарушил сроки и находится в красной зоне, а экшен Б вызвали 10 000 раз, но он обитает в желтой зоне – всё же оптимизировать Б до зеленого важнее, чем помочь единичным вызовам экшена А. Эта характеристика даст больше информации и понимания при выборе приоритетов для оптимизации.\n\nПример Apdex\n\n![Формула расчета показателя](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/250\/b49\/652\/250b49652f50da314285e78050165eb5.png)\n\nФормула расчета показателя\n\n![Дашборд отслеживания Apdex](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/7d4\/b02\/6ac\/7d4b026acb886dd79172f1992f19b130.png)\n\n*Дашборд отслеживания Apdex*\n\nApdex покажет комфорт пользователей при работе в системе относительно отдельных тегов и экшенов. Целевое время зададим ниже отметки для SLI как рекомендованное время для удобства пользователя. Покажет, где пользователи ждут больше обычного в наглядных областях «хороший», «медленный» и «плохой». Разобравшись с проблемами по SLI, можно будет приняться за улучшение показателя Apdex.\n\n### Дашборд Business Apdex\nОтследить показатели производительности сервиса метрикой Apdex с группировкой по бизнес-понятиям. Вместо специфичных для разработки понятий (тег, экшен, контроллер) отобразить информацию в виде удобных и понятных панелей-карточек. Каждая панель отображает одну из частей системы с человеческим названием и может в себе группировать один или несколько экшенов.\n\nДля возможности группировки и мониторинга по бизнес-понятиям заведем таблицу в ClickHouse с колонками:\n\n`log_business_target(action_tag, controller, action, business_target, apdex_time, priority)`\n\nКонфигурация поможет гибко настроить маппинг tag-controller-action =\\> понятие + целевое время для Apdex. Выполняется группировка по понятиям и сортировка по приоритету. Список понятий формируется эмпирически, что именно необходимо отслеживать по системе. В одну карточку могут попасть как один конкретный экшен, так и целая группа, покрывающая часть логики сервиса. В Grafana используется элемент Canvas с настройкой Repeat by variable (business\\_target).\n\nПример дашборда на тестовом наборе данных, где части системы были под нагрузкой (чтобы показать разные цвета):\n\n![Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/ff6\/1b2\/559\/ff61b255953cc901cf18db31a79d2393.png)\n\n*Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex*\n\n● Отображает для каждого бизнес-понятия панель с состоянием Apdex за указанный период Grafana человеческими словами.  \n  \n● Отображает динамику по сравнению с предыдущим периодом (+-0.xx).  \n  \n● Отображает справочную информацию о целевом времени и о количестве запросов.  \n  \n● Позволяет отфильтровать только нужные бизнес-понятия либо вывести все сразу.\n\nКаждая карточка нацелена на свое время Apdex, и помимо самого индекса отображает дополнительную информацию. Дашборд использовать как средство мониторинга состояния системы для менеджеров, бизнес-аналитиков, заказчиков и других заинтересованных лиц.\n\n### Дашборд оценки и прогнозирования производительности экшенов\nОднажды при наблюдении за статистикой по экшенам появилась мысль: *«если у нас такой богатый объем данных, есть статистика производительности экшена и есть числовые показатели, на каких масштабах данных выполнялся экшен, почему бы не зайти дальше и не попытаться оценить, как себя поведет экшен в будущем при росте этих показателей?».* Сказано – сделано: кастомный инструмент очередной раз показал, насколько быстро и гибко получается накидывать дашборды, ограничиваясь лишь фантазией и здравым смыслом.\n\n`Используя статистические методы, оценить зависимость используемых ресурсов от объема данных и спрогнозировать поведение экшена.`\n\nОценка и прогнозы основаны на базовых методах математической статистики и подвержены ухудшению при аномалиях или недостаточном количестве данных. В основе стоит гипотеза о том, что потребление экшеном ресурса (время и RAM) зависит от объема данных, который представлен количеством SQL-запросов либо длительностью их выполнения. Если же экшен по природе не меняет количество или общую длительность SQL-запросов, корреляцию этим дашбордом обнаружить не получится.\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/dd0\/136\/ec0\/dd0136ec0c02d5b6a3564691a8bf1b9e.png)\n\nТекущий алгоритм, по которому выполняется оценка сложности O(n^x): анализ сложности на основе регрессии логарифмов или log-log regression analysis \/ plot в английской терминологии ([ссылка 1](https:\/\/en.wikipedia.org\/wiki\/Log%E2%80%93log_plot), [ссылка 2](https:\/\/www.vexpower.com\/brief\/log-log-model), больше про сложность и линейную регрессию при оценке алгоритмов – [ссылка 3](https:\/\/ppml.dev\/algorithms.html)). Стоит отметить, это ни в коем случае не аналитическая сложность алгоритма (экшена), а сложность в бытовом понимании – оценить, насколько увеличивается время работы от объема данных, и попытаться предсказать, сколько времени займет при увеличении этого объема.\n\nКлючевые моменты (под спойлером)\n\n1. Два предположительно взаимосвязанных массива данных в отношении a =\\> b.\n2. Используется натуральный логарифм. Логарифм превращает сложную степенную зависимость в линейную, чтобы легко найти показатель сложности slope через линейную регрессию.\n3. Расчет ковариации и дисперсии. Ковариация – это статистическая мера того, насколько две переменные изменяются вместе. В нашем случае это мера того, как ln(total\\_sql\\_queries) и ln(duration\\_s) изменяются относительно друг друга. Дисперсия – это мера разброса значений переменной. Здесь мы используем дисперсию ln(total\\_sql\\_queries).\n4. Расчет наклона (slope). Наклон линии регрессии в log-log пространстве рассчитывается как отношение ковариации к дисперсии. Этот наклон и есть показатель сложности алгоритма.\n5. Интерпретация наклона. Если наклон близок к 1, это указывает на линейную сложность O(N). Наклон между 1 и 2 может указывать на сложность O(N\\*log(N)). Наклон около 2 указывает на квадратичную сложность O(N^2). Другие значения наклона интерпретируются как O(N^slope).\n6. Экстраполяция. Используя полученный наклон (slope), мы можем предсказать время выполнения для больших объемов данных.\n\nДашборд в альфа-версии. Список улучшений на будущее: улучшить качество оценки (другие алгоритмы прогноза; нейронная сеть лучше отследит закономерности), убрать недостоверную оценку (отрицательную сложность), снизить влияние аномалий и шумов на оценку, дать возможность повысить приоритет точек на экстремумах.\n\n**Примеры – оценка и прогноз времени отклика экшена в зависимости от объема данных**\n\nПример импорта позиций спецификации из XLSX. Значение prediction\\_multipler задает, насколько далеко мы желаем увеличить объемы данных для прогноза, обычно ×1 хватает для просмотра кривой сложности.\n\n![Дашборд прогнозирования сложности времени на примере экшена типа import](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/123\/4ba\/c21\/1234bac21dcad3e3d49895b6395584ac.png)\n\n*Дашборд прогнозирования сложности времени на примере экшена типа import*\n\nПопробуем оценить результат:\n\n● Время импорта нелинейно зависит от количества SQL-запросов. Степенная сложность O(n^3) может говорить о том, что используется алгоритм вида for-for-for с тяжелой операцией во внутреннем цикле, стоит пересмотреть алгоритм импорта.\n\n● Время импорта линейно зависит от длительности SQL-запросов, здесь мало пользы.\n\nПример экспорта списка позиций реестра платежей в XLSX\n\n![Дашборд прогнозирования сложности времени на примере экшена типа export](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/630\/e24\/700\/630e2470063551097daa6cdfc1362a91.png)\n\n*Дашборд прогнозирования сложности времени на примере экшена типа export*\n\n● Время экспорта не зависит от количества SQL-запросов (количество запросов не меняется, а время растет) – оценка сложности невозможна.\n\n● Время экспорта почти линейно зависит от длительности SQL-запросов. Сейчас проблемы нет, однако можем спрогнозировать, при каком росте объема данных наступит лимит по времени выполнения для пользователя.\n\n**Оценка и прогноз времени CPU в зависимости от объема данных**\n\nВ предыдущем прогнозе время отклика содержит в себе и собственно время обработки SQL-запросов (а по нему мы и пытаемся оценить зависимость). Как тогда найти сложные вычислительные алгоритмы и операции самого кода без учета запросов к БД? При оценке сложности берем общее время отклика и минус время из метрик типа Duration. Останется т. н. время CPU, не учтенное ни в каких других метриках Duration. Повышенный slope времени CPU, скорее всего, и будет означать медленный код: недостаточно эффективные алгоритмы; медленные библиотеки.\n\nРассмотрим на примере экспорта списка компаний заявки. Оценка времени отклика показала O(n^0.36) и O(n^0.41). Однако если оценивать время без БД и внешних запросов:\n\n![Дашборд прогнозирования сложности времени CPU на примере экшена типа export](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/c21\/690\/6f4\/c216906f44a49923c1f7529cbb4982e8.png)\n\n*Дашборд прогнозирования сложности времени CPU на примере экшена типа export*\n\nВремя CPU более чем линейно зависит от количества SQL-запросов. Это говорит о неэффективном использовании алгоритмов (действительно, используется медленная библиотека для генерации файла экспорта – phpspreadsheet). После перехода на собственную разработку, которая распаковывает xlsx и работает с xml, как со строками, получилось снизить сложность.\n\n![Тот же экшен после внедрения оптимизации](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/b36\/97c\/8f0\/b3697c8f022af9818c6ffc1936143cb0.png)\n\n*Тот же экшен после внедрения оптимизации*\n\n**Оценка и прогноз использования RAM в зависимости от объема данных**\n\nПример экспорта списка позиций в XLSX\n\n![Дашборд прогнозирования сложности потребления RAM на примере экшена типа export](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/27c\/960\/925\/27c960925d29efec3b64cef20881ff0f.png)\n\n*Дашборд прогнозирования сложности потребления RAM на примере экшена типа export*\n\nМаксимальный объем задействованной оперативной памяти более чем линейно зависит от длительности SQL-запросов. Это говорит о неэффективном использовании RAM (действительно, используется библиотека phpspreadsheet, которая в базовой реализации требует многократного объема оперативной памяти).\n\n**Дашбор ТОПов экшенов по оценке сложности**\n\n![ТОПы по оценке сложности среди экшенов контроллера request](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/a53\/ccf\/a66\/a53ccfa66b51d24fb2e07183c11aa83c.png)\n\n*ТОПы по оценке сложности среди экшенов контроллера request*\n\nАналогично разделу ТОПов дашборд составлен для быстрого поиска экшенов с высокой оценкой сложности по перечисленным критериям. Это позволит обнаружить экшены, которые в перспективе могут стать тяжелыми при увеличении объемов данных. Как и намекает JSON Statham с картинки, не стоит верить статистике: необязательно высокая оценка сложности приведет к медленному экшену в перспективе. Каждый экшен лучше дополнительно анализировать и изучать текущую статистику: может ли существенно увеличиться объем данных; как часто экшен вызывается; насколько важно заниматься оптимизацией. Оценка также может быть рассчитана неточно: повлияют аномалии, шумы или недостаток данных. С опытом и анализом по другим дашбордам придет понимание, на какие экшены действительно стоит обратить внимание при закладывании оптимизации.\n\n## Автоматические оповещения\nАналитики с других дашбордов уже хватает на месяцы работ по оптимизации. В перспективе понадобятся автоматические рассылки при резком снижении производительности экшена. Возможности Grafana alerts позволяют гибко настроить правила рассылок, а составление запросов с помощью SQL развязывает руки в плане вариантов событий.\n\n![Интерфейс Grafana для настройки автоматических уведомлений](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/952\/651\/ccd\/952651ccd6f68b2c1b6fdcd91b958396.png)\n\n*Интерфейс Grafana для настройки автоматических уведомлений*\n\n![Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/8fd\/065\/c2d\/8fd065c2df6e07aaf81c2b62bf11f3cd.png)\n\n*Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд*\n\nТут и пригодилась таблица с настройками по целевым показателям SLI: например, можно создать алерт со списком экшенов, которые нарушили SLO за выбранный период.\n```\n\n```\n![Пример результата по алерту нарушения SLO](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/175\/962\/8b6\/1759628b60c9af4fd2c25b1e738caf17.png)\n\n*Пример результата по алерту нарушения SLO*\n\nМожно строить любые запросы и выдавать в уведомлении всё, что выдаст этот запрос. Можно запросом получать некоторую метрику и в автоматическом режиме задать правила и значения, при которых оповещение будет рассылаться. Поддерживаются самые разнообразные экспортеры: почта, смс, телеграм и другие мессенджеры.\n\nПримеры условий для алертов по экшенам:\n\n● Тяжелый запрос БД – % БД по времени дольше остальных %.\n\n● Запросы к БД – больше 5 000 запросов в одном вызове экшена.\n\n● Много итераций в интеграции – интеграция в цикле.\n\n● Неоптимизированный код – долгое время вычисления CPU.\n\n● Большое потребление памяти – медиана по потреблению за полчаса от 100 МБ.\n\n● Триггеры на изменения – метрика по экшену выросла более 50% относительно обычного в данный период.\n\n● **На вырост** – прогнать **нейронную сеть** через **базу кейсов**: когда потребовалась критичная оптимизация, получим рекомендации SQL-запросов по неочевидным взаимосвязям метрик.\n\n## Дальнейшее развитие инструмента\nПо мере накопления опыта и подключения других проектов появляется всё больше идей для развития и усовершенствования инструмента:\n\n● Больше метрик (FS, cache, Request\/Response size, AMQP, TOP SQL, near\/far external requests …)\n\n● Автоматическая конфигурация метрик (заведение любых метрик типов IDENT\/Single\/Count\/Duration) с автоинициализацией БД и дашбордов\n\n● Автоматический сбор метрик в популярных фреймворках\n\n● Оптимизация времени отправки (например, с демоном и posix shared memory\/UDP\/TCP)\n\n● Адаптация под другие языки, поддержка микросервисов\n\n● Больше дашбордов (P95\/P99…), возможность сократить дашборды для уменьшения дублирования информации, улучшение алгоритмов прогноза (нейронка)\n\n● Автоматические отчеты на почту\n\n● Расширение списка триггеров для Grafana alerts (+нейронка)\n\n● Мониторинг статистики для отслеживания тенденций использования сервиса (тренды развития проекта для аналитиков)\n\n● Связать с мониторингом железа (USE+)\n\n● Добавить показатели по фронтенду\n\n● Подключить отказы и прерывания – тем самым добавим метрики недоступности по экшенам\n\n● Генерация аналитических запросов с помощью LLM, которая находится в контексте проекта\n\n● Опциональное включение профайлинга а-ля pinba для конкретных экшенов (must have для поиска конкретных мест в коде при оптимизации)\n\nПутей для развития много, но кажется лишним двигаться в сторону Sentry и агрегировать вообще всё отовсюду и всегда. Вместо разработки универсального инструмента хочется сконцентрироваться на конкретной проблеме контроля производительности, помочь разработчикам быстро и плавно обнаружить и разобраться с проблемами на продакшене. Добавить уверенности в стабильной и качественной работе сервиса.\n\n## Плюсы и минусы используемого подхода\nПреимущества используемых инструментов – большая гибкость как по метрикам, так и по методу отправки и отображаемому анализу, почти нет влияния на время отклика (чуть задерживаем fpm), малый объем для хранения, легко разрабатывать новые дашборды. SQL в качестве анализа – очень удобный язык. Текущие дашборды позволяют со всех сторон взглянуть на бэкенд и прозрачно видеть все аспекты производительности.\n\nТеперь по недостаткам по сравнению с аналогичными решениями:\n\n● Ручное подключение статических вызовов в pipeline экшена. Вручную придется заводить БД и выполнять инициализирующие запросы. Хоть и настройка дашбордов решается импортом JSON файла в графану. Проблема ручного подключения решается разработкой версий библиотеки по сбору метрик для конкретных фреймворков.\n\n● Аналоги в виде Uptrace и Sentry подключить быстрее, и они возможно дают более глубокую аналитику (например, указывают место в коде, но для этого приходится эту информацию хранить и занимать трафик\/место). Мы делаем чуть по-другому: концентрация на мониторинге небольшого набора метрик, агрегация показателей на разных аспектах производительности вкупе с аналитикой с точки зрения вызовов конкретных экшенов с помощью SQL.\n\n● Пока среди языков поддерживается только PHP. При этом сама библиотека для сбора и отправки укладывается в 200 строк кода. При необходимости можно взять пример и написать реализацию для своего языка с подходящим методом сбора и отправки.\n\n● Микросервисы – сложнее отследить, но можно добавить единую метрику trace\\_id. С группировкой по trace\\_id отслеживать целиком процесс затрагивающий несколько микросервисов.\n\n● В текущей схеме сложно увидеть недоступность сервиса для показателей SLI по доступности (отказы регистрируются на уровне железа), тут можем поставить дополнительный сканер и отвалившиеся запросы логировать на входе балансера\/nginx и записывать в ту же БД кликхауза.\n\n● Prometheus больше оптимизирован под хранение и выборку одиночных метрик в виде временных рядов, данные могут занимать меньше места, но дольше вставка, и, если не заложились на определенную структуру, возможно, будет дольше выборка данных особенно на сложных агрегациях по нескольким метрикам сразу. Вместо SQL используется свой язык PromQL, может чуть неудобен для сложных аналитических запросов и нужно отдельно знакомиться с синтаксисом.\n\n## Итоги\n![ Гусь наконец отстал от нас и занялся музыкой =)](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/e43\/898\/34a\/e4389834a3b013fc658ceb73b40fd146.png)\n\nГусь наконец отстал от нас и занялся музыкой =)\n\n● В больших проектах важно отслеживать производительность с прицелом на конкретные экшены – мониторинг и анализ.\n\n● Можно не ограничиваться стандартами RED\/USE, SLI\/Apdex – добавлять метрики и аналитику, полезные именно вашему проекту.\n\n● Не просто живые графики, но и статистика вроде таблиц ТОПов, желательно с автоматическими оповещениями + прогнозы.\n\n● Своевременная оптимизация снизит тревогу пользователей и улучшит отзывы о работе системы.\n\nИнструмент назвали **VESNA.Insight** – система детального мониторинга и анализа производительности сервисов с прицелом на конкретные действия пользователей. Позволяет с легкостью мониторить аспекты производительности более тысячи экшенов: время выполнения, нагрузка на БД, CPU, ожидание HTTP-запросов, RAM, ошибки. Реализована возможность группировки действий по типам, задание критичных точек по различным аспектам и мониторинг всей группы с отслеживанием выполнения целевых показателей. Довольно быстро добавляются новые метрики, расширяются панели мониторинга и аналитики.\n\nБлагодаря дашборду ТОПов создаем несколько задач оптимизации для разработчиков еженедельно, сокращает время на поиск узких мест. Каждой задаче помимо описания действия дашборды сообщают ценную информацию о критичности правки, какие аспекты требуют оптимизации, оценку сложности алгоритмов и предсказание производительности, получить рекомендации по оптимизации из предыдущих кейсов работы с подобными задачами.\n\nClickHouse отрабатывает очень шустро, индекса по времени хватает на то, что все перечисленные дашборды загружаются менее чем за 1 секунду. Агрегации моментальные: при отрисовке глобальной статистики – даже без фильтра по времени – десятки миллионов строк логов обрабатываются за пару секунд.\n\nБлагодаря Grafana с плагином кликхауз можем отправлять автоматические уведомления при превышении настроенных целевых показателей по всем отслеживаемым аспектам производительности сервиса. Оценка и прогнозирование производительности дают возможность получать уведомления вида «Импорт данных превысит лимит времени\/RAM при росте объема на 200%» и заложить ресурсы на оптимизацию заранее.\n\nИнструмент в первую очередь разрабатывался для внутренних нужд и уже преобразовал просто ручные точечные применения улучшений на управление целым комбайном производительности сервиса. Для коллег из интеграционных систем это гарантия бесперебойности работы с самыми важными контрактами. Для компании и менеджмента – снижение рисков, улучшение показателей работы команды и впечатлений по работе с сервисами. Для разработчиков, QA и аналитиков по проекту – уменьшение неудобств при попытках исследовать проблему с продакшена, меньше отвлечений на оперативные правки, больше уверенность при доработке тяжелых экшенов. Ну и наконец, для пользователей – отсутствие подтормаживающих экшенов и увеличение комфорта позволяет спокойно работать в системе.\n\nЯ же с удовольствием провел время, разбираясь в тонкостях мониторинга, аспектах производительности и, аки детектив, выслеживал проблемные места в крупном легаси-проекте с помощью построения нужных дашбордов. После долгих лет ручного разбора логов наконец появилась возможность видеть, как методы оживают в продакшене и весь бэкенд становится видно насквозь. Чувствуется осуществление моей мечты, как бэкенд-разработчика, болеющего за свой проект. Несколько раз в месяц во время работы над задачами возникают идеи всё новых метрик и дашбордов и что с их помощью можно обнаружить – такой инструмент позволяет быстро и просто за считанные дни накидывать в графану всё необходимое. Весьма интересно, куда эта дорожка приведет в дальнейшем, какие нюансы производительности получится вскрыть и какие рубежи преодолеть.\n\n## Послесловие\nОгромное спасибо всем, кто дочитал до конца и выжил! В комментариях предлагаю обсудить не только предложенный инструмент, но и ваш опыт внедрения или использования подобного мониторинга. Особенно если работали с Sentry\/Uptrace\/.. или, может, даже разработали свой аналог, прошу рассказать о впечатлениях использования этих инструментов и какой аспект больше всего пригодился. Разумеется, задавайте вопросы и пишите рекомендации по улучшению. Спасибо за поддержку и ценный фидбэк! Ещё хочется послушать, как бы пригодился подобный инструмент в вашем языке (или, может, ваш язык уже имеет мощный встроенный инструмент мониторинга и анализа производительности экшенов и подключать что-то ещё не требуется?), какие метрики 100% нужно добавить, а какие будут бесполезны.\n\nА так – хочется пожелать всем быстрых сервисов и безотказных экшенов, при всем этом – спокойной разработки и размеренной оптимизации. До встречи\\!\n\nТеги:\n\n- [мониторинг производительности](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[%D0%BC%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3+%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8])\n- [backend](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[backend])\n- [метрики red](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8+red])\n- [оптимизация api](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F+api])\n- [sre](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[sre])\n- [php](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[php])\n- [pinba](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[pinba])\n- [clickhouse-grafana](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[clickhouse-grafana])\n- [vesna.insight](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[vesna.insight])\n- [оценка сложности алгоритмов](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[%D0%BE%D1%86%D0%B5%D0%BD%D0%BA%D0%B0+%D1%81%D0%BB%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D0%B8+%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%BE%D0%B2])\n\nХабы:\n\n- [Блог компании ЭТП ГПБ \/ VESNA](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/)\n- [Анализ и проектирование систем](https:\/\/habr.com\/ru\/hubs\/analysis_design\/)\n- [PHP](https:\/\/habr.com\/ru\/hubs\/php\/)\n- [DevOps](https:\/\/habr.com\/ru\/hubs\/devops\/)\n- [Веб-разработка](https:\/\/habr.com\/ru\/hubs\/webdev\/)\n\n\\+8\n\n33\n\n[0](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/946000\/comments\/)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/company\/f4f\/29f\/9d3\/f4f29f9d312a85b3b1abe9bcfcad1ab8.png)](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/profile\/)\n\n[ЭТП ГПБ \/ VESNA](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/profile\/)\n\n[Сайт](https:\/\/vesna-group.ru\/)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/avatars\/7c1\/033\/627\/7c10336274775082efe7d847711b0f26.jpeg)](https:\/\/habr.com\/ru\/users\/chronoexp\/)\n\n5\n\nКарма\n\nАртем Седых[@chronoexp](https:\/\/habr.com\/ru\/users\/chronoexp\/)\n\nВедущий разработчик, тимлид\n\nПодписаться\n\nПоток Бэкенд доступен 24\/7 благодаря поддержке друзей Хабра\n\n![Хабр Карьера Курсы](https:\/\/habrastorage.org\/webt\/qq\/ey\/pn\/qqeypn-py71suynxbusbakjdfjw.png)\n\nХабр Курсы для бэкендеров\n\nРЕКЛАМА\n\nПрактикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать\\!\n\n[Перейти](https:\/\/career.habr.com\/courses\/programmirovanie\/backend-razrabotka\/?erid=2VSb5zFkQ3T&utm_source=habr&utm_medium=sponsorship_hub)\n\n[Перейти в поток Бэкенд](https:\/\/habr.com\/ru\/flows\/backend\/)\n\n[Комментировать](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/946000\/comments\/)\n\n## Публикации\nЛучшие за сутки\n\nПохожие\n\n## Информация\nСайт\n\n[vesna-group.ru](https:\/\/vesna-group.ru\/)\n\nДата регистрации\n\n21 ноября 2024\n\nДата основания\n\n26 апреля 2023\n\nЧисленность\n\n501–1 000 человек\n\nМестоположение\n\nРоссия\n\nВаш аккаунт\n\n- [Войти](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr\/?back=\/ru\/companies\/etpgpb_vesna\/articles\/946000\/&hl=ru)\n- [Регистрация](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr-register\/?back=\/ru\/companies\/etpgpb_vesna\/articles\/946000\/&hl=ru)\n\nРазделы\n\n- [Статьи](https:\/\/habr.com\/ru\/articles\/)\n- [Новости](https:\/\/habr.com\/ru\/news\/)\n- [Хабы](https:\/\/habr.com\/ru\/hubs\/)\n- [Компании](https:\/\/habr.com\/ru\/companies\/)\n- [Авторы](https:\/\/habr.com\/ru\/users\/)\n- [Песочница](https:\/\/habr.com\/ru\/sandbox\/)\n\nИнформация\n\n- [Устройство сайта](https:\/\/habr.com\/ru\/docs\/help\/)\n- [Для авторов](https:\/\/habr.com\/ru\/docs\/authors\/codex\/)\n- [Для компаний](https:\/\/habr.com\/ru\/docs\/companies\/corpblogs\/)\n- [Документы](https:\/\/habr.com\/ru\/docs\/docs\/transparency\/)\n- [Соглашение](https:\/\/account.habr.com\/info\/agreement\/?hl=ru_RU)\n- [Конфиденциальность](https:\/\/account.habr.com\/info\/confidential\/?hl=ru_RU)\n\nУслуги\n\n- [Корпоративный блог](https:\/\/company.habr.com\/ru\/corporate-blogs\/)\n- [Медийная реклама](https:\/\/company.habr.com\/ru\/advertising\/)\n- [Нативные проекты](https:\/\/company.habr.com\/ru\/native-special\/)\n- [Образовательные программы](https:\/\/company.habr.com\/ru\/education-programs\/)\n- [Стартапам](https:\/\/company.habr.com\/ru\/hello-startup\/)\n\nНастройка языка\n\n[Техническая поддержка](https:\/\/habr.com\/ru\/feedback\/)\n\n© 2006–2026, [Habr](https:\/\/company.habr.com\/)","attrs_readable_markdown":"> [Ссылка на часть 1](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/939742)\n\n> [Ссылка на часть 2](https:\/\/habr.com\/ru\/companies\/etpgpb_vesna\/articles\/944148)\n\nВсем привет! Я Артём Седых, работаю ведущим разработчиком команды банковского сопровождения. Проекту уже девятый год, накопилась большая функциональная база и много легаси-кода с набором узких мест для возможной оптимизации. В данном наборе статей рассказываю про наш опыт разработки и внедрения собственной системы мониторинга бэкенда PHP с возможностью просмотреть, как именно проседают экшены, и даже спрогнозировать их поведение. Если не читали предыдущие части, ссылки выше. Сегодня, в третьей и заключительной части, рассмотрим мониторинг со стороны devops на дашбордах SLI\/Apdex, поколдуем над статистическими методами для прогноза снижения производительности (рубрика «эксперименты»), поговорим об автоматических уведомлениях Grafana. Оценим перспективы развития, сравнительный анализ выбранного подхода и выводы по нашему опыту. Заваривайте любимый напиток, приятного прочтения\\!\n\n### Расследование проблемных параметров\nВ прошлой части было много дашбордов для изучения и оценки больше количественных показателей по проекту и экшенам с самой разнообразной агрегацией. Теперь попробуем получить информацию из метрики параметров. Дашборд покажет, какие именно параметры загружают систему дольше всего вместе с их количеством и количеством ошибок. Выполняется группировка по parameters.\n\n`Отследить, какие именно параметры имеют больше влияния на время работы системы`\n\nДля лучшей четкости картинки можно открыть в новой вкладке.\n\n![Дашборд расследования параметров](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/629\/d2f\/86a\/629d2f86a7ef45cadc3a7ad7d72334ee.png)\n\n*Дашборд расследования параметров*\n\nТут уже вступает анализ конкретных данных, стоит обратить внимание: а всё ли нормально с этими параметрами, корректно ли обрабатываются и почему обработка так долго занимает. Добавлен фильтр по пользователю: если есть тяжелый пользователь с дашборда ТОПов, здесь увидим, какие параметры он запрашивает. На второй таблице можно точечно отследить конкретные запросы конкретного юзера с конкретными параметрами и получить по ним статистику. Часто помогает и наоборот: если на других дашбордах видно аномалию, этот дашборд покажет, при каком наборе параметров она возникает.\n\n### Дашборд SLI и Apdex\nСо стороны бизнеса и devops первое, на что стоит обратить внимание, – конкретные показатели производительности по стандартам SRE (Site Reliability Engineering) вроде [SLI](https:\/\/habr.com\/ru\/articles\/718796\/) и [Apdex](https:\/\/habr.com\/ru\/companies\/sravni\/articles\/802705\/) по четко выставленным критериям. Это вполне реализуемо на текущих инструментах в разрезе каждого тега и экшена. До сих пор в ClickHouse использовали только одну таблицу – таблицу логов. Для удобства аналитики укажем целевые показатели SLI и Apdex по времени отклика прямо в CH в виде отдельной таблицы – это позволит приджойниться и динамически отследить соответствие метрик поставленным целям. Мы выбрали разное время для разных тегов исходя из природы операции. Например, время на загрузку списка сущностей в таблицу фронтенда должно быть довольно мало, т. к. это наиболее востребованное действие в системе. При этом на тяжелую операцию импорта или интеграции можно заложить побольше, особенно если пользователь не участвует в операции и не ждет немедленной реакции.\n\nПеречень колонок таблицы с целевыми показателями по времени SLI и Apdex:\n\n`log_target(action_tag, slo_percent, sli_time, apdex_time)`\n\nПри вычислении по формулам целевое время выбирается из этой таблицы по конкретному тегу в логе операций.\n\n`Отследить показатели производительности сервиса по стандартам Google Site Reliability Engineering`\n\nПример SLI\n\n![Формула расчета показателя](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/f51\/94c\/ed6\/f5194ced6f26253d498ee0f5f9cdf429.png)\n\nФормула расчета показателя\n\n![Дашборд отслеживания SLI](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/65e\/62e\/a88\/65e62ea88317d5e05278327c48a441e6.png)\n\n*Дашборд отслеживания SLI*\n\nВидно как глобальный индекс, так и с разбивкой по тегам и экшенам. В таблице видно тяжелые экшены по показателю SLI с сортировкой по низкому %. В первую очередь стоит заняться оптимизацией красной зоны. Дополнительно планируем вычислять характеристику импакта в целом по системе: к примеру, экшен А вызвали всего 2 раза за день, он нарушил сроки и находится в красной зоне, а экшен Б вызвали 10 000 раз, но он обитает в желтой зоне – всё же оптимизировать Б до зеленого важнее, чем помочь единичным вызовам экшена А. Эта характеристика даст больше информации и понимания при выборе приоритетов для оптимизации.\n\nПример Apdex\n\n![Формула расчета показателя](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/250\/b49\/652\/250b49652f50da314285e78050165eb5.png)\n\nФормула расчета показателя\n\n![Дашборд отслеживания Apdex](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/7d4\/b02\/6ac\/7d4b026acb886dd79172f1992f19b130.png)\n\n*Дашборд отслеживания Apdex*\n\nApdex покажет комфорт пользователей при работе в системе относительно отдельных тегов и экшенов. Целевое время зададим ниже отметки для SLI как рекомендованное время для удобства пользователя. Покажет, где пользователи ждут больше обычного в наглядных областях «хороший», «медленный» и «плохой». Разобравшись с проблемами по SLI, можно будет приняться за улучшение показателя Apdex.\n\n### Дашборд Business Apdex\nОтследить показатели производительности сервиса метрикой Apdex с группировкой по бизнес-понятиям. Вместо специфичных для разработки понятий (тег, экшен, контроллер) отобразить информацию в виде удобных и понятных панелей-карточек. Каждая панель отображает одну из частей системы с человеческим названием и может в себе группировать один или несколько экшенов.\n\nДля возможности группировки и мониторинга по бизнес-понятиям заведем таблицу в ClickHouse с колонками:\n\n`log_business_target(action_tag, controller, action, business_target, apdex_time, priority)`\n\nКонфигурация поможет гибко настроить маппинг tag-controller-action =\\> понятие + целевое время для Apdex. Выполняется группировка по понятиям и сортировка по приоритету. Список понятий формируется эмпирически, что именно необходимо отслеживать по системе. В одну карточку могут попасть как один конкретный экшен, так и целая группа, покрывающая часть логики сервиса. В Grafana используется элемент Canvas с настройкой Repeat by variable (business\\_target).\n\nПример дашборда на тестовом наборе данных, где части системы были под нагрузкой (чтобы показать разные цвета):\n\n![Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/ff6\/1b2\/559\/ff61b255953cc901cf18db31a79d2393.png)\n\n*Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex*\n\n● Отображает для каждого бизнес-понятия панель с состоянием Apdex за указанный период Grafana человеческими словами.\n\n● Отображает динамику по сравнению с предыдущим периодом (+-0.xx).\n\n● Отображает справочную информацию о целевом времени и о количестве запросов.\n\n● Позволяет отфильтровать только нужные бизнес-понятия либо вывести все сразу.\n\nКаждая карточка нацелена на свое время Apdex, и помимо самого индекса отображает дополнительную информацию. Дашборд использовать как средство мониторинга состояния системы для менеджеров, бизнес-аналитиков, заказчиков и других заинтересованных лиц.\n\n### Дашборд оценки и прогнозирования производительности экшенов\nОднажды при наблюдении за статистикой по экшенам появилась мысль: *«если у нас такой богатый объем данных, есть статистика производительности экшена и есть числовые показатели, на каких масштабах данных выполнялся экшен, почему бы не зайти дальше и не попытаться оценить, как себя поведет экшен в будущем при росте этих показателей?».* Сказано – сделано: кастомный инструмент очередной раз показал, насколько быстро и гибко получается накидывать дашборды, ограничиваясь лишь фантазией и здравым смыслом.\n\n`Используя статистические методы, оценить зависимость используемых ресурсов от объема данных и спрогнозировать поведение экшена.`\n\nОценка и прогнозы основаны на базовых методах математической статистики и подвержены ухудшению при аномалиях или недостаточном количестве данных. В основе стоит гипотеза о том, что потребление экшеном ресурса (время и RAM) зависит от объема данных, который представлен количеством SQL-запросов либо длительностью их выполнения. Если же экшен по природе не меняет количество или общую длительность SQL-запросов, корреляцию этим дашбордом обнаружить не получится.\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/dd0\/136\/ec0\/dd0136ec0c02d5b6a3564691a8bf1b9e.png)\n\nТекущий алгоритм, по которому выполняется оценка сложности O(n^x): анализ сложности на основе регрессии логарифмов или log-log regression analysis \/ plot в английской терминологии ([ссылка 1](https:\/\/en.wikipedia.org\/wiki\/Log%E2%80%93log_plot), [ссылка 2](https:\/\/www.vexpower.com\/brief\/log-log-model), больше про сложность и линейную регрессию при оценке алгоритмов – [ссылка 3](https:\/\/ppml.dev\/algorithms.html)). Стоит отметить, это ни в коем случае не аналитическая сложность алгоритма (экшена), а сложность в бытовом понимании – оценить, насколько увеличивается время работы от объема данных, и попытаться предсказать, сколько времени займет при увеличении этого объема.\n\nКлючевые моменты (под спойлером)\n\n1. Два предположительно взаимосвязанных массива данных в отношении a =\\> b.\n2. Используется натуральный логарифм. Логарифм превращает сложную степенную зависимость в линейную, чтобы легко найти показатель сложности slope через линейную регрессию.\n3. Расчет ковариации и дисперсии. Ковариация – это статистическая мера того, насколько две переменные изменяются вместе. В нашем случае это мера того, как ln(total\\_sql\\_queries) и ln(duration\\_s) изменяются относительно друг друга. Дисперсия – это мера разброса значений переменной. Здесь мы используем дисперсию ln(total\\_sql\\_queries).\n4. Расчет наклона (slope). Наклон линии регрессии в log-log пространстве рассчитывается как отношение ковариации к дисперсии. Этот наклон и есть показатель сложности алгоритма.\n5. Интерпретация наклона. Если наклон близок к 1, это указывает на линейную сложность O(N). Наклон между 1 и 2 может указывать на сложность O(N\\*log(N)). Наклон около 2 указывает на квадратичную сложность O(N^2). Другие значения наклона интерпретируются как O(N^slope).\n6. Экстраполяция. Используя полученный наклон (slope), мы можем предсказать время выполнения для больших объемов данных.\n\nДашборд в альфа-версии. Список улучшений на будущее: улучшить качество оценки (другие алгоритмы прогноза; нейронная сеть лучше отследит закономерности), убрать недостоверную оценку (отрицательную сложность), снизить влияние аномалий и шумов на оценку, дать возможность повысить приоритет точек на экстремумах.\n\n**Примеры – оценка и прогноз времени отклика экшена в зависимости от объема данных**\n\nПример импорта позиций спецификации из XLSX. Значение prediction\\_multipler задает, насколько далеко мы желаем увеличить объемы данных для прогноза, обычно ×1 хватает для просмотра кривой сложности.\n\n![Дашборд прогнозирования сложности времени на примере экшена типа import](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/123\/4ba\/c21\/1234bac21dcad3e3d49895b6395584ac.png)\n\n*Дашборд прогнозирования сложности времени на примере экшена типа import*\n\nПопробуем оценить результат:\n\n● Время импорта нелинейно зависит от количества SQL-запросов. Степенная сложность O(n^3) может говорить о том, что используется алгоритм вида for-for-for с тяжелой операцией во внутреннем цикле, стоит пересмотреть алгоритм импорта.\n\n● Время импорта линейно зависит от длительности SQL-запросов, здесь мало пользы.\n\nПример экспорта списка позиций реестра платежей в XLSX\n\n![Дашборд прогнозирования сложности времени на примере экшена типа export](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/630\/e24\/700\/630e2470063551097daa6cdfc1362a91.png)\n\n*Дашборд прогнозирования сложности времени на примере экшена типа export*\n\n● Время экспорта не зависит от количества SQL-запросов (количество запросов не меняется, а время растет) – оценка сложности невозможна.\n\n● Время экспорта почти линейно зависит от длительности SQL-запросов. Сейчас проблемы нет, однако можем спрогнозировать, при каком росте объема данных наступит лимит по времени выполнения для пользователя.\n\n**Оценка и прогноз времени CPU в зависимости от объема данных**\n\nВ предыдущем прогнозе время отклика содержит в себе и собственно время обработки SQL-запросов (а по нему мы и пытаемся оценить зависимость). Как тогда найти сложные вычислительные алгоритмы и операции самого кода без учета запросов к БД? При оценке сложности берем общее время отклика и минус время из метрик типа Duration. Останется т. н. время CPU, не учтенное ни в каких других метриках Duration. Повышенный slope времени CPU, скорее всего, и будет означать медленный код: недостаточно эффективные алгоритмы; медленные библиотеки.\n\nРассмотрим на примере экспорта списка компаний заявки. Оценка времени отклика показала O(n^0.36) и O(n^0.41). Однако если оценивать время без БД и внешних запросов:\n\n![Дашборд прогнозирования сложности времени CPU на примере экшена типа export](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/c21\/690\/6f4\/c216906f44a49923c1f7529cbb4982e8.png)\n\n*Дашборд прогнозирования сложности времени CPU на примере экшена типа export*\n\nВремя CPU более чем линейно зависит от количества SQL-запросов. Это говорит о неэффективном использовании алгоритмов (действительно, используется медленная библиотека для генерации файла экспорта – phpspreadsheet). После перехода на собственную разработку, которая распаковывает xlsx и работает с xml, как со строками, получилось снизить сложность.\n\n![Тот же экшен после внедрения оптимизации](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/b36\/97c\/8f0\/b3697c8f022af9818c6ffc1936143cb0.png)\n\n*Тот же экшен после внедрения оптимизации*\n\n**Оценка и прогноз использования RAM в зависимости от объема данных**\n\nПример экспорта списка позиций в XLSX\n\n![Дашборд прогнозирования сложности потребления RAM на примере экшена типа export](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/27c\/960\/925\/27c960925d29efec3b64cef20881ff0f.png)\n\n*Дашборд прогнозирования сложности потребления RAM на примере экшена типа export*\n\nМаксимальный объем задействованной оперативной памяти более чем линейно зависит от длительности SQL-запросов. Это говорит о неэффективном использовании RAM (действительно, используется библиотека phpspreadsheet, которая в базовой реализации требует многократного объема оперативной памяти).\n\n**Дашбор ТОПов экшенов по оценке сложности**\n\n![ТОПы по оценке сложности среди экшенов контроллера request](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/a53\/ccf\/a66\/a53ccfa66b51d24fb2e07183c11aa83c.png)\n\n*ТОПы по оценке сложности среди экшенов контроллера request*\n\nАналогично разделу ТОПов дашборд составлен для быстрого поиска экшенов с высокой оценкой сложности по перечисленным критериям. Это позволит обнаружить экшены, которые в перспективе могут стать тяжелыми при увеличении объемов данных. Как и намекает JSON Statham с картинки, не стоит верить статистике: необязательно высокая оценка сложности приведет к медленному экшену в перспективе. Каждый экшен лучше дополнительно анализировать и изучать текущую статистику: может ли существенно увеличиться объем данных; как часто экшен вызывается; насколько важно заниматься оптимизацией. Оценка также может быть рассчитана неточно: повлияют аномалии, шумы или недостаток данных. С опытом и анализом по другим дашбордам придет понимание, на какие экшены действительно стоит обратить внимание при закладывании оптимизации.\n\n## Автоматические оповещения\nАналитики с других дашбордов уже хватает на месяцы работ по оптимизации. В перспективе понадобятся автоматические рассылки при резком снижении производительности экшена. Возможности Grafana alerts позволяют гибко настроить правила рассылок, а составление запросов с помощью SQL развязывает руки в плане вариантов событий.\n\n![Интерфейс Grafana для настройки автоматических уведомлений](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/952\/651\/ccd\/952651ccd6f68b2c1b6fdcd91b958396.png)\n\n*Интерфейс Grafana для настройки автоматических уведомлений*\n\n![Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/8fd\/065\/c2d\/8fd065c2df6e07aaf81c2b62bf11f3cd.png)\n\n*Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд*\n\nТут и пригодилась таблица с настройками по целевым показателям SLI: например, можно создать алерт со списком экшенов, которые нарушили SLO за выбранный период.\n```\nSELECT l.controller_name || '.' || l.action_name AS action,\n       lt.slo_percent, ROUND((countIf(l.duration_s <= lt.sli_time) \/ COUNT(*)) * 100, 2) AS sli_current\nFROM logs AS l\nJOIN log_target AS lt ON l.action_group_tag = lt.action_tag\nWHERE $__timeFilter(l.start_datetime) AND l.success\nGROUP BY l.controller_name, l.action_name, lt.slo_percent\nHAVING ROUND((countIf(l.duration_s <= lt.sli_time) \/ COUNT(*)) * 100, 2) < lt.slo_percent;\n```\n![Пример результата по алерту нарушения SLO](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/175\/962\/8b6\/1759628b60c9af4fd2c25b1e738caf17.png)\n\n*Пример результата по алерту нарушения SLO*\n\nМожно строить любые запросы и выдавать в уведомлении всё, что выдаст этот запрос. Можно запросом получать некоторую метрику и в автоматическом режиме задать правила и значения, при которых оповещение будет рассылаться. Поддерживаются самые разнообразные экспортеры: почта, смс, телеграм и другие мессенджеры.\n\nПримеры условий для алертов по экшенам:\n\n● Тяжелый запрос БД – % БД по времени дольше остальных %.\n\n● Запросы к БД – больше 5 000 запросов в одном вызове экшена.\n\n● Много итераций в интеграции – интеграция в цикле.\n\n● Неоптимизированный код – долгое время вычисления CPU.\n\n● Большое потребление памяти – медиана по потреблению за полчаса от 100 МБ.\n\n● Триггеры на изменения – метрика по экшену выросла более 50% относительно обычного в данный период.\n\n● **На вырост** – прогнать **нейронную сеть** через **базу кейсов**: когда потребовалась критичная оптимизация, получим рекомендации SQL-запросов по неочевидным взаимосвязям метрик.\n\n## Дальнейшее развитие инструмента\nПо мере накопления опыта и подключения других проектов появляется всё больше идей для развития и усовершенствования инструмента:\n\n● Больше метрик (FS, cache, Request\/Response size, AMQP, TOP SQL, near\/far external requests …)\n\n● Автоматическая конфигурация метрик (заведение любых метрик типов IDENT\/Single\/Count\/Duration) с автоинициализацией БД и дашбордов\n\n● Автоматический сбор метрик в популярных фреймворках\n\n● Оптимизация времени отправки (например, с демоном и posix shared memory\/UDP\/TCP)\n\n● Адаптация под другие языки, поддержка микросервисов\n\n● Больше дашбордов (P95\/P99…), возможность сократить дашборды для уменьшения дублирования информации, улучшение алгоритмов прогноза (нейронка)\n\n● Автоматические отчеты на почту\n\n● Расширение списка триггеров для Grafana alerts (+нейронка)\n\n● Мониторинг статистики для отслеживания тенденций использования сервиса (тренды развития проекта для аналитиков)\n\n● Связать с мониторингом железа (USE+)\n\n● Добавить показатели по фронтенду\n\n● Подключить отказы и прерывания – тем самым добавим метрики недоступности по экшенам\n\n● Генерация аналитических запросов с помощью LLM, которая находится в контексте проекта\n\n● Опциональное включение профайлинга а-ля pinba для конкретных экшенов (must have для поиска конкретных мест в коде при оптимизации)\n\nПутей для развития много, но кажется лишним двигаться в сторону Sentry и агрегировать вообще всё отовсюду и всегда. Вместо разработки универсального инструмента хочется сконцентрироваться на конкретной проблеме контроля производительности, помочь разработчикам быстро и плавно обнаружить и разобраться с проблемами на продакшене. Добавить уверенности в стабильной и качественной работе сервиса.\n\n## Плюсы и минусы используемого подхода\nПреимущества используемых инструментов – большая гибкость как по метрикам, так и по методу отправки и отображаемому анализу, почти нет влияния на время отклика (чуть задерживаем fpm), малый объем для хранения, легко разрабатывать новые дашборды. SQL в качестве анализа – очень удобный язык. Текущие дашборды позволяют со всех сторон взглянуть на бэкенд и прозрачно видеть все аспекты производительности.\n\nТеперь по недостаткам по сравнению с аналогичными решениями:\n\n● Ручное подключение статических вызовов в pipeline экшена. Вручную придется заводить БД и выполнять инициализирующие запросы. Хоть и настройка дашбордов решается импортом JSON файла в графану. Проблема ручного подключения решается разработкой версий библиотеки по сбору метрик для конкретных фреймворков.\n\n● Аналоги в виде Uptrace и Sentry подключить быстрее, и они возможно дают более глубокую аналитику (например, указывают место в коде, но для этого приходится эту информацию хранить и занимать трафик\/место). Мы делаем чуть по-другому: концентрация на мониторинге небольшого набора метрик, агрегация показателей на разных аспектах производительности вкупе с аналитикой с точки зрения вызовов конкретных экшенов с помощью SQL.\n\n● Пока среди языков поддерживается только PHP. При этом сама библиотека для сбора и отправки укладывается в 200 строк кода. При необходимости можно взять пример и написать реализацию для своего языка с подходящим методом сбора и отправки.\n\n● Микросервисы – сложнее отследить, но можно добавить единую метрику trace\\_id. С группировкой по trace\\_id отслеживать целиком процесс затрагивающий несколько микросервисов.\n\n● В текущей схеме сложно увидеть недоступность сервиса для показателей SLI по доступности (отказы регистрируются на уровне железа), тут можем поставить дополнительный сканер и отвалившиеся запросы логировать на входе балансера\/nginx и записывать в ту же БД кликхауза.\n\n● Prometheus больше оптимизирован под хранение и выборку одиночных метрик в виде временных рядов, данные могут занимать меньше места, но дольше вставка, и, если не заложились на определенную структуру, возможно, будет дольше выборка данных особенно на сложных агрегациях по нескольким метрикам сразу. Вместо SQL используется свой язык PromQL, может чуть неудобен для сложных аналитических запросов и нужно отдельно знакомиться с синтаксисом.\n\n## Итоги\n![ Гусь наконец отстал от нас и занялся музыкой =)](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/e43\/898\/34a\/e4389834a3b013fc658ceb73b40fd146.png)\n\nГусь наконец отстал от нас и занялся музыкой =)\n\n● В больших проектах важно отслеживать производительность с прицелом на конкретные экшены – мониторинг и анализ.\n\n● Можно не ограничиваться стандартами RED\/USE, SLI\/Apdex – добавлять метрики и аналитику, полезные именно вашему проекту.\n\n● Не просто живые графики, но и статистика вроде таблиц ТОПов, желательно с автоматическими оповещениями + прогнозы.\n\n● Своевременная оптимизация снизит тревогу пользователей и улучшит отзывы о работе системы.\n\nИнструмент назвали **VESNA.Insight** – система детального мониторинга и анализа производительности сервисов с прицелом на конкретные действия пользователей. Позволяет с легкостью мониторить аспекты производительности более тысячи экшенов: время выполнения, нагрузка на БД, CPU, ожидание HTTP-запросов, RAM, ошибки. Реализована возможность группировки действий по типам, задание критичных точек по различным аспектам и мониторинг всей группы с отслеживанием выполнения целевых показателей. Довольно быстро добавляются новые метрики, расширяются панели мониторинга и аналитики.\n\nБлагодаря дашборду ТОПов создаем несколько задач оптимизации для разработчиков еженедельно, сокращает время на поиск узких мест. Каждой задаче помимо описания действия дашборды сообщают ценную информацию о критичности правки, какие аспекты требуют оптимизации, оценку сложности алгоритмов и предсказание производительности, получить рекомендации по оптимизации из предыдущих кейсов работы с подобными задачами.\n\nClickHouse отрабатывает очень шустро, индекса по времени хватает на то, что все перечисленные дашборды загружаются менее чем за 1 секунду. Агрегации моментальные: при отрисовке глобальной статистики – даже без фильтра по времени – десятки миллионов строк логов обрабатываются за пару секунд.\n\nБлагодаря Grafana с плагином кликхауз можем отправлять автоматические уведомления при превышении настроенных целевых показателей по всем отслеживаемым аспектам производительности сервиса. Оценка и прогнозирование производительности дают возможность получать уведомления вида «Импорт данных превысит лимит времени\/RAM при росте объема на 200%» и заложить ресурсы на оптимизацию заранее.\n\nИнструмент в первую очередь разрабатывался для внутренних нужд и уже преобразовал просто ручные точечные применения улучшений на управление целым комбайном производительности сервиса. Для коллег из интеграционных систем это гарантия бесперебойности работы с самыми важными контрактами. Для компании и менеджмента – снижение рисков, улучшение показателей работы команды и впечатлений по работе с сервисами. Для разработчиков, QA и аналитиков по проекту – уменьшение неудобств при попытках исследовать проблему с продакшена, меньше отвлечений на оперативные правки, больше уверенность при доработке тяжелых экшенов. Ну и наконец, для пользователей – отсутствие подтормаживающих экшенов и увеличение комфорта позволяет спокойно работать в системе.\n\nЯ же с удовольствием провел время, разбираясь в тонкостях мониторинга, аспектах производительности и, аки детектив, выслеживал проблемные места в крупном легаси-проекте с помощью построения нужных дашбордов. После долгих лет ручного разбора логов наконец появилась возможность видеть, как методы оживают в продакшене и весь бэкенд становится видно насквозь. Чувствуется осуществление моей мечты, как бэкенд-разработчика, болеющего за свой проект. Несколько раз в месяц во время работы над задачами возникают идеи всё новых метрик и дашбордов и что с их помощью можно обнаружить – такой инструмент позволяет быстро и просто за считанные дни накидывать в графану всё необходимое. Весьма интересно, куда эта дорожка приведет в дальнейшем, какие нюансы производительности получится вскрыть и какие рубежи преодолеть.\n\n## Послесловие\nОгромное спасибо всем, кто дочитал до конца и выжил! В комментариях предлагаю обсудить не только предложенный инструмент, но и ваш опыт внедрения или использования подобного мониторинга. Особенно если работали с Sentry\/Uptrace\/.. или, может, даже разработали свой аналог, прошу рассказать о впечатлениях использования этих инструментов и какой аспект больше всего пригодился. Разумеется, задавайте вопросы и пишите рекомендации по улучшению. Спасибо за поддержку и ценный фидбэк! Ещё хочется послушать, как бы пригодился подобный инструмент в вашем языке (или, может, ваш язык уже имеет мощный встроенный инструмент мониторинга и анализа производительности экшенов и подключать что-то ещё не требуется?), какие метрики 100% нужно добавить, а какие будут бесполезны.\n\nА так – хочется пожелать всем быстрых сервисов и безотказных экшенов, при всем этом – спокойной разработки и размеренной оптимизации. До встречи\\!","meta_canonical":null}

3. Robots.txt Check

Query:

Response:

4. Spam/Ban Check

Query:

Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄

INDEXABLE

✅

CRAWLED

19 days ago

🤖

ROBOTS ALLOWED

Page Info Filters

Filter	Status	Condition	Details
HTTP status	PASS	`download_http_code = 200`	HTTP 200
Age cutoff	PASS	`download_stamp > now() - 6 MONTH`	0.6 months ago
History drop	PASS	`isNull(history_drop_reason)`	No drop reason
Spam/ban	PASS	`fh_dont_index != 1 AND ml_spam_score = 0`	ml_spam_score=0
Canonical	PASS	`meta_canonical IS NULL OR = '' OR = src_unparsed`	Not set

Page Details

Property	Value
URL	https://habr.com/ru/companies/etpgpb_vesna/articles/946000/
Last Crawled	2026-03-28 11:09:16 (19 days ago)
First Indexed	2025-09-11 10:35:11 (7 months ago)
HTTP Status Code	200
Meta Title	Мониторинг и анализ производительности бэкенда с помощью ClickHouse и Grafana. Часть 3 / Хабр
Meta Description	Ссылка на часть 1 Ссылка на часть 2 Всем привет! Я Артём Седых, работаю ведущим разработчиком команды банковского сопровождения. Проекту уже девятый год, накопилась большая функциональная база и много...
Meta Canonical	null
Boilerpipe Text	Ссылка на часть 1 Ссылка на часть 2 Всем привет! Я Артём Седых, работаю ведущим разработчиком команды банковского сопровождения. Проекту уже девятый год, накопилась большая функциональная база и много легаси-кода с набором узких мест для возможной оптимизации. В данном наборе статей рассказываю про наш опыт разработки и внедрения собственной системы мониторинга бэкенда PHP с возможностью просмотреть, как именно проседают экшены, и даже спрогнозировать их поведение. Если не читали предыдущие части, ссылки выше. Сегодня, в третьей и заключительной части, рассмотрим мониторинг со стороны devops на дашбордах SLI/Apdex, поколдуем над статистическими методами для прогноза снижения производительности (рубрика «эксперименты»), поговорим об автоматических уведомлениях Grafana. Оценим перспективы развития, сравнительный анализ выбранного подхода и выводы по нашему опыту. Заваривайте любимый напиток, приятного прочтения! Расследование проблемных параметров В прошлой части было много дашбордов для изучения и оценки больше количественных показателей по проекту и экшенам с самой разнообразной агрегацией. Теперь попробуем получить информацию из метрики параметров. Дашборд покажет, какие именно параметры загружают систему дольше всего вместе с их количеством и количеством ошибок. Выполняется группировка по parameters. Отследить, какие именно параметры имеют больше влияния на время работы системы Для лучшей четкости картинки можно открыть в новой вкладке. Дашборд расследования параметров Тут уже вступает анализ конкретных данных, стоит обратить внимание: а всё ли нормально с этими параметрами, корректно ли обрабатываются и почему обработка так долго занимает. Добавлен фильтр по пользователю: если есть тяжелый пользователь с дашборда ТОПов, здесь увидим, какие параметры он запрашивает. На второй таблице можно точечно отследить конкретные запросы конкретного юзера с конкретными параметрами и получить по ним статистику. Часто помогает и наоборот: если на других дашбордах видно аномалию, этот дашборд покажет, при каком наборе параметров она возникает. Дашборд SLI и Apdex Со стороны бизнеса и devops первое, на что стоит обратить внимание, – конкретные показатели производительности по стандартам SRE (Site Reliability Engineering) вроде SLI и Apdex по четко выставленным критериям. Это вполне реализуемо на текущих инструментах в разрезе каждого тега и экшена. До сих пор в ClickHouse использовали только одну таблицу – таблицу логов. Для удобства аналитики укажем целевые показатели SLI и Apdex по времени отклика прямо в CH в виде отдельной таблицы – это позволит приджойниться и динамически отследить соответствие метрик поставленным целям. Мы выбрали разное время для разных тегов исходя из природы операции. Например, время на загрузку списка сущностей в таблицу фронтенда должно быть довольно мало, т. к. это наиболее востребованное действие в системе. При этом на тяжелую операцию импорта или интеграции можно заложить побольше, особенно если пользователь не участвует в операции и не ждет немедленной реакции. Перечень колонок таблицы с целевыми показателями по времени SLI и Apdex: log_target( action_tag , slo_percent, sli_time , apdex_time ) При вычислении по формулам целевое время выбирается из этой таблицы по конкретному тегу в логе операций. Отследить показатели производительности сервиса по стандартам Google Site Reliability Engineering Пример SLI Формула расчета показателя Дашборд отслеживания SLI Видно как глобальный индекс, так и с разбивкой по тегам и экшенам. В таблице видно тяжелые экшены по показателю SLI с сортировкой по низкому %. В первую очередь стоит заняться оптимизацией красной зоны. Дополнительно планируем вычислять характеристику импакта в целом по системе: к примеру, экшен А вызвали всего 2 раза за день, он нарушил сроки и находится в красной зоне, а экшен Б вызвали 10 000 раз, но он обитает в желтой зоне – всё же оптимизировать Б до зеленого важнее, чем помочь единичным вызовам экшена А. Эта характеристика даст больше информации и понимания при выборе приоритетов для оптимизации. Пример Apdex Формула расчета показателя Дашборд отслеживания Apdex Apdex покажет комфорт пользователей при работе в системе относительно отдельных тегов и экшенов. Целевое время зададим ниже отметки для SLI как рекомендованное время для удобства пользователя. Покажет, где пользователи ждут больше обычного в наглядных областях «хороший», «медленный» и «плохой». Разобравшись с проблемами по SLI, можно будет приняться за улучшение показателя Apdex. Дашборд Business Apdex Отследить показатели производительности сервиса метрикой Apdex с группировкой по бизнес-понятиям. Вместо специфичных для разработки понятий (тег, экшен, контроллер) отобразить информацию в виде удобных и понятных панелей-карточек. Каждая панель отображает одну из частей системы с человеческим названием и может в себе группировать один или несколько экшенов. Для возможности группировки и мониторинга по бизнес-понятиям заведем таблицу в ClickHouse с колонками: log_business_target( action_tag, controller, action, business_target, apdex_time , priority ) Конфигурация поможет гибко настроить маппинг tag-controller-action => понятие + целевое время для Apdex. Выполняется группировка по понятиям и сортировка по приоритету. Список понятий формируется эмпирически, что именно необходимо отслеживать по системе. В одну карточку могут попасть как один конкретный экшен, так и целая группа, покрывающая часть логики сервиса. В Grafana используется элемент Canvas с настройкой Repeat by variable (business_target). Пример дашборда на тестовом наборе данных, где части системы были под нагрузкой (чтобы показать разные цвета): Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex ● Отображает для каждого бизнес-понятия панель с состоянием Apdex за указанный период Grafana человеческими словами. ● Отображает динамику по сравнению с предыдущим периодом (+-0.xx). ● Отображает справочную информацию о целевом времени и о количестве запросов. ● Позволяет отфильтровать только нужные бизнес-понятия либо вывести все сразу. Каждая карточка нацелена на свое время Apdex, и помимо самого индекса отображает дополнительную информацию. Дашборд использовать как средство мониторинга состояния системы для менеджеров, бизнес-аналитиков, заказчиков и других заинтересованных лиц. Дашборд оценки и прогнозирования производительности экшенов Однажды при наблюдении за статистикой по экшенам появилась мысль: «если у нас такой богатый объем данных, есть статистика производительности экшена и есть числовые показатели, на каких масштабах данных выполнялся экшен, почему бы не зайти дальше и не попытаться оценить, как себя поведет экшен в будущем при росте этих показателей?». Сказано – сделано: кастомный инструмент очередной раз показал, насколько быстро и гибко получается накидывать дашборды, ограничиваясь лишь фантазией и здравым смыслом. Используя статистические методы, оценить зависимость используемых ресурсов от объема данных и спрогнозировать поведение экшена. Оценка и прогнозы основаны на базовых методах математической статистики и подвержены ухудшению при аномалиях или недостаточном количестве данных. В основе стоит гипотеза о том, что потребление экшеном ресурса (время и RAM) зависит от объема данных, который представлен количеством SQL-запросов либо длительностью их выполнения. Если же экшен по природе не меняет количество или общую длительность SQL-запросов, корреляцию этим дашбордом обнаружить не получится. Текущий алгоритм, по которому выполняется оценка сложности O(n^x): анализ сложности на основе регрессии логарифмов или log-log regression analysis / plot в английской терминологии ( ссылка 1 , ссылка 2 , больше про сложность и линейную регрессию при оценке алгоритмов – ссылка 3 ). Стоит отметить, это ни в коем случае не аналитическая сложность алгоритма (экшена), а сложность в бытовом понимании – оценить, насколько увеличивается время работы от объема данных, и попытаться предсказать, сколько времени займет при увеличении этого объема. Ключевые моменты (под спойлером) Два предположительно взаимосвязанных массива данных в отношении a => b. Используется натуральный логарифм. Логарифм превращает сложную степенную зависимость в линейную, чтобы легко найти показатель сложности slope через линейную регрессию. Расчет ковариации и дисперсии. Ковариация – это статистическая мера того, насколько две переменные изменяются вместе. В нашем случае это мера того, как ln(total_sql_queries) и ln(duration_s) изменяются относительно друг друга. Дисперсия – это мера разброса значений переменной. Здесь мы используем дисперсию ln(total_sql_queries). Расчет наклона (slope). Наклон линии регрессии в log-log пространстве рассчитывается как отношение ковариации к дисперсии. Этот наклон и есть показатель сложности алгоритма. Интерпретация наклона. Если наклон близок к 1, это указывает на линейную сложность O(N). Наклон между 1 и 2 может указывать на сложность O(Nlog(N)). Наклон около 2 указывает на квадратичную сложность O(N^2). Другие значения наклона интерпретируются как O(N^slope). Экстраполяция. Используя полученный наклон (slope), мы можем предсказать время выполнения для больших объемов данных. Дашборд в альфа-версии. Список улучшений на будущее: улучшить качество оценки (другие алгоритмы прогноза; нейронная сеть лучше отследит закономерности), убрать недостоверную оценку (отрицательную сложность), снизить влияние аномалий и шумов на оценку, дать возможность повысить приоритет точек на экстремумах. Примеры – оценка и прогноз времени отклика экшена в зависимости от объема данных Пример импорта позиций спецификации из XLSX. Значение prediction_multipler задает, насколько далеко мы желаем увеличить объемы данных для прогноза, обычно ×1 хватает для просмотра кривой сложности. Дашборд прогнозирования сложности времени на примере экшена типа import Попробуем оценить результат: ● Время импорта нелинейно зависит от количества SQL-запросов. Степенная сложность O(n^3) может говорить о том, что используется алгоритм вида for-for-for с тяжелой операцией во внутреннем цикле, стоит пересмотреть алгоритм импорта. ● Время импорта линейно зависит от длительности SQL-запросов, здесь мало пользы. Пример экспорта списка позиций реестра платежей в XLSX Дашборд прогнозирования сложности времени на примере экшена типа export ● Время экспорта не зависит от количества SQL-запросов (количество запросов не меняется, а время растет) – оценка сложности невозможна. ● Время экспорта почти линейно зависит от длительности SQL-запросов. Сейчас проблемы нет, однако можем спрогнозировать, при каком росте объема данных наступит лимит по времени выполнения для пользователя. Оценка и прогноз времени CPU в зависимости от объема данных В предыдущем прогнозе время отклика содержит в себе и собственно время обработки SQL-запросов (а по нему мы и пытаемся оценить зависимость). Как тогда найти сложные вычислительные алгоритмы и операции самого кода без учета запросов к БД? При оценке сложности берем общее время отклика и минус время из метрик типа Duration. Останется т. н. время CPU, не учтенное ни в каких других метриках Duration. Повышенный slope времени CPU, скорее всего, и будет означать медленный код: недостаточно эффективные алгоритмы; медленные библиотеки. Рассмотрим на примере экспорта списка компаний заявки. Оценка времени отклика показала O(n^0.36) и O(n^0.41). Однако если оценивать время без БД и внешних запросов: Дашборд прогнозирования сложности времени CPU на примере экшена типа export Время CPU более чем линейно зависит от количества SQL-запросов. Это говорит о неэффективном использовании алгоритмов (действительно, используется медленная библиотека для генерации файла экспорта – phpspreadsheet). После перехода на собственную разработку, которая распаковывает xlsx и работает с xml, как со строками, получилось снизить сложность. Тот же экшен после внедрения оптимизации Оценка и прогноз использования RAM в зависимости от объема данных Пример экспорта списка позиций в XLSX Дашборд прогнозирования сложности потребления RAM на примере экшена типа export Максимальный объем задействованной оперативной памяти более чем линейно зависит от длительности SQL-запросов. Это говорит о неэффективном использовании RAM (действительно, используется библиотека phpspreadsheet, которая в базовой реализации требует многократного объема оперативной памяти). Дашбор ТОПов экшенов по оценке сложности ТОПы по оценке сложности среди экшенов контроллера request Аналогично разделу ТОПов дашборд составлен для быстрого поиска экшенов с высокой оценкой сложности по перечисленным критериям. Это позволит обнаружить экшены, которые в перспективе могут стать тяжелыми при увеличении объемов данных. Как и намекает JSON Statham с картинки, не стоит верить статистике: необязательно высокая оценка сложности приведет к медленному экшену в перспективе. Каждый экшен лучше дополнительно анализировать и изучать текущую статистику: может ли существенно увеличиться объем данных; как часто экшен вызывается; насколько важно заниматься оптимизацией. Оценка также может быть рассчитана неточно: повлияют аномалии, шумы или недостаток данных. С опытом и анализом по другим дашбордам придет понимание, на какие экшены действительно стоит обратить внимание при закладывании оптимизации. Автоматические оповещения Аналитики с других дашбордов уже хватает на месяцы работ по оптимизации. В перспективе понадобятся автоматические рассылки при резком снижении производительности экшена. Возможности Grafana alerts позволяют гибко настроить правила рассылок, а составление запросов с помощью SQL развязывает руки в плане вариантов событий. Интерфейс Grafana для настройки автоматических уведомлений Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд Тут и пригодилась таблица с настройками по целевым показателям SLI: например, можно создать алерт со списком экшенов, которые нарушили SLO за выбранный период. SELECT l.controller_name \|\| '.' \|\| l.action_name AS action, lt.slo_percent, ROUND((countIf(l.duration_s <= lt.sli_time) / COUNT()) * 100, 2) AS sli_current FROM logs AS l JOIN log_target AS lt ON l.action_group_tag = lt.action_tag WHERE $__timeFilter(l.start_datetime) AND l.success GROUP BY l.controller_name, l.action_name, lt.slo_percent HAVING ROUND((countIf(l.duration_s <= lt.sli_time) / COUNT()) 100, 2) < lt.slo_percent; Пример результата по алерту нарушения SLO Можно строить любые запросы и выдавать в уведомлении всё, что выдаст этот запрос. Можно запросом получать некоторую метрику и в автоматическом режиме задать правила и значения, при которых оповещение будет рассылаться. Поддерживаются самые разнообразные экспортеры: почта, смс, телеграм и другие мессенджеры. Примеры условий для алертов по экшенам: ● Тяжелый запрос БД – % БД по времени дольше остальных %. ● Запросы к БД – больше 5 000 запросов в одном вызове экшена. ● Много итераций в интеграции – интеграция в цикле. ● Неоптимизированный код – долгое время вычисления CPU. ● Большое потребление памяти – медиана по потреблению за полчаса от 100 МБ. ● Триггеры на изменения – метрика по экшену выросла более 50% относительно обычного в данный период. ● На вырост – прогнать нейронную сеть через базу кейсов : когда потребовалась критичная оптимизация, получим рекомендации SQL-запросов по неочевидным взаимосвязям метрик. Дальнейшее развитие инструмента По мере накопления опыта и подключения других проектов появляется всё больше идей для развития и усовершенствования инструмента: ● Больше метрик (FS, cache, Request/Response size, AMQP, TOP SQL, near/far external requests …) ● Автоматическая конфигурация метрик (заведение любых метрик типов IDENT/Single/Count/Duration) с автоинициализацией БД и дашбордов ● Автоматический сбор метрик в популярных фреймворках ● Оптимизация времени отправки (например, с демоном и posix shared memory/UDP/TCP) ● Адаптация под другие языки, поддержка микросервисов ● Больше дашбордов (P95/P99…), возможность сократить дашборды для уменьшения дублирования информации, улучшение алгоритмов прогноза (нейронка) ● Автоматические отчеты на почту ● Расширение списка триггеров для Grafana alerts (+нейронка) ● Мониторинг статистики для отслеживания тенденций использования сервиса (тренды развития проекта для аналитиков) ● Связать с мониторингом железа (USE+) ● Добавить показатели по фронтенду ● Подключить отказы и прерывания – тем самым добавим метрики недоступности по экшенам ● Генерация аналитических запросов с помощью LLM, которая находится в контексте проекта ● Опциональное включение профайлинга а-ля pinba для конкретных экшенов (must have для поиска конкретных мест в коде при оптимизации) Путей для развития много, но кажется лишним двигаться в сторону Sentry и агрегировать вообще всё отовсюду и всегда. Вместо разработки универсального инструмента хочется сконцентрироваться на конкретной проблеме контроля производительности, помочь разработчикам быстро и плавно обнаружить и разобраться с проблемами на продакшене. Добавить уверенности в стабильной и качественной работе сервиса. Плюсы и минусы используемого подхода Преимущества используемых инструментов – большая гибкость как по метрикам, так и по методу отправки и отображаемому анализу, почти нет влияния на время отклика (чуть задерживаем fpm), малый объем для хранения, легко разрабатывать новые дашборды. SQL в качестве анализа – очень удобный язык. Текущие дашборды позволяют со всех сторон взглянуть на бэкенд и прозрачно видеть все аспекты производительности. Теперь по недостаткам по сравнению с аналогичными решениями: ● Ручное подключение статических вызовов в pipeline экшена. Вручную придется заводить БД и выполнять инициализирующие запросы. Хоть и настройка дашбордов решается импортом JSON файла в графану. Проблема ручного подключения решается разработкой версий библиотеки по сбору метрик для конкретных фреймворков. ● Аналоги в виде Uptrace и Sentry подключить быстрее, и они возможно дают более глубокую аналитику (например, указывают место в коде, но для этого приходится эту информацию хранить и занимать трафик/место). Мы делаем чуть по-другому: концентрация на мониторинге небольшого набора метрик, агрегация показателей на разных аспектах производительности вкупе с аналитикой с точки зрения вызовов конкретных экшенов с помощью SQL. ● Пока среди языков поддерживается только PHP. При этом сама библиотека для сбора и отправки укладывается в 200 строк кода. При необходимости можно взять пример и написать реализацию для своего языка с подходящим методом сбора и отправки. ● Микросервисы – сложнее отследить, но можно добавить единую метрику trace_id. С группировкой по trace_id отслеживать целиком процесс затрагивающий несколько микросервисов. ● В текущей схеме сложно увидеть недоступность сервиса для показателей SLI по доступности (отказы регистрируются на уровне железа), тут можем поставить дополнительный сканер и отвалившиеся запросы логировать на входе балансера/nginx и записывать в ту же БД кликхауза. ● Prometheus больше оптимизирован под хранение и выборку одиночных метрик в виде временных рядов, данные могут занимать меньше места, но дольше вставка, и, если не заложились на определенную структуру, возможно, будет дольше выборка данных особенно на сложных агрегациях по нескольким метрикам сразу. Вместо SQL используется свой язык PromQL, может чуть неудобен для сложных аналитических запросов и нужно отдельно знакомиться с синтаксисом. Итоги Гусь наконец отстал от нас и занялся музыкой =) ● В больших проектах важно отслеживать производительность с прицелом на конкретные экшены – мониторинг и анализ. ● Можно не ограничиваться стандартами RED/USE, SLI/Apdex – добавлять метрики и аналитику, полезные именно вашему проекту. ● Не просто живые графики, но и статистика вроде таблиц ТОПов, желательно с автоматическими оповещениями + прогнозы. ● Своевременная оптимизация снизит тревогу пользователей и улучшит отзывы о работе системы. Инструмент назвали VESNA.Insight – система детального мониторинга и анализа производительности сервисов с прицелом на конкретные действия пользователей. Позволяет с легкостью мониторить аспекты производительности более тысячи экшенов: время выполнения, нагрузка на БД, CPU, ожидание HTTP-запросов, RAM, ошибки. Реализована возможность группировки действий по типам, задание критичных точек по различным аспектам и мониторинг всей группы с отслеживанием выполнения целевых показателей. Довольно быстро добавляются новые метрики, расширяются панели мониторинга и аналитики. Благодаря дашборду ТОПов создаем несколько задач оптимизации для разработчиков еженедельно, сокращает время на поиск узких мест. Каждой задаче помимо описания действия дашборды сообщают ценную информацию о критичности правки, какие аспекты требуют оптимизации, оценку сложности алгоритмов и предсказание производительности, получить рекомендации по оптимизации из предыдущих кейсов работы с подобными задачами. ClickHouse отрабатывает очень шустро, индекса по времени хватает на то, что все перечисленные дашборды загружаются менее чем за 1 секунду. Агрегации моментальные: при отрисовке глобальной статистики – даже без фильтра по времени – десятки миллионов строк логов обрабатываются за пару секунд. Благодаря Grafana с плагином кликхауз можем отправлять автоматические уведомления при превышении настроенных целевых показателей по всем отслеживаемым аспектам производительности сервиса. Оценка и прогнозирование производительности дают возможность получать уведомления вида «Импорт данных превысит лимит времени/RAM при росте объема на 200%» и заложить ресурсы на оптимизацию заранее. Инструмент в первую очередь разрабатывался для внутренних нужд и уже преобразовал просто ручные точечные применения улучшений на управление целым комбайном производительности сервиса. Для коллег из интеграционных систем это гарантия бесперебойности работы с самыми важными контрактами. Для компании и менеджмента – снижение рисков, улучшение показателей работы команды и впечатлений по работе с сервисами. Для разработчиков, QA и аналитиков по проекту – уменьшение неудобств при попытках исследовать проблему с продакшена, меньше отвлечений на оперативные правки, больше уверенность при доработке тяжелых экшенов. Ну и наконец, для пользователей – отсутствие подтормаживающих экшенов и увеличение комфорта позволяет спокойно работать в системе. Я же с удовольствием провел время, разбираясь в тонкостях мониторинга, аспектах производительности и, аки детектив, выслеживал проблемные места в крупном легаси-проекте с помощью построения нужных дашбордов. После долгих лет ручного разбора логов наконец появилась возможность видеть, как методы оживают в продакшене и весь бэкенд становится видно насквозь. Чувствуется осуществление моей мечты, как бэкенд-разработчика, болеющего за свой проект. Несколько раз в месяц во время работы над задачами возникают идеи всё новых метрик и дашбордов и что с их помощью можно обнаружить – такой инструмент позволяет быстро и просто за считанные дни накидывать в графану всё необходимое. Весьма интересно, куда эта дорожка приведет в дальнейшем, какие нюансы производительности получится вскрыть и какие рубежи преодолеть. Послесловие Огромное спасибо всем, кто дочитал до конца и выжил! В комментариях предлагаю обсудить не только предложенный инструмент, но и ваш опыт внедрения или использования подобного мониторинга. Особенно если работали с Sentry/Uptrace/.. или, может, даже разработали свой аналог, прошу рассказать о впечатлениях использования этих инструментов и какой аспект больше всего пригодился. Разумеется, задавайте вопросы и пишите рекомендации по улучшению. Спасибо за поддержку и ценный фидбэк! Ещё хочется послушать, как бы пригодился подобный инструмент в вашем языке (или, может, ваш язык уже имеет мощный встроенный инструмент мониторинга и анализа производительности экшенов и подключать что-то ещё не требуется?), какие метрики 100% нужно добавить, а какие будут бесполезны. А так – хочется пожелать всем быстрых сервисов и безотказных экшенов, при всем этом – спокойной разработки и размеренной оптимизации. До встречи!
Markdown	[Все потоки](https://habr.com/ru/articles/) [Войти](https://habr.com/kek/v1/auth/habrahabr/?back=/ru/companies/etpgpb_vesna/articles/946000/&hl=ru) [![](https://habrastorage.org/getpro/habr/company/f4f/29f/9d3/f4f29f9d312a85b3b1abe9bcfcad1ab8.png)](https://habr.com/ru/companies/etpgpb_vesna/profile/) [ЭТП ГПБ / VESNA](https://habr.com/ru/companies/etpgpb_vesna/profile/) 4,37 Оценка работодателя 46,89 Рейтинг 27 Подписчики Подписаться [![](https://habrastorage.org/r/w48/getpro/habr/avatars/7c1/033/627/7c10336274775082efe7d847711b0f26.jpeg)](https://habr.com/ru/users/chronoexp/) [chronoexp](https://habr.com/ru/users/chronoexp/) 11 сен 2025 в 10:26 # Мониторинг и анализ производительности бэкенда с помощью ClickHouse и Grafana. Часть 3 Средний 15 мин 9\.3K [Блог компании ЭТП ГПБ / VESNA](https://habr.com/ru/companies/etpgpb_vesna/articles/)[Анализ и проектирование систем \](https://habr.com/ru/hubs/analysis_design/) [PHP \](https://habr.com/ru/hubs/php/) [DevOps \](https://habr.com/ru/hubs/devops/) [Веб-разработка \](https://habr.com/ru/hubs/webdev/) Кейс > [Ссылка на часть 1](https://habr.com/ru/companies/etpgpb_vesna/articles/939742) > [Ссылка на часть 2](https://habr.com/ru/companies/etpgpb_vesna/articles/944148) Всем привет! Я Артём Седых, работаю ведущим разработчиком команды банковского сопровождения. Проекту уже девятый год, накопилась большая функциональная база и много легаси-кода с набором узких мест для возможной оптимизации. В данном наборе статей рассказываю про наш опыт разработки и внедрения собственной системы мониторинга бэкенда PHP с возможностью просмотреть, как именно проседают экшены, и даже спрогнозировать их поведение. Если не читали предыдущие части, ссылки выше. Сегодня, в третьей и заключительной части, рассмотрим мониторинг со стороны devops на дашбордах SLI/Apdex, поколдуем над статистическими методами для прогноза снижения производительности (рубрика «эксперименты»), поговорим об автоматических уведомлениях Grafana. Оценим перспективы развития, сравнительный анализ выбранного подхода и выводы по нашему опыту. Заваривайте любимый напиток, приятного прочтения\! ### Расследование проблемных параметров В прошлой части было много дашбордов для изучения и оценки больше количественных показателей по проекту и экшенам с самой разнообразной агрегацией. Теперь попробуем получить информацию из метрики параметров. Дашборд покажет, какие именно параметры загружают систему дольше всего вместе с их количеством и количеством ошибок. Выполняется группировка по parameters. `Отследить, какие именно параметры имеют больше влияния на время работы системы` Для лучшей четкости картинки можно открыть в новой вкладке. ![Дашборд расследования параметров](https://habrastorage.org/r/w1560/getpro/habr/upload_files/629/d2f/86a/629d2f86a7ef45cadc3a7ad7d72334ee.png) Дашборд расследования параметров Тут уже вступает анализ конкретных данных, стоит обратить внимание: а всё ли нормально с этими параметрами, корректно ли обрабатываются и почему обработка так долго занимает. Добавлен фильтр по пользователю: если есть тяжелый пользователь с дашборда ТОПов, здесь увидим, какие параметры он запрашивает. На второй таблице можно точечно отследить конкретные запросы конкретного юзера с конкретными параметрами и получить по ним статистику. Часто помогает и наоборот: если на других дашбордах видно аномалию, этот дашборд покажет, при каком наборе параметров она возникает. ### Дашборд SLI и Apdex Со стороны бизнеса и devops первое, на что стоит обратить внимание, – конкретные показатели производительности по стандартам SRE (Site Reliability Engineering) вроде [SLI](https://habr.com/ru/articles/718796/) и [Apdex](https://habr.com/ru/companies/sravni/articles/802705/) по четко выставленным критериям. Это вполне реализуемо на текущих инструментах в разрезе каждого тега и экшена. До сих пор в ClickHouse использовали только одну таблицу – таблицу логов. Для удобства аналитики укажем целевые показатели SLI и Apdex по времени отклика прямо в CH в виде отдельной таблицы – это позволит приджойниться и динамически отследить соответствие метрик поставленным целям. Мы выбрали разное время для разных тегов исходя из природы операции. Например, время на загрузку списка сущностей в таблицу фронтенда должно быть довольно мало, т. к. это наиболее востребованное действие в системе. При этом на тяжелую операцию импорта или интеграции можно заложить побольше, особенно если пользователь не участвует в операции и не ждет немедленной реакции. Перечень колонок таблицы с целевыми показателями по времени SLI и Apdex: `log_target(action_tag, slo_percent, sli_time, apdex_time)` При вычислении по формулам целевое время выбирается из этой таблицы по конкретному тегу в логе операций. `Отследить показатели производительности сервиса по стандартам Google Site Reliability Engineering` Пример SLI ![Формула расчета показателя](https://habrastorage.org/r/w1560/getpro/habr/upload_files/f51/94c/ed6/f5194ced6f26253d498ee0f5f9cdf429.png) Формула расчета показателя ![Дашборд отслеживания SLI](https://habrastorage.org/r/w1560/getpro/habr/upload_files/65e/62e/a88/65e62ea88317d5e05278327c48a441e6.png) Дашборд отслеживания SLI Видно как глобальный индекс, так и с разбивкой по тегам и экшенам. В таблице видно тяжелые экшены по показателю SLI с сортировкой по низкому %. В первую очередь стоит заняться оптимизацией красной зоны. Дополнительно планируем вычислять характеристику импакта в целом по системе: к примеру, экшен А вызвали всего 2 раза за день, он нарушил сроки и находится в красной зоне, а экшен Б вызвали 10 000 раз, но он обитает в желтой зоне – всё же оптимизировать Б до зеленого важнее, чем помочь единичным вызовам экшена А. Эта характеристика даст больше информации и понимания при выборе приоритетов для оптимизации. Пример Apdex ![Формула расчета показателя](https://habrastorage.org/r/w1560/getpro/habr/upload_files/250/b49/652/250b49652f50da314285e78050165eb5.png) Формула расчета показателя ![Дашборд отслеживания Apdex](https://habrastorage.org/r/w1560/getpro/habr/upload_files/7d4/b02/6ac/7d4b026acb886dd79172f1992f19b130.png) Дашборд отслеживания Apdex Apdex покажет комфорт пользователей при работе в системе относительно отдельных тегов и экшенов. Целевое время зададим ниже отметки для SLI как рекомендованное время для удобства пользователя. Покажет, где пользователи ждут больше обычного в наглядных областях «хороший», «медленный» и «плохой». Разобравшись с проблемами по SLI, можно будет приняться за улучшение показателя Apdex. ### Дашборд Business Apdex Отследить показатели производительности сервиса метрикой Apdex с группировкой по бизнес-понятиям. Вместо специфичных для разработки понятий (тег, экшен, контроллер) отобразить информацию в виде удобных и понятных панелей-карточек. Каждая панель отображает одну из частей системы с человеческим названием и может в себе группировать один или несколько экшенов. Для возможности группировки и мониторинга по бизнес-понятиям заведем таблицу в ClickHouse с колонками: `log_business_target(action_tag, controller, action, business_target, apdex_time, priority)` Конфигурация поможет гибко настроить маппинг tag-controller-action =\> понятие + целевое время для Apdex. Выполняется группировка по понятиям и сортировка по приоритету. Список понятий формируется эмпирически, что именно необходимо отслеживать по системе. В одну карточку могут попасть как один конкретный экшен, так и целая группа, покрывающая часть логики сервиса. В Grafana используется элемент Canvas с настройкой Repeat by variable (business\_target). Пример дашборда на тестовом наборе данных, где части системы были под нагрузкой (чтобы показать разные цвета): ![Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex](https://habrastorage.org/r/w1560/getpro/habr/upload_files/ff6/1b2/559/ff61b255953cc901cf18db31a79d2393.png) Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex ● Отображает для каждого бизнес-понятия панель с состоянием Apdex за указанный период Grafana человеческими словами. ● Отображает динамику по сравнению с предыдущим периодом (+-0.xx). ● Отображает справочную информацию о целевом времени и о количестве запросов. ● Позволяет отфильтровать только нужные бизнес-понятия либо вывести все сразу. Каждая карточка нацелена на свое время Apdex, и помимо самого индекса отображает дополнительную информацию. Дашборд использовать как средство мониторинга состояния системы для менеджеров, бизнес-аналитиков, заказчиков и других заинтересованных лиц. ### Дашборд оценки и прогнозирования производительности экшенов Однажды при наблюдении за статистикой по экшенам появилась мысль: «если у нас такой богатый объем данных, есть статистика производительности экшена и есть числовые показатели, на каких масштабах данных выполнялся экшен, почему бы не зайти дальше и не попытаться оценить, как себя поведет экшен в будущем при росте этих показателей?». Сказано – сделано: кастомный инструмент очередной раз показал, насколько быстро и гибко получается накидывать дашборды, ограничиваясь лишь фантазией и здравым смыслом. `Используя статистические методы, оценить зависимость используемых ресурсов от объема данных и спрогнозировать поведение экшена.` Оценка и прогнозы основаны на базовых методах математической статистики и подвержены ухудшению при аномалиях или недостаточном количестве данных. В основе стоит гипотеза о том, что потребление экшеном ресурса (время и RAM) зависит от объема данных, который представлен количеством SQL-запросов либо длительностью их выполнения. Если же экшен по природе не меняет количество или общую длительность SQL-запросов, корреляцию этим дашбордом обнаружить не получится. ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/dd0/136/ec0/dd0136ec0c02d5b6a3564691a8bf1b9e.png) Текущий алгоритм, по которому выполняется оценка сложности O(n^x): анализ сложности на основе регрессии логарифмов или log-log regression analysis / plot в английской терминологии ([ссылка 1](https://en.wikipedia.org/wiki/Log%E2%80%93log_plot), [ссылка 2](https://www.vexpower.com/brief/log-log-model), больше про сложность и линейную регрессию при оценке алгоритмов – [ссылка 3](https://ppml.dev/algorithms.html)). Стоит отметить, это ни в коем случае не аналитическая сложность алгоритма (экшена), а сложность в бытовом понимании – оценить, насколько увеличивается время работы от объема данных, и попытаться предсказать, сколько времени займет при увеличении этого объема. Ключевые моменты (под спойлером) 1. Два предположительно взаимосвязанных массива данных в отношении a =\> b. 2. Используется натуральный логарифм. Логарифм превращает сложную степенную зависимость в линейную, чтобы легко найти показатель сложности slope через линейную регрессию. 3. Расчет ковариации и дисперсии. Ковариация – это статистическая мера того, насколько две переменные изменяются вместе. В нашем случае это мера того, как ln(total\_sql\_queries) и ln(duration\_s) изменяются относительно друг друга. Дисперсия – это мера разброса значений переменной. Здесь мы используем дисперсию ln(total\_sql\_queries). 4. Расчет наклона (slope). Наклон линии регрессии в log-log пространстве рассчитывается как отношение ковариации к дисперсии. Этот наклон и есть показатель сложности алгоритма. 5. Интерпретация наклона. Если наклон близок к 1, это указывает на линейную сложность O(N). Наклон между 1 и 2 может указывать на сложность O(N\log(N)). Наклон около 2 указывает на квадратичную сложность O(N^2). Другие значения наклона интерпретируются как O(N^slope). 6. Экстраполяция. Используя полученный наклон (slope), мы можем предсказать время выполнения для больших объемов данных. Дашборд в альфа-версии. Список улучшений на будущее: улучшить качество оценки (другие алгоритмы прогноза; нейронная сеть лучше отследит закономерности), убрать недостоверную оценку (отрицательную сложность), снизить влияние аномалий и шумов на оценку, дать возможность повысить приоритет точек на экстремумах. Примеры – оценка и прогноз времени отклика экшена в зависимости от объема данных* Пример импорта позиций спецификации из XLSX. Значение prediction\_multipler задает, насколько далеко мы желаем увеличить объемы данных для прогноза, обычно ×1 хватает для просмотра кривой сложности. ![Дашборд прогнозирования сложности времени на примере экшена типа import](https://habrastorage.org/r/w1560/getpro/habr/upload_files/123/4ba/c21/1234bac21dcad3e3d49895b6395584ac.png) Дашборд прогнозирования сложности времени на примере экшена типа import Попробуем оценить результат: ● Время импорта нелинейно зависит от количества SQL-запросов. Степенная сложность O(n^3) может говорить о том, что используется алгоритм вида for-for-for с тяжелой операцией во внутреннем цикле, стоит пересмотреть алгоритм импорта. ● Время импорта линейно зависит от длительности SQL-запросов, здесь мало пользы. Пример экспорта списка позиций реестра платежей в XLSX ![Дашборд прогнозирования сложности времени на примере экшена типа export](https://habrastorage.org/r/w1560/getpro/habr/upload_files/630/e24/700/630e2470063551097daa6cdfc1362a91.png) Дашборд прогнозирования сложности времени на примере экшена типа export ● Время экспорта не зависит от количества SQL-запросов (количество запросов не меняется, а время растет) – оценка сложности невозможна. ● Время экспорта почти линейно зависит от длительности SQL-запросов. Сейчас проблемы нет, однако можем спрогнозировать, при каком росте объема данных наступит лимит по времени выполнения для пользователя. Оценка и прогноз времени CPU в зависимости от объема данных В предыдущем прогнозе время отклика содержит в себе и собственно время обработки SQL-запросов (а по нему мы и пытаемся оценить зависимость). Как тогда найти сложные вычислительные алгоритмы и операции самого кода без учета запросов к БД? При оценке сложности берем общее время отклика и минус время из метрик типа Duration. Останется т. н. время CPU, не учтенное ни в каких других метриках Duration. Повышенный slope времени CPU, скорее всего, и будет означать медленный код: недостаточно эффективные алгоритмы; медленные библиотеки. Рассмотрим на примере экспорта списка компаний заявки. Оценка времени отклика показала O(n^0.36) и O(n^0.41). Однако если оценивать время без БД и внешних запросов: ![Дашборд прогнозирования сложности времени CPU на примере экшена типа export](https://habrastorage.org/r/w1560/getpro/habr/upload_files/c21/690/6f4/c216906f44a49923c1f7529cbb4982e8.png) Дашборд прогнозирования сложности времени CPU на примере экшена типа export Время CPU более чем линейно зависит от количества SQL-запросов. Это говорит о неэффективном использовании алгоритмов (действительно, используется медленная библиотека для генерации файла экспорта – phpspreadsheet). После перехода на собственную разработку, которая распаковывает xlsx и работает с xml, как со строками, получилось снизить сложность. ![Тот же экшен после внедрения оптимизации](https://habrastorage.org/r/w1560/getpro/habr/upload_files/b36/97c/8f0/b3697c8f022af9818c6ffc1936143cb0.png) Тот же экшен после внедрения оптимизации Оценка и прогноз использования RAM в зависимости от объема данных Пример экспорта списка позиций в XLSX ![Дашборд прогнозирования сложности потребления RAM на примере экшена типа export](https://habrastorage.org/r/w1560/getpro/habr/upload_files/27c/960/925/27c960925d29efec3b64cef20881ff0f.png) Дашборд прогнозирования сложности потребления RAM на примере экшена типа export Максимальный объем задействованной оперативной памяти более чем линейно зависит от длительности SQL-запросов. Это говорит о неэффективном использовании RAM (действительно, используется библиотека phpspreadsheet, которая в базовой реализации требует многократного объема оперативной памяти). Дашбор ТОПов экшенов по оценке сложности ![ТОПы по оценке сложности среди экшенов контроллера request](https://habrastorage.org/r/w1560/getpro/habr/upload_files/a53/ccf/a66/a53ccfa66b51d24fb2e07183c11aa83c.png) ТОПы по оценке сложности среди экшенов контроллера request Аналогично разделу ТОПов дашборд составлен для быстрого поиска экшенов с высокой оценкой сложности по перечисленным критериям. Это позволит обнаружить экшены, которые в перспективе могут стать тяжелыми при увеличении объемов данных. Как и намекает JSON Statham с картинки, не стоит верить статистике: необязательно высокая оценка сложности приведет к медленному экшену в перспективе. Каждый экшен лучше дополнительно анализировать и изучать текущую статистику: может ли существенно увеличиться объем данных; как часто экшен вызывается; насколько важно заниматься оптимизацией. Оценка также может быть рассчитана неточно: повлияют аномалии, шумы или недостаток данных. С опытом и анализом по другим дашбордам придет понимание, на какие экшены действительно стоит обратить внимание при закладывании оптимизации. ## Автоматические оповещения Аналитики с других дашбордов уже хватает на месяцы работ по оптимизации. В перспективе понадобятся автоматические рассылки при резком снижении производительности экшена. Возможности Grafana alerts позволяют гибко настроить правила рассылок, а составление запросов с помощью SQL развязывает руки в плане вариантов событий. ![Интерфейс Grafana для настройки автоматических уведомлений](https://habrastorage.org/r/w1560/getpro/habr/upload_files/952/651/ccd/952651ccd6f68b2c1b6fdcd91b958396.png) Интерфейс Grafana для настройки автоматических уведомлений ![Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд](https://habrastorage.org/r/w1560/getpro/habr/upload_files/8fd/065/c2d/8fd065c2df6e07aaf81c2b62bf11f3cd.png) Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд Тут и пригодилась таблица с настройками по целевым показателям SLI: например, можно создать алерт со списком экшенов, которые нарушили SLO за выбранный период. ``` ``` ![Пример результата по алерту нарушения SLO](https://habrastorage.org/r/w1560/getpro/habr/upload_files/175/962/8b6/1759628b60c9af4fd2c25b1e738caf17.png) Пример результата по алерту нарушения SLO Можно строить любые запросы и выдавать в уведомлении всё, что выдаст этот запрос. Можно запросом получать некоторую метрику и в автоматическом режиме задать правила и значения, при которых оповещение будет рассылаться. Поддерживаются самые разнообразные экспортеры: почта, смс, телеграм и другие мессенджеры. Примеры условий для алертов по экшенам: ● Тяжелый запрос БД – % БД по времени дольше остальных %. ● Запросы к БД – больше 5 000 запросов в одном вызове экшена. ● Много итераций в интеграции – интеграция в цикле. ● Неоптимизированный код – долгое время вычисления CPU. ● Большое потребление памяти – медиана по потреблению за полчаса от 100 МБ. ● Триггеры на изменения – метрика по экшену выросла более 50% относительно обычного в данный период. ● На вырост – прогнать нейронную сеть через базу кейсов: когда потребовалась критичная оптимизация, получим рекомендации SQL-запросов по неочевидным взаимосвязям метрик. ## Дальнейшее развитие инструмента По мере накопления опыта и подключения других проектов появляется всё больше идей для развития и усовершенствования инструмента: ● Больше метрик (FS, cache, Request/Response size, AMQP, TOP SQL, near/far external requests …) ● Автоматическая конфигурация метрик (заведение любых метрик типов IDENT/Single/Count/Duration) с автоинициализацией БД и дашбордов ● Автоматический сбор метрик в популярных фреймворках ● Оптимизация времени отправки (например, с демоном и posix shared memory/UDP/TCP) ● Адаптация под другие языки, поддержка микросервисов ● Больше дашбордов (P95/P99…), возможность сократить дашборды для уменьшения дублирования информации, улучшение алгоритмов прогноза (нейронка) ● Автоматические отчеты на почту ● Расширение списка триггеров для Grafana alerts (+нейронка) ● Мониторинг статистики для отслеживания тенденций использования сервиса (тренды развития проекта для аналитиков) ● Связать с мониторингом железа (USE+) ● Добавить показатели по фронтенду ● Подключить отказы и прерывания – тем самым добавим метрики недоступности по экшенам ● Генерация аналитических запросов с помощью LLM, которая находится в контексте проекта ● Опциональное включение профайлинга а-ля pinba для конкретных экшенов (must have для поиска конкретных мест в коде при оптимизации) Путей для развития много, но кажется лишним двигаться в сторону Sentry и агрегировать вообще всё отовсюду и всегда. Вместо разработки универсального инструмента хочется сконцентрироваться на конкретной проблеме контроля производительности, помочь разработчикам быстро и плавно обнаружить и разобраться с проблемами на продакшене. Добавить уверенности в стабильной и качественной работе сервиса. ## Плюсы и минусы используемого подхода Преимущества используемых инструментов – большая гибкость как по метрикам, так и по методу отправки и отображаемому анализу, почти нет влияния на время отклика (чуть задерживаем fpm), малый объем для хранения, легко разрабатывать новые дашборды. SQL в качестве анализа – очень удобный язык. Текущие дашборды позволяют со всех сторон взглянуть на бэкенд и прозрачно видеть все аспекты производительности. Теперь по недостаткам по сравнению с аналогичными решениями: ● Ручное подключение статических вызовов в pipeline экшена. Вручную придется заводить БД и выполнять инициализирующие запросы. Хоть и настройка дашбордов решается импортом JSON файла в графану. Проблема ручного подключения решается разработкой версий библиотеки по сбору метрик для конкретных фреймворков. ● Аналоги в виде Uptrace и Sentry подключить быстрее, и они возможно дают более глубокую аналитику (например, указывают место в коде, но для этого приходится эту информацию хранить и занимать трафик/место). Мы делаем чуть по-другому: концентрация на мониторинге небольшого набора метрик, агрегация показателей на разных аспектах производительности вкупе с аналитикой с точки зрения вызовов конкретных экшенов с помощью SQL. ● Пока среди языков поддерживается только PHP. При этом сама библиотека для сбора и отправки укладывается в 200 строк кода. При необходимости можно взять пример и написать реализацию для своего языка с подходящим методом сбора и отправки. ● Микросервисы – сложнее отследить, но можно добавить единую метрику trace\_id. С группировкой по trace\_id отслеживать целиком процесс затрагивающий несколько микросервисов. ● В текущей схеме сложно увидеть недоступность сервиса для показателей SLI по доступности (отказы регистрируются на уровне железа), тут можем поставить дополнительный сканер и отвалившиеся запросы логировать на входе балансера/nginx и записывать в ту же БД кликхауза. ● Prometheus больше оптимизирован под хранение и выборку одиночных метрик в виде временных рядов, данные могут занимать меньше места, но дольше вставка, и, если не заложились на определенную структуру, возможно, будет дольше выборка данных особенно на сложных агрегациях по нескольким метрикам сразу. Вместо SQL используется свой язык PromQL, может чуть неудобен для сложных аналитических запросов и нужно отдельно знакомиться с синтаксисом. ## Итоги ![ Гусь наконец отстал от нас и занялся музыкой =)](https://habrastorage.org/r/w1560/getpro/habr/upload_files/e43/898/34a/e4389834a3b013fc658ceb73b40fd146.png) Гусь наконец отстал от нас и занялся музыкой =) ● В больших проектах важно отслеживать производительность с прицелом на конкретные экшены – мониторинг и анализ. ● Можно не ограничиваться стандартами RED/USE, SLI/Apdex – добавлять метрики и аналитику, полезные именно вашему проекту. ● Не просто живые графики, но и статистика вроде таблиц ТОПов, желательно с автоматическими оповещениями + прогнозы. ● Своевременная оптимизация снизит тревогу пользователей и улучшит отзывы о работе системы. Инструмент назвали VESNA.Insight – система детального мониторинга и анализа производительности сервисов с прицелом на конкретные действия пользователей. Позволяет с легкостью мониторить аспекты производительности более тысячи экшенов: время выполнения, нагрузка на БД, CPU, ожидание HTTP-запросов, RAM, ошибки. Реализована возможность группировки действий по типам, задание критичных точек по различным аспектам и мониторинг всей группы с отслеживанием выполнения целевых показателей. Довольно быстро добавляются новые метрики, расширяются панели мониторинга и аналитики. Благодаря дашборду ТОПов создаем несколько задач оптимизации для разработчиков еженедельно, сокращает время на поиск узких мест. Каждой задаче помимо описания действия дашборды сообщают ценную информацию о критичности правки, какие аспекты требуют оптимизации, оценку сложности алгоритмов и предсказание производительности, получить рекомендации по оптимизации из предыдущих кейсов работы с подобными задачами. ClickHouse отрабатывает очень шустро, индекса по времени хватает на то, что все перечисленные дашборды загружаются менее чем за 1 секунду. Агрегации моментальные: при отрисовке глобальной статистики – даже без фильтра по времени – десятки миллионов строк логов обрабатываются за пару секунд. Благодаря Grafana с плагином кликхауз можем отправлять автоматические уведомления при превышении настроенных целевых показателей по всем отслеживаемым аспектам производительности сервиса. Оценка и прогнозирование производительности дают возможность получать уведомления вида «Импорт данных превысит лимит времени/RAM при росте объема на 200%» и заложить ресурсы на оптимизацию заранее. Инструмент в первую очередь разрабатывался для внутренних нужд и уже преобразовал просто ручные точечные применения улучшений на управление целым комбайном производительности сервиса. Для коллег из интеграционных систем это гарантия бесперебойности работы с самыми важными контрактами. Для компании и менеджмента – снижение рисков, улучшение показателей работы команды и впечатлений по работе с сервисами. Для разработчиков, QA и аналитиков по проекту – уменьшение неудобств при попытках исследовать проблему с продакшена, меньше отвлечений на оперативные правки, больше уверенность при доработке тяжелых экшенов. Ну и наконец, для пользователей – отсутствие подтормаживающих экшенов и увеличение комфорта позволяет спокойно работать в системе. Я же с удовольствием провел время, разбираясь в тонкостях мониторинга, аспектах производительности и, аки детектив, выслеживал проблемные места в крупном легаси-проекте с помощью построения нужных дашбордов. После долгих лет ручного разбора логов наконец появилась возможность видеть, как методы оживают в продакшене и весь бэкенд становится видно насквозь. Чувствуется осуществление моей мечты, как бэкенд-разработчика, болеющего за свой проект. Несколько раз в месяц во время работы над задачами возникают идеи всё новых метрик и дашбордов и что с их помощью можно обнаружить – такой инструмент позволяет быстро и просто за считанные дни накидывать в графану всё необходимое. Весьма интересно, куда эта дорожка приведет в дальнейшем, какие нюансы производительности получится вскрыть и какие рубежи преодолеть. ## Послесловие Огромное спасибо всем, кто дочитал до конца и выжил! В комментариях предлагаю обсудить не только предложенный инструмент, но и ваш опыт внедрения или использования подобного мониторинга. Особенно если работали с Sentry/Uptrace/.. или, может, даже разработали свой аналог, прошу рассказать о впечатлениях использования этих инструментов и какой аспект больше всего пригодился. Разумеется, задавайте вопросы и пишите рекомендации по улучшению. Спасибо за поддержку и ценный фидбэк! Ещё хочется послушать, как бы пригодился подобный инструмент в вашем языке (или, может, ваш язык уже имеет мощный встроенный инструмент мониторинга и анализа производительности экшенов и подключать что-то ещё не требуется?), какие метрики 100% нужно добавить, а какие будут бесполезны. А так – хочется пожелать всем быстрых сервисов и безотказных экшенов, при всем этом – спокойной разработки и размеренной оптимизации. До встречи\! Теги: - [мониторинг производительности](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[%D0%BC%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3+%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8]) - [backend](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[backend]) - [метрики red](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8+red]) - [оптимизация api](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F+api]) - [sre](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[sre]) - [php](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[php]) - [pinba](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[pinba]) - [clickhouse-grafana](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[clickhouse-grafana]) - [vesna.insight](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[vesna.insight]) - [оценка сложности алгоритмов](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[%D0%BE%D1%86%D0%B5%D0%BD%D0%BA%D0%B0+%D1%81%D0%BB%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D0%B8+%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%BE%D0%B2]) Хабы: - [Блог компании ЭТП ГПБ / VESNA](https://habr.com/ru/companies/etpgpb_vesna/articles/) - [Анализ и проектирование систем](https://habr.com/ru/hubs/analysis_design/) - [PHP](https://habr.com/ru/hubs/php/) - [DevOps](https://habr.com/ru/hubs/devops/) - [Веб-разработка](https://habr.com/ru/hubs/webdev/) \+8 33 [0](https://habr.com/ru/companies/etpgpb_vesna/articles/946000/comments/) [![](https://habrastorage.org/getpro/habr/company/f4f/29f/9d3/f4f29f9d312a85b3b1abe9bcfcad1ab8.png)](https://habr.com/ru/companies/etpgpb_vesna/profile/) [ЭТП ГПБ / VESNA](https://habr.com/ru/companies/etpgpb_vesna/profile/) [Сайт](https://vesna-group.ru/) [![](https://habrastorage.org/getpro/habr/avatars/7c1/033/627/7c10336274775082efe7d847711b0f26.jpeg)](https://habr.com/ru/users/chronoexp/) 5 Карма Артем Седых[@chronoexp](https://habr.com/ru/users/chronoexp/) Ведущий разработчик, тимлид Подписаться Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра ![Хабр Карьера Курсы](https://habrastorage.org/webt/qq/ey/pn/qqeypn-py71suynxbusbakjdfjw.png) Хабр Курсы для бэкендеров РЕКЛАМА Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать\! [Перейти](https://career.habr.com/courses/programmirovanie/backend-razrabotka/?erid=2VSb5zFkQ3T&utm_source=habr&utm_medium=sponsorship_hub) [Перейти в поток Бэкенд](https://habr.com/ru/flows/backend/) [Комментировать](https://habr.com/ru/companies/etpgpb_vesna/articles/946000/comments/) ## Публикации Лучшие за сутки Похожие ## Информация Сайт [vesna-group.ru](https://vesna-group.ru/) Дата регистрации 21 ноября 2024 Дата основания 26 апреля 2023 Численность 501–1 000 человек Местоположение Россия Ваш аккаунт - [Войти](https://habr.com/kek/v1/auth/habrahabr/?back=/ru/companies/etpgpb_vesna/articles/946000/&hl=ru) - [Регистрация](https://habr.com/kek/v1/auth/habrahabr-register/?back=/ru/companies/etpgpb_vesna/articles/946000/&hl=ru) Разделы - [Статьи](https://habr.com/ru/articles/) - [Новости](https://habr.com/ru/news/) - [Хабы](https://habr.com/ru/hubs/) - [Компании](https://habr.com/ru/companies/) - [Авторы](https://habr.com/ru/users/) - [Песочница](https://habr.com/ru/sandbox/) Информация - [Устройство сайта](https://habr.com/ru/docs/help/) - [Для авторов](https://habr.com/ru/docs/authors/codex/) - [Для компаний](https://habr.com/ru/docs/companies/corpblogs/) - [Документы](https://habr.com/ru/docs/docs/transparency/) - [Соглашение](https://account.habr.com/info/agreement/?hl=ru_RU) - [Конфиденциальность](https://account.habr.com/info/confidential/?hl=ru_RU) Услуги - [Корпоративный блог](https://company.habr.com/ru/corporate-blogs/) - [Медийная реклама](https://company.habr.com/ru/advertising/) - [Нативные проекты](https://company.habr.com/ru/native-special/) - [Образовательные программы](https://company.habr.com/ru/education-programs/) - [Стартапам](https://company.habr.com/ru/hello-startup/) Настройка языка [Техническая поддержка](https://habr.com/ru/feedback/) © 2006–2026, [Habr](https://company.habr.com/)
Readable Markdown	> [Ссылка на часть 1](https://habr.com/ru/companies/etpgpb_vesna/articles/939742) > [Ссылка на часть 2](https://habr.com/ru/companies/etpgpb_vesna/articles/944148) Всем привет! Я Артём Седых, работаю ведущим разработчиком команды банковского сопровождения. Проекту уже девятый год, накопилась большая функциональная база и много легаси-кода с набором узких мест для возможной оптимизации. В данном наборе статей рассказываю про наш опыт разработки и внедрения собственной системы мониторинга бэкенда PHP с возможностью просмотреть, как именно проседают экшены, и даже спрогнозировать их поведение. Если не читали предыдущие части, ссылки выше. Сегодня, в третьей и заключительной части, рассмотрим мониторинг со стороны devops на дашбордах SLI/Apdex, поколдуем над статистическими методами для прогноза снижения производительности (рубрика «эксперименты»), поговорим об автоматических уведомлениях Grafana. Оценим перспективы развития, сравнительный анализ выбранного подхода и выводы по нашему опыту. Заваривайте любимый напиток, приятного прочтения\! ### Расследование проблемных параметров В прошлой части было много дашбордов для изучения и оценки больше количественных показателей по проекту и экшенам с самой разнообразной агрегацией. Теперь попробуем получить информацию из метрики параметров. Дашборд покажет, какие именно параметры загружают систему дольше всего вместе с их количеством и количеством ошибок. Выполняется группировка по parameters. `Отследить, какие именно параметры имеют больше влияния на время работы системы` Для лучшей четкости картинки можно открыть в новой вкладке. ![Дашборд расследования параметров](https://habrastorage.org/r/w1560/getpro/habr/upload_files/629/d2f/86a/629d2f86a7ef45cadc3a7ad7d72334ee.png) Дашборд расследования параметров Тут уже вступает анализ конкретных данных, стоит обратить внимание: а всё ли нормально с этими параметрами, корректно ли обрабатываются и почему обработка так долго занимает. Добавлен фильтр по пользователю: если есть тяжелый пользователь с дашборда ТОПов, здесь увидим, какие параметры он запрашивает. На второй таблице можно точечно отследить конкретные запросы конкретного юзера с конкретными параметрами и получить по ним статистику. Часто помогает и наоборот: если на других дашбордах видно аномалию, этот дашборд покажет, при каком наборе параметров она возникает. ### Дашборд SLI и Apdex Со стороны бизнеса и devops первое, на что стоит обратить внимание, – конкретные показатели производительности по стандартам SRE (Site Reliability Engineering) вроде [SLI](https://habr.com/ru/articles/718796/) и [Apdex](https://habr.com/ru/companies/sravni/articles/802705/) по четко выставленным критериям. Это вполне реализуемо на текущих инструментах в разрезе каждого тега и экшена. До сих пор в ClickHouse использовали только одну таблицу – таблицу логов. Для удобства аналитики укажем целевые показатели SLI и Apdex по времени отклика прямо в CH в виде отдельной таблицы – это позволит приджойниться и динамически отследить соответствие метрик поставленным целям. Мы выбрали разное время для разных тегов исходя из природы операции. Например, время на загрузку списка сущностей в таблицу фронтенда должно быть довольно мало, т. к. это наиболее востребованное действие в системе. При этом на тяжелую операцию импорта или интеграции можно заложить побольше, особенно если пользователь не участвует в операции и не ждет немедленной реакции. Перечень колонок таблицы с целевыми показателями по времени SLI и Apdex: `log_target(action_tag, slo_percent, sli_time, apdex_time)` При вычислении по формулам целевое время выбирается из этой таблицы по конкретному тегу в логе операций. `Отследить показатели производительности сервиса по стандартам Google Site Reliability Engineering` Пример SLI ![Формула расчета показателя](https://habrastorage.org/r/w1560/getpro/habr/upload_files/f51/94c/ed6/f5194ced6f26253d498ee0f5f9cdf429.png) Формула расчета показателя ![Дашборд отслеживания SLI](https://habrastorage.org/r/w1560/getpro/habr/upload_files/65e/62e/a88/65e62ea88317d5e05278327c48a441e6.png) Дашборд отслеживания SLI Видно как глобальный индекс, так и с разбивкой по тегам и экшенам. В таблице видно тяжелые экшены по показателю SLI с сортировкой по низкому %. В первую очередь стоит заняться оптимизацией красной зоны. Дополнительно планируем вычислять характеристику импакта в целом по системе: к примеру, экшен А вызвали всего 2 раза за день, он нарушил сроки и находится в красной зоне, а экшен Б вызвали 10 000 раз, но он обитает в желтой зоне – всё же оптимизировать Б до зеленого важнее, чем помочь единичным вызовам экшена А. Эта характеристика даст больше информации и понимания при выборе приоритетов для оптимизации. Пример Apdex ![Формула расчета показателя](https://habrastorage.org/r/w1560/getpro/habr/upload_files/250/b49/652/250b49652f50da314285e78050165eb5.png) Формула расчета показателя ![Дашборд отслеживания Apdex](https://habrastorage.org/r/w1560/getpro/habr/upload_files/7d4/b02/6ac/7d4b026acb886dd79172f1992f19b130.png) Дашборд отслеживания Apdex Apdex покажет комфорт пользователей при работе в системе относительно отдельных тегов и экшенов. Целевое время зададим ниже отметки для SLI как рекомендованное время для удобства пользователя. Покажет, где пользователи ждут больше обычного в наглядных областях «хороший», «медленный» и «плохой». Разобравшись с проблемами по SLI, можно будет приняться за улучшение показателя Apdex. ### Дашборд Business Apdex Отследить показатели производительности сервиса метрикой Apdex с группировкой по бизнес-понятиям. Вместо специфичных для разработки понятий (тег, экшен, контроллер) отобразить информацию в виде удобных и понятных панелей-карточек. Каждая панель отображает одну из частей системы с человеческим названием и может в себе группировать один или несколько экшенов. Для возможности группировки и мониторинга по бизнес-понятиям заведем таблицу в ClickHouse с колонками: `log_business_target(action_tag, controller, action, business_target, apdex_time, priority)` Конфигурация поможет гибко настроить маппинг tag-controller-action =\> понятие + целевое время для Apdex. Выполняется группировка по понятиям и сортировка по приоритету. Список понятий формируется эмпирически, что именно необходимо отслеживать по системе. В одну карточку могут попасть как один конкретный экшен, так и целая группа, покрывающая часть логики сервиса. В Grafana используется элемент Canvas с настройкой Repeat by variable (business\_target). Пример дашборда на тестовом наборе данных, где части системы были под нагрузкой (чтобы показать разные цвета): ![Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex](https://habrastorage.org/r/w1560/getpro/habr/upload_files/ff6/1b2/559/ff61b255953cc901cf18db31a79d2393.png) Дашборд отслеживания Apdex для отслеживания именованных показателей Apdex ● Отображает для каждого бизнес-понятия панель с состоянием Apdex за указанный период Grafana человеческими словами. ● Отображает динамику по сравнению с предыдущим периодом (+-0.xx). ● Отображает справочную информацию о целевом времени и о количестве запросов. ● Позволяет отфильтровать только нужные бизнес-понятия либо вывести все сразу. Каждая карточка нацелена на свое время Apdex, и помимо самого индекса отображает дополнительную информацию. Дашборд использовать как средство мониторинга состояния системы для менеджеров, бизнес-аналитиков, заказчиков и других заинтересованных лиц. ### Дашборд оценки и прогнозирования производительности экшенов Однажды при наблюдении за статистикой по экшенам появилась мысль: «если у нас такой богатый объем данных, есть статистика производительности экшена и есть числовые показатели, на каких масштабах данных выполнялся экшен, почему бы не зайти дальше и не попытаться оценить, как себя поведет экшен в будущем при росте этих показателей?». Сказано – сделано: кастомный инструмент очередной раз показал, насколько быстро и гибко получается накидывать дашборды, ограничиваясь лишь фантазией и здравым смыслом. `Используя статистические методы, оценить зависимость используемых ресурсов от объема данных и спрогнозировать поведение экшена.` Оценка и прогнозы основаны на базовых методах математической статистики и подвержены ухудшению при аномалиях или недостаточном количестве данных. В основе стоит гипотеза о том, что потребление экшеном ресурса (время и RAM) зависит от объема данных, который представлен количеством SQL-запросов либо длительностью их выполнения. Если же экшен по природе не меняет количество или общую длительность SQL-запросов, корреляцию этим дашбордом обнаружить не получится. ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/dd0/136/ec0/dd0136ec0c02d5b6a3564691a8bf1b9e.png) Текущий алгоритм, по которому выполняется оценка сложности O(n^x): анализ сложности на основе регрессии логарифмов или log-log regression analysis / plot в английской терминологии ([ссылка 1](https://en.wikipedia.org/wiki/Log%E2%80%93log_plot), [ссылка 2](https://www.vexpower.com/brief/log-log-model), больше про сложность и линейную регрессию при оценке алгоритмов – [ссылка 3](https://ppml.dev/algorithms.html)). Стоит отметить, это ни в коем случае не аналитическая сложность алгоритма (экшена), а сложность в бытовом понимании – оценить, насколько увеличивается время работы от объема данных, и попытаться предсказать, сколько времени займет при увеличении этого объема. Ключевые моменты (под спойлером) 1. Два предположительно взаимосвязанных массива данных в отношении a =\> b. 2. Используется натуральный логарифм. Логарифм превращает сложную степенную зависимость в линейную, чтобы легко найти показатель сложности slope через линейную регрессию. 3. Расчет ковариации и дисперсии. Ковариация – это статистическая мера того, насколько две переменные изменяются вместе. В нашем случае это мера того, как ln(total\_sql\_queries) и ln(duration\_s) изменяются относительно друг друга. Дисперсия – это мера разброса значений переменной. Здесь мы используем дисперсию ln(total\_sql\_queries). 4. Расчет наклона (slope). Наклон линии регрессии в log-log пространстве рассчитывается как отношение ковариации к дисперсии. Этот наклон и есть показатель сложности алгоритма. 5. Интерпретация наклона. Если наклон близок к 1, это указывает на линейную сложность O(N). Наклон между 1 и 2 может указывать на сложность O(N\log(N)). Наклон около 2 указывает на квадратичную сложность O(N^2). Другие значения наклона интерпретируются как O(N^slope). 6. Экстраполяция. Используя полученный наклон (slope), мы можем предсказать время выполнения для больших объемов данных. Дашборд в альфа-версии. Список улучшений на будущее: улучшить качество оценки (другие алгоритмы прогноза; нейронная сеть лучше отследит закономерности), убрать недостоверную оценку (отрицательную сложность), снизить влияние аномалий и шумов на оценку, дать возможность повысить приоритет точек на экстремумах. Примеры – оценка и прогноз времени отклика экшена в зависимости от объема данных* Пример импорта позиций спецификации из XLSX. Значение prediction\_multipler задает, насколько далеко мы желаем увеличить объемы данных для прогноза, обычно ×1 хватает для просмотра кривой сложности. ![Дашборд прогнозирования сложности времени на примере экшена типа import](https://habrastorage.org/r/w1560/getpro/habr/upload_files/123/4ba/c21/1234bac21dcad3e3d49895b6395584ac.png) Дашборд прогнозирования сложности времени на примере экшена типа import Попробуем оценить результат: ● Время импорта нелинейно зависит от количества SQL-запросов. Степенная сложность O(n^3) может говорить о том, что используется алгоритм вида for-for-for с тяжелой операцией во внутреннем цикле, стоит пересмотреть алгоритм импорта. ● Время импорта линейно зависит от длительности SQL-запросов, здесь мало пользы. Пример экспорта списка позиций реестра платежей в XLSX ![Дашборд прогнозирования сложности времени на примере экшена типа export](https://habrastorage.org/r/w1560/getpro/habr/upload_files/630/e24/700/630e2470063551097daa6cdfc1362a91.png) Дашборд прогнозирования сложности времени на примере экшена типа export ● Время экспорта не зависит от количества SQL-запросов (количество запросов не меняется, а время растет) – оценка сложности невозможна. ● Время экспорта почти линейно зависит от длительности SQL-запросов. Сейчас проблемы нет, однако можем спрогнозировать, при каком росте объема данных наступит лимит по времени выполнения для пользователя. Оценка и прогноз времени CPU в зависимости от объема данных В предыдущем прогнозе время отклика содержит в себе и собственно время обработки SQL-запросов (а по нему мы и пытаемся оценить зависимость). Как тогда найти сложные вычислительные алгоритмы и операции самого кода без учета запросов к БД? При оценке сложности берем общее время отклика и минус время из метрик типа Duration. Останется т. н. время CPU, не учтенное ни в каких других метриках Duration. Повышенный slope времени CPU, скорее всего, и будет означать медленный код: недостаточно эффективные алгоритмы; медленные библиотеки. Рассмотрим на примере экспорта списка компаний заявки. Оценка времени отклика показала O(n^0.36) и O(n^0.41). Однако если оценивать время без БД и внешних запросов: ![Дашборд прогнозирования сложности времени CPU на примере экшена типа export](https://habrastorage.org/r/w1560/getpro/habr/upload_files/c21/690/6f4/c216906f44a49923c1f7529cbb4982e8.png) Дашборд прогнозирования сложности времени CPU на примере экшена типа export Время CPU более чем линейно зависит от количества SQL-запросов. Это говорит о неэффективном использовании алгоритмов (действительно, используется медленная библиотека для генерации файла экспорта – phpspreadsheet). После перехода на собственную разработку, которая распаковывает xlsx и работает с xml, как со строками, получилось снизить сложность. ![Тот же экшен после внедрения оптимизации](https://habrastorage.org/r/w1560/getpro/habr/upload_files/b36/97c/8f0/b3697c8f022af9818c6ffc1936143cb0.png) Тот же экшен после внедрения оптимизации Оценка и прогноз использования RAM в зависимости от объема данных Пример экспорта списка позиций в XLSX ![Дашборд прогнозирования сложности потребления RAM на примере экшена типа export](https://habrastorage.org/r/w1560/getpro/habr/upload_files/27c/960/925/27c960925d29efec3b64cef20881ff0f.png) Дашборд прогнозирования сложности потребления RAM на примере экшена типа export Максимальный объем задействованной оперативной памяти более чем линейно зависит от длительности SQL-запросов. Это говорит о неэффективном использовании RAM (действительно, используется библиотека phpspreadsheet, которая в базовой реализации требует многократного объема оперативной памяти). Дашбор ТОПов экшенов по оценке сложности ![ТОПы по оценке сложности среди экшенов контроллера request](https://habrastorage.org/r/w1560/getpro/habr/upload_files/a53/ccf/a66/a53ccfa66b51d24fb2e07183c11aa83c.png) ТОПы по оценке сложности среди экшенов контроллера request Аналогично разделу ТОПов дашборд составлен для быстрого поиска экшенов с высокой оценкой сложности по перечисленным критериям. Это позволит обнаружить экшены, которые в перспективе могут стать тяжелыми при увеличении объемов данных. Как и намекает JSON Statham с картинки, не стоит верить статистике: необязательно высокая оценка сложности приведет к медленному экшену в перспективе. Каждый экшен лучше дополнительно анализировать и изучать текущую статистику: может ли существенно увеличиться объем данных; как часто экшен вызывается; насколько важно заниматься оптимизацией. Оценка также может быть рассчитана неточно: повлияют аномалии, шумы или недостаток данных. С опытом и анализом по другим дашбордам придет понимание, на какие экшены действительно стоит обратить внимание при закладывании оптимизации. ## Автоматические оповещения Аналитики с других дашбордов уже хватает на месяцы работ по оптимизации. В перспективе понадобятся автоматические рассылки при резком снижении производительности экшена. Возможности Grafana alerts позволяют гибко настроить правила рассылок, а составление запросов с помощью SQL развязывает руки в плане вариантов событий. ![Интерфейс Grafana для настройки автоматических уведомлений](https://habrastorage.org/r/w1560/getpro/habr/upload_files/952/651/ccd/952651ccd6f68b2c1b6fdcd91b958396.png) Интерфейс Grafana для настройки автоматических уведомлений ![Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд](https://habrastorage.org/r/w1560/getpro/habr/upload_files/8fd/065/c2d/8fd065c2df6e07aaf81c2b62bf11f3cd.png) Пример простейшего алерта на максимальную длительность запроса: сработает при превышении 4 секунд Тут и пригодилась таблица с настройками по целевым показателям SLI: например, можно создать алерт со списком экшенов, которые нарушили SLO за выбранный период. ``` SELECT l.controller_name \|\| '.' \|\| l.action_name AS action, lt.slo_percent, ROUND((countIf(l.duration_s <= lt.sli_time) / COUNT()) 100, 2) AS sli_current FROM logs AS l JOIN log_target AS lt ON l.action_group_tag = lt.action_tag WHERE $__timeFilter(l.start_datetime) AND l.success GROUP BY l.controller_name, l.action_name, lt.slo_percent HAVING ROUND((countIf(l.duration_s <= lt.sli_time) / COUNT()) 100, 2) < lt.slo_percent; ``` ![Пример результата по алерту нарушения SLO](https://habrastorage.org/r/w1560/getpro/habr/upload_files/175/962/8b6/1759628b60c9af4fd2c25b1e738caf17.png) Пример результата по алерту нарушения SLO Можно строить любые запросы и выдавать в уведомлении всё, что выдаст этот запрос. Можно запросом получать некоторую метрику и в автоматическом режиме задать правила и значения, при которых оповещение будет рассылаться. Поддерживаются самые разнообразные экспортеры: почта, смс, телеграм и другие мессенджеры. Примеры условий для алертов по экшенам: ● Тяжелый запрос БД – % БД по времени дольше остальных %. ● Запросы к БД – больше 5 000 запросов в одном вызове экшена. ● Много итераций в интеграции – интеграция в цикле. ● Неоптимизированный код – долгое время вычисления CPU. ● Большое потребление памяти – медиана по потреблению за полчаса от 100 МБ. ● Триггеры на изменения – метрика по экшену выросла более 50% относительно обычного в данный период. ● На вырост – прогнать нейронную сеть через базу кейсов: когда потребовалась критичная оптимизация, получим рекомендации SQL-запросов по неочевидным взаимосвязям метрик. ## Дальнейшее развитие инструмента По мере накопления опыта и подключения других проектов появляется всё больше идей для развития и усовершенствования инструмента: ● Больше метрик (FS, cache, Request/Response size, AMQP, TOP SQL, near/far external requests …) ● Автоматическая конфигурация метрик (заведение любых метрик типов IDENT/Single/Count/Duration) с автоинициализацией БД и дашбордов ● Автоматический сбор метрик в популярных фреймворках ● Оптимизация времени отправки (например, с демоном и posix shared memory/UDP/TCP) ● Адаптация под другие языки, поддержка микросервисов ● Больше дашбордов (P95/P99…), возможность сократить дашборды для уменьшения дублирования информации, улучшение алгоритмов прогноза (нейронка) ● Автоматические отчеты на почту ● Расширение списка триггеров для Grafana alerts (+нейронка) ● Мониторинг статистики для отслеживания тенденций использования сервиса (тренды развития проекта для аналитиков) ● Связать с мониторингом железа (USE+) ● Добавить показатели по фронтенду ● Подключить отказы и прерывания – тем самым добавим метрики недоступности по экшенам ● Генерация аналитических запросов с помощью LLM, которая находится в контексте проекта ● Опциональное включение профайлинга а-ля pinba для конкретных экшенов (must have для поиска конкретных мест в коде при оптимизации) Путей для развития много, но кажется лишним двигаться в сторону Sentry и агрегировать вообще всё отовсюду и всегда. Вместо разработки универсального инструмента хочется сконцентрироваться на конкретной проблеме контроля производительности, помочь разработчикам быстро и плавно обнаружить и разобраться с проблемами на продакшене. Добавить уверенности в стабильной и качественной работе сервиса. ## Плюсы и минусы используемого подхода Преимущества используемых инструментов – большая гибкость как по метрикам, так и по методу отправки и отображаемому анализу, почти нет влияния на время отклика (чуть задерживаем fpm), малый объем для хранения, легко разрабатывать новые дашборды. SQL в качестве анализа – очень удобный язык. Текущие дашборды позволяют со всех сторон взглянуть на бэкенд и прозрачно видеть все аспекты производительности. Теперь по недостаткам по сравнению с аналогичными решениями: ● Ручное подключение статических вызовов в pipeline экшена. Вручную придется заводить БД и выполнять инициализирующие запросы. Хоть и настройка дашбордов решается импортом JSON файла в графану. Проблема ручного подключения решается разработкой версий библиотеки по сбору метрик для конкретных фреймворков. ● Аналоги в виде Uptrace и Sentry подключить быстрее, и они возможно дают более глубокую аналитику (например, указывают место в коде, но для этого приходится эту информацию хранить и занимать трафик/место). Мы делаем чуть по-другому: концентрация на мониторинге небольшого набора метрик, агрегация показателей на разных аспектах производительности вкупе с аналитикой с точки зрения вызовов конкретных экшенов с помощью SQL. ● Пока среди языков поддерживается только PHP. При этом сама библиотека для сбора и отправки укладывается в 200 строк кода. При необходимости можно взять пример и написать реализацию для своего языка с подходящим методом сбора и отправки. ● Микросервисы – сложнее отследить, но можно добавить единую метрику trace\_id. С группировкой по trace\_id отслеживать целиком процесс затрагивающий несколько микросервисов. ● В текущей схеме сложно увидеть недоступность сервиса для показателей SLI по доступности (отказы регистрируются на уровне железа), тут можем поставить дополнительный сканер и отвалившиеся запросы логировать на входе балансера/nginx и записывать в ту же БД кликхауза. ● Prometheus больше оптимизирован под хранение и выборку одиночных метрик в виде временных рядов, данные могут занимать меньше места, но дольше вставка, и, если не заложились на определенную структуру, возможно, будет дольше выборка данных особенно на сложных агрегациях по нескольким метрикам сразу. Вместо SQL используется свой язык PromQL, может чуть неудобен для сложных аналитических запросов и нужно отдельно знакомиться с синтаксисом. ## Итоги ![ Гусь наконец отстал от нас и занялся музыкой =)](https://habrastorage.org/r/w1560/getpro/habr/upload_files/e43/898/34a/e4389834a3b013fc658ceb73b40fd146.png) Гусь наконец отстал от нас и занялся музыкой =) ● В больших проектах важно отслеживать производительность с прицелом на конкретные экшены – мониторинг и анализ. ● Можно не ограничиваться стандартами RED/USE, SLI/Apdex – добавлять метрики и аналитику, полезные именно вашему проекту. ● Не просто живые графики, но и статистика вроде таблиц ТОПов, желательно с автоматическими оповещениями + прогнозы. ● Своевременная оптимизация снизит тревогу пользователей и улучшит отзывы о работе системы. Инструмент назвали VESNA.Insight – система детального мониторинга и анализа производительности сервисов с прицелом на конкретные действия пользователей. Позволяет с легкостью мониторить аспекты производительности более тысячи экшенов: время выполнения, нагрузка на БД, CPU, ожидание HTTP-запросов, RAM, ошибки. Реализована возможность группировки действий по типам, задание критичных точек по различным аспектам и мониторинг всей группы с отслеживанием выполнения целевых показателей. Довольно быстро добавляются новые метрики, расширяются панели мониторинга и аналитики. Благодаря дашборду ТОПов создаем несколько задач оптимизации для разработчиков еженедельно, сокращает время на поиск узких мест. Каждой задаче помимо описания действия дашборды сообщают ценную информацию о критичности правки, какие аспекты требуют оптимизации, оценку сложности алгоритмов и предсказание производительности, получить рекомендации по оптимизации из предыдущих кейсов работы с подобными задачами. ClickHouse отрабатывает очень шустро, индекса по времени хватает на то, что все перечисленные дашборды загружаются менее чем за 1 секунду. Агрегации моментальные: при отрисовке глобальной статистики – даже без фильтра по времени – десятки миллионов строк логов обрабатываются за пару секунд. Благодаря Grafana с плагином кликхауз можем отправлять автоматические уведомления при превышении настроенных целевых показателей по всем отслеживаемым аспектам производительности сервиса. Оценка и прогнозирование производительности дают возможность получать уведомления вида «Импорт данных превысит лимит времени/RAM при росте объема на 200%» и заложить ресурсы на оптимизацию заранее. Инструмент в первую очередь разрабатывался для внутренних нужд и уже преобразовал просто ручные точечные применения улучшений на управление целым комбайном производительности сервиса. Для коллег из интеграционных систем это гарантия бесперебойности работы с самыми важными контрактами. Для компании и менеджмента – снижение рисков, улучшение показателей работы команды и впечатлений по работе с сервисами. Для разработчиков, QA и аналитиков по проекту – уменьшение неудобств при попытках исследовать проблему с продакшена, меньше отвлечений на оперативные правки, больше уверенность при доработке тяжелых экшенов. Ну и наконец, для пользователей – отсутствие подтормаживающих экшенов и увеличение комфорта позволяет спокойно работать в системе. Я же с удовольствием провел время, разбираясь в тонкостях мониторинга, аспектах производительности и, аки детектив, выслеживал проблемные места в крупном легаси-проекте с помощью построения нужных дашбордов. После долгих лет ручного разбора логов наконец появилась возможность видеть, как методы оживают в продакшене и весь бэкенд становится видно насквозь. Чувствуется осуществление моей мечты, как бэкенд-разработчика, болеющего за свой проект. Несколько раз в месяц во время работы над задачами возникают идеи всё новых метрик и дашбордов и что с их помощью можно обнаружить – такой инструмент позволяет быстро и просто за считанные дни накидывать в графану всё необходимое. Весьма интересно, куда эта дорожка приведет в дальнейшем, какие нюансы производительности получится вскрыть и какие рубежи преодолеть. ## Послесловие Огромное спасибо всем, кто дочитал до конца и выжил! В комментариях предлагаю обсудить не только предложенный инструмент, но и ваш опыт внедрения или использования подобного мониторинга. Особенно если работали с Sentry/Uptrace/.. или, может, даже разработали свой аналог, прошу рассказать о впечатлениях использования этих инструментов и какой аспект больше всего пригодился. Разумеется, задавайте вопросы и пишите рекомендации по улучшению. Спасибо за поддержку и ценный фидбэк! Ещё хочется послушать, как бы пригодился подобный инструмент в вашем языке (или, может, ваш язык уже имеет мощный встроенный инструмент мониторинга и анализа производительности экшенов и подключать что-то ещё не требуется?), какие метрики 100% нужно добавить, а какие будут бесполезны. А так – хочется пожелать всем быстрых сервисов и безотказных экшенов, при всем этом – спокойной разработки и размеренной оптимизации. До встречи\!
Shard	134 (laksa)
Root Hash	14843476518697139734
Unparsed URL	com,habr!/ru/companies/etpgpb_vesna/articles/946000/ s443