Перейти к основному содержанию
Перейти к основному содержанию

Удаленный демонстрационный набор данных

В данном руководстве предполагается, что вы развернули ClickStack, используя инструкции для образа «всё в одном» или режим Local Mode Only и выполнили начальное создание пользователя. Либо вы можете пропустить всю локальную настройку и просто подключиться к нашему размещённому демо ClickStack play-clickstack.clickhouse.com, которое использует этот набор данных.

В этом руководстве используется пример набора данных, размещённый в общедоступной песочнице ClickHouse по адресу sql.clickhouse.com, к которой вы можете подключиться из локального развертывания ClickStack.

Недоступно с HyperDX в ClickHouse Cloud

Удалённые базы данных не поддерживаются, когда HyperDX развёрнут в ClickHouse Cloud. Поэтому этот набор данных недоступен.

Он включает примерно 40 часов данных, полученных из ClickHouse-версии официального демо OpenTelemetry (OTel). Данные каждую ночь повторно воспроизводятся со временными метками, смещёнными к текущему временному интервалу, что позволяет пользователям исследовать поведение системы, используя встроенные в HyperDX логи, трассировки и метрики.

Вариации данных

Поскольку набор данных каждый день повторно воспроизводится с полуночи, конкретные визуализации могут отличаться в зависимости от того, когда вы изучаете демо.

Демонстрационный сценарий​

В этом демонстрационном примере мы расследуем инцидент, связанный с интернет-магазином, который продает телескопы и сопутствующие аксессуары.

Команда службы поддержки сообщила, что пользователи сталкиваются с проблемами при завершении оплаты на этапе оформления заказа. Проблема была эскалирована в команду Site Reliability Engineering (SRE) для расследования.

Используя HyperDX, команда SRE проанализирует логи, трейсы и метрики, чтобы диагностировать и устранить проблему, а затем изучит данные пользовательских сессий, чтобы подтвердить, соответствуют ли их выводы фактическому поведению пользователей.

Демонстрация OpenTelemetry​

В этой демонстрации используется форк официального демо OpenTelemetry, поддерживаемый ClickStack.

Архитектура демо​

Демо состоит из микросервисов, написанных на разных языках программирования, которые взаимодействуют друг с другом по gRPC и HTTP, а также генератора нагрузки, использующего Locust для имитации пользовательского трафика. Исходный код этого демо был изменён для использования инструментации ClickStack.

Архитектура

Источник: https://opentelemetry.io/docs/demo/architecture/

Дополнительные сведения о демо приведены в:

Шаги демонстрации​

В этом демо мы реализовали сбор телеметрии с помощью ClickStack SDKs, развернув сервисы в Kubernetes, откуда также собираются метрики и логи.

Подключение к демонстрационному серверу​

Режим Local-Only

Этот шаг можно пропустить, если при развертывании в локальном режиме вы нажали Connect to Demo Server. При использовании данного режима к именам источников будет добавлен префикс Demo_, например Demo_Logs

Перейдите в Team Settings и нажмите Edit для Local Connection:

Редактировать подключение

Переименуйте подключение в Demo и заполните последующую форму следующими параметрами подключения к демонстрационному серверу:

  • Имя подключения: Demo
  • Host: https://sql-clickhouse.clickhouse.com
  • Username: otel_demo
  • Password: оставьте пустым
Изменить демо-подключение

Изменение источников​

Режим Local-Only

Этот шаг можно пропустить, если при развертывании в локальном режиме вы нажали Connect to Demo Server. При использовании данного режима к именам источников будет добавлен префикс Demo_, например Demo_Logs

Прокрутите вверх до Sources и измените каждый из источников — Logs, Traces, Metrics и Sessions — чтобы они использовали базу данных otel_v2.

Редактировать демо-источник
Примечание

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

Настройте временной диапазон​

Настройте временной диапазон на 1 день для отображения всех данных за предыдущие сутки с помощью селектора времени в правом верхнем углу.

Шаг 2

Вы можете заметить небольшое различие в количестве ошибок на обзорной гистограмме — незначительное увеличение красной области в нескольких последовательных столбцах.

Примечание

Расположение столбцов будет отличаться в зависимости от времени выполнения запроса к набору данных.

Фильтрация ошибок​

Чтобы выделить ошибки, используйте фильтр SeverityText и выберите error для отображения только записей с уровнем ошибки.

Ошибка должна стать более очевидной:

Шаг 3

Выявление шаблонов ошибок​

С помощью функции кластеризации HyperDX вы можете автоматически выявлять ошибки и группировать их в значимые шаблоны. Это ускоряет анализ при работе с большими объёмами логов и трассировок. Чтобы воспользоваться этой функцией, выберите Event Patterns в меню Analysis Mode на левой панели.

Кластеры ошибок выявляют проблемы, связанные с неудачными платежами, включая именованный паттерн Failed to place order. Дополнительные кластеры также указывают на проблемы с списанием средств с карт и переполнением кэша.

