ClickStack - примеры логов, трассировок и метрик
В следующем примере предполагается, что вы запустили ClickStack, используя инструкции для образа «всё-в-одном» и подключились к локальному экземпляру ClickHouse или экземпляру ClickHouse Cloud.
Этот демонстрационный набор данных также может использоваться с HyperDX в ClickHouse Cloud, с незначительными изменениями в последовательности действий, отмеченными ниже. При использовании HyperDX в ClickHouse Cloud пользователям потребуется локально запущенный коллектор OpenTelemetry, как описано в руководстве по началу работы для этой модели развертывания.
Перейдите в интерфейс HyperDX
Перейдите по адресу http://localhost:8080 для доступа к интерфейсу HyperDX при локальном развёртывании. При использовании HyperDX в ClickHouse Cloud выберите ваш сервис и пункт HyperDX в меню слева.

Скопируйте ключ API для приёма данных
Этот шаг не требуется при использовании HyperDX в ClickHouse Cloud, где поддержка ключей ингестии в настоящее время отсутствует.
Перейдите в Team Settings и скопируйте Ingestion API Key из раздела API Keys. Этот ключ API для приёма данных обеспечивает безопасность ингестии данных через коллектор OpenTelemetry.

Загрузка образцов данных
Для заполнения интерфейса тестовыми данными загрузите следующий файл:
Этот файл содержит примеры логов, метрик и трейсов из нашего публичного OpenTelemetry demo — простого интернет-магазина с микросервисами. Скопируйте этот файл в выбранную директорию.
Загрузка тестовых данных
Для загрузки этих данных просто отправьте их на HTTP-эндпоинт развёрнутого коллектора OpenTelemetry (OTel).
Сначала экспортируйте скопированный выше API-ключ.
Этот шаг не требуется при использовании HyperDX в ClickHouse Cloud, где поддержка ключей ингестии в настоящее время отсутствует.
Выполните следующую команду для отправки данных в OTel collector:
Это имитирует источники логов, трейсов и метрик OTLP, отправляющие данные в OTel collector. В production-среде такими источниками могут быть языковые клиенты или даже другие OTel collector.
Вернувшись к представлению Search, вы должны увидеть, что данные начали загружаться (если данные не отображаются, установите временной диапазон Last 1 hour):

Загрузка данных займет несколько минут. Дождитесь завершения загрузки, прежде чем переходить к следующим шагам.
Изучение сессий
Предположим, поступили сообщения о том, что пользователи испытывают проблемы при оплате товаров. Мы можем изучить их действия с помощью функции воспроизведения сеансов HyperDX.
Выберите Client Sessions в левом меню.

Это представление позволяет просматривать фронтенд-сеансы нашего интернет-магазина. Сеансы остаются анонимными до тех пор, пока пользователи не перейдут к оформлению заказа и не попытаются завершить покупку.
Обратите внимание, что для некоторых сессий с электронной почтой зафиксированы ошибки, что может подтверждать сообщения о неудачных транзакциях.
Выберите трассировку с ошибкой и связанным email. В открывшемся представлении можно воспроизвести сеанс пользователя и изучить его проблему. Нажмите кнопку воспроизведения, чтобы просмотреть сеанс.

Воспроизведение показывает, как пользователь перемещается по сайту и добавляет товары в корзину. При необходимости можно перейти к более поздней части сеанса, где выполняется попытка завершить оплату.
Ошибки отмечены на временной шкале красным цветом.
Пользователь не смог оформить заказ, при этом явная ошибка не отображалась. Прокрутите левую панель вниз до конца — она содержит сетевые события и события консоли из браузера пользователя. Вы увидите, что при выполнении запроса /api/checkout возникла ошибка 500.

Выберите эту ошибку 500. Ни Overview, ни Column Values не указывают на источник проблемы — только то, что ошибка является неожиданной и вызывает Internal Error.
Изучение трассировок
Перейдите на вкладку Trace, чтобы просмотреть полную распределенную трассировку.

Прокрутите трассировку вниз, чтобы увидеть источник ошибки — спан сервиса checkout. Выберите спан сервиса Payment.

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

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

Установлено, что кэш в платёжном сервисе переполняется, что блокирует завершение платежей.
Изучение логов
Для получения дополнительной информации можно вернуться к представлению Search:
Выберите Logs из источников и примените фильтр к сервису payment.

Видно, что несмотря на недавнее возникновение проблемы, количество затронутых платежей значительно. Кроме того, похоже, что проблемы вызывает кэш, связанный с платежами Visa.
Метрики диаграммы
Хотя в код явно была внесена ошибка, мы можем использовать метрики для проверки размера кэша. Перейдите в представление Chart Explorer.
Выберите Metrics в качестве источника данных. Заполните конструктор графика для построения Maximum метрики visa_validation_cache.size (Gauge) и нажмите кнопку воспроизведения. Кэш явно увеличивался до достижения максимального размера, после чего начали возникать ошибки.
