ClickStack - Пример журналов, трассировок и метрик
В этом руководстве на примере тестового набора данных рассматриваются как ClickStack Open Source, так и управляемый ClickStack.
- Управляемый ClickStack
- ClickStack с открытым исходным кодом
Перейдите к пользовательскому интерфейсу ClickStack (HyperDX)
Выберите ClickStack в левом меню, чтобы перейти к интерфейсу ClickStack, где вы будете автоматически авторизованы.

Загрузка образцов данных
Чтобы заполнить интерфейс примерными данными, загрузите следующий файл:
Этот файл содержит примеры логов, метрик и трейсов из нашего публичного OpenTelemetry demo — простого интернет-магазина с микросервисами. Скопируйте этот файл в директорию по вашему выбору.
Загрузка тестовых данных
Чтобы загрузить эти данные, отправьте их на HTTP-эндпоинт развёрнутого коллектора OpenTelemetry (OTel).
Выполните следующую команду для отправки данных в OTel collector:
Это имитирует источники логов, трассировок и метрик OTLP, отправляющие данные в OTel collector. В продакшене такими источниками могут быть клиентские библиотеки для различных языков программирования или даже другие 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) и нажмите кнопку воспроизведения. Кэш явно увеличивался до достижения максимального размера, после чего начали генерироваться ошибки.

В следующем примере предполагается, что вы запустили Open Source ClickStack, следуя инструкциям для универсального образа, и подключились к локальному экземпляру ClickHouse.
Перейдите к пользовательскому интерфейсу ClickStack (HyperDX)
Откройте http://localhost:8080 для доступа к интерфейсу ClickStack.

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

Загрузка образцов данных
Чтобы заполнить интерфейс примерными данными, загрузите следующий файл:
Этот файл содержит примеры логов, метрик и трейсов из нашего публичного OpenTelemetry demo — простого интернет-магазина с микросервисами. Скопируйте этот файл в директорию по вашему выбору.
Загрузка тестовых данных
Чтобы загрузить эти данные, отправьте их на HTTP-эндпоинт развёрнутого коллектора OpenTelemetry (OTel).
Сначала экспортируйте API-ключ, скопированный выше.
Выполните следующую команду для отправки данных в OTel collector:
Это имитирует источники логов, трассировок и метрик OTLP, отправляющие данные в OTel collector. В продакшене такими источниками могут быть клиентские библиотеки для различных языков программирования или даже другие 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) и нажмите кнопку воспроизведения. Кэш явно увеличивался до достижения максимального размера, после чего начали генерироваться ошибки.