Шаг 4

Обратите внимание, что эти кластеры ошибок, вероятно, исходят из разных сервисов.

Изучение паттерна ошибок​

Нажмите на наиболее очевидные кластеры ошибок, которые коррелируют с зарегистрированной проблемой невозможности пользователей завершить платежи: Failed to place order.

Это отобразит список всех случаев возникновения данной ошибки, связанных со службой frontend:

Шаг 5

Выберите любую из полученных ошибок. Метаданные логов будут показаны подробно. Просмотр разделов Overview и Column Values указывает на проблему с платёжными картами, связанную с кешем:

ошибка списания с карты: не удалось списать средства с карты: rpc error: code = Unknown desc = кэш Visa переполнен: невозможно добавить новый элемент.

Шаг 6

Изучите инфраструктуру​

Мы выявили ошибку, связанную с кешем, которая, вероятно, приводит к сбоям платежей. Необходимо определить, в каком компоненте микросервисной архитектуры возникает данная проблема.

Учитывая проблему с кэшем, имеет смысл проверить базовую инфраструктуру — возможно, в связанных подах возникла проблема с памятью? В ClickStack логи и метрики объединены и отображаются в контексте, что позволяет быстро выявить первопричину.

Выберите вкладку Infrastructure, чтобы просмотреть метрики, связанные с базовыми подами сервиса frontend, и расширьте временной диапазон до 1d:

Шаг 7

Проблема, по-видимому, не связана с инфраструктурой — метрики не показали существенных изменений за указанный период времени ни до, ни после возникновения ошибки. Закройте вкладку инфраструктуры.

Изучение трассировки​

В ClickStack трассировки также автоматически коррелируются как с логами, так и с метриками. Давайте изучим трассировку, связанную с выбранным логом, чтобы определить ответственный за это сервис.

Выберите Trace для визуализации соответствующей трассировки. При прокрутке вниз в открывшемся представлении можно увидеть, как HyperDX визуализирует распределённую трассировку по микросервисам, связывая спаны в каждом сервисе. Платёж явно задействует несколько микросервисов, включая те, которые выполняют оформление заказа и конвертацию валют.

Шаг 8

Прокрутив представление вниз, можно увидеть, что сервис payment вызывает ошибку, которая затем распространяется обратно вверх по цепочке вызовов.

Шаг 9

Поиск трассировок​

Мы установили, что пользователи не могут завершить покупки из-за проблемы с кешем в платежном сервисе. Рассмотрим трассировки этого сервиса более детально, чтобы выяснить больше о первопричине.

Переключитесь на основное представление поиска, выбрав Search. Переключите источник данных на Traces и выберите представление Results table. Убедитесь, что временной диапазон по-прежнему охватывает последние сутки.

Шаг 10

Это представление отображает все трассировки за последние сутки. Поскольку известно, что проблема исходит из сервиса платежей, примените фильтр payment к ServiceName.

Шаг 11

Если применить кластеризацию событий к трассировкам, выбрав Event Patterns, можно сразу обнаружить проблему с кешем в сервисе payment.

Шаг 12

Изучение инфраструктуры трассировки​

Переключитесь на представление результатов, нажав на Results table. Отфильтруйте ошибки с помощью фильтра StatusCode и значения Error.

Шаг 13

Выберите ошибку Error: Visa cache full: cannot add new item., перейдите на вкладку Infrastructure и увеличьте временной диапазон до 1d.

Шаг 14

Сопоставляя трассировки с метриками, мы видим, что потребление памяти и ЦП увеличилось в сервисе payment, после чего упало до 0 (это можно объяснить перезапуском пода) — что указывает на то, что проблема с кешем вызвала проблемы с ресурсами. Можно ожидать, что это повлияло на время завершения платежей.

Дельты событий для более быстрого устранения проблем​

Event Deltas помогают обнаруживать аномалии, сопоставляя изменения производительности или частоты ошибок с конкретными подмножествами данных, что упрощает быстрое выявление первопричины.

Хотя мы знаем, что у сервиса payment есть проблема с кешем, приводящая к увеличению потребления ресурсов, мы пока не выявили основную причину.

Вернитесь к табличному представлению результатов и выберите временной период, содержащий ошибки, чтобы ограничить объём данных. Убедитесь, что выбран интервал, включающий несколько часов до и после возникновения ошибок, если это возможно (проблема может продолжаться):

Шаг 15

Удалите фильтр ошибок и выберите Event Deltas из меню Analysis Mode в левой части экрана.

Шаг 16

Верхняя панель показывает распределение временных интервалов, где цвета обозначают плотность событий (количество спанов). Подмножество событий за пределами основной концентрации, как правило, заслуживает наиболее пристального внимания при анализе.

Если выбрать события с длительностью более 200ms и применить фильтр Filter by selection, можно ограничить анализ медленными событиями:

Шаг 17

Анализ подмножества данных показывает, что большинство пиков производительности связано с транзакциями visa.

Использование графиков для расширенного контекста​

В ClickStack можно построить график любого числового значения из логов, трейсов или метрик для получения дополнительного контекста.

Мы установили:

  • Проблема у нас в платежном сервисе
  • Кэш переполнен
  • Это приводило к увеличению расхода ресурсов
  • Проблема мешала завершению платежей по картам Visa — или, по крайней мере, значительно замедляла их обработку.

Выберите Chart Explorer в меню слева. Укажите следующие значения для построения графика времени завершения платежей по типу диаграммы:

  • Источник данных: Трассировки
  • Метрика: Maximum
  • Столбец SQL: Duration
  • Где: ServiceName: payment
  • Интервал времени: Последние 24 часа

Нажмите ▶️, чтобы увидеть, как производительность платежей снижалась с течением времени.

Шаг 18

Если установить Group By в значение SpanAttributes['app.payment.card_type'] (для автозаполнения достаточно ввести card), можно увидеть, как снизилась производительность сервиса для транзакций Visa по сравнению с Mastercard:

Шаг 19

Обратите внимание, что после возникновения ошибки ответы возвращаются за 0s.

Изучение метрик в контексте​

Наконец, построим график размера кэша как метрику, чтобы увидеть, как он изменялся с течением времени, что даст нам дополнительный контекст.

Укажите следующие значения:

  • Источник данных: Метрики
  • Metric: Maximum
  • SQL Column: visa_validation_cache.size (gauge) (просто введите cache для автодополнения)
  • Где: ServiceName: payment
  • Group By: <пусто>

Мы видим, как размер кэша увеличивался в течение 4–5 часов (вероятно, после развёртывания программного обеспечения), прежде чем достичь максимального размера 100,000. В разделе Sample Matched Events видно, что наши ошибки коррелируют с достижением кэшем этого предела, после чего он фиксируется с размером 0, а ответы также возвращаются за 0s.

Шаг 20

Итак, проанализировав логи, трассировки и метрики, мы пришли к следующим выводам:

  • Проблема на стороне платёжного сервиса
  • Изменение поведения сервиса, вероятно из‑за развертывания, привело к медленному увеличению кэша виз в течение 4–5 часов, в результате чего его максимальный размер достиг 100 000.
  • Это вызвало увеличение потребления ресурсов по мере роста кеша — вероятно, из‑за неудачной реализации
  • По мере роста объёма кэша производительность платежей по картам Visa снижалась
  • По достижении максимального размера кэш стал отклонять платежи и сообщал, что его размер равен 0.

Использование сессий​

Сессии позволяют воспроизвести действия пользователя, предоставляя визуальное представление о том, как произошла ошибка с его точки зрения. Хотя они обычно не используются для диагностики первопричин, они полезны для подтверждения проблем, о которых сообщается в службу поддержки, и могут служить отправной точкой для более глубокого анализа.

В HyperDX сессии связаны с трассировками и журналами, что обеспечивает полное представление о первопричине проблемы.

Например, если команда поддержки предоставляет адрес электронной почты пользователя, столкнувшегося с проблемой оплаты Braulio.Roberts23@hotmail.com — зачастую эффективнее начать с анализа его сеанса, а не с прямого поиска по логам или трассировкам.

Перейдите на вкладку Client Sessions в левом меню и убедитесь, что источник данных установлен на Sessions, а временной период — на Last 1 day:

Шаг 21

Выполните поиск по SpanAttributes.userEmail: Braulio, чтобы найти сеанс клиента. При выборе сеанса слева отобразятся события браузера и связанные спаны для сеанса клиента, а справа — воспроизведённый интерфейс браузера пользователя:

Шаг 22

Воспроизведение сеансов​

Сеансы можно воспроизвести, нажав кнопку ▶️. Переключение между режимами Highlighted и All Events позволяет изменять степень детализации спанов: первый выделяет ключевые события и ошибки.

Прокрутив список спанов вниз, можно увидеть ошибку 500, связанную с /api/checkout. Нажатие кнопки ▶️ для этого спана переместит воспроизведение к данной точке сессии, что позволит подтвердить опыт пользователя — оплата просто не работает, при этом ошибка не отображается.

Шаг 23

Выбрав спан, можно подтвердить, что причиной стала внутренняя ошибка. Перейдя на вкладку Trace и просмотрев связанные спаны, можно убедиться, что клиент действительно пострадал от проблемы с кешем.

Шаг 24

Это демо разбирает реальный инцидент с неуспешными платежами в e-commerce‑приложении и показывает, как ClickStack помогает выявлять первопричины с помощью объединённых логов, трейсов, метрик и записей сессий — ознакомьтесь с другими руководствами по началу работы, чтобы глубже изучить отдельные возможности.