> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Удалённый демо-набор данных
> Начало работы с ClickStack и удалённым демо-набором данных
export const Image = ({img, alt, size}) => {
return
;
};
**В этом руководстве предполагается, что вы развернули ClickStack с открытым исходным кодом, следуя [инструкциям для образа all-in-one](/ru/clickstack/getting-started/oss) или [Local Mode Only](/ru/clickstack/deployment/local-mode-only), и завершили первоначальное создание пользователя. Либо можно пропустить всю локальную настройку и просто подключиться к нашей хостинговой демоверсии ClickStack [play-clickstack.clickhouse.com](https://play-clickstack.clickhouse.com), в которой используется этот набор данных.**
В этом руководстве используется пример набора данных, размещённый в общедоступной Песочнице ClickHouse по адресу [sql.clickhouse.com](https://sql.clickhouse.com), к которому можно подключиться из локально развернутого ClickStack.
**Не поддерживается в Управляемом ClickStack**
Удалённые базы данных не поддерживаются при использовании Управляемого ClickStack. Поэтому этот набор данных также не поддерживается.
Он содержит примерно 40 часов данных, собранных в версии официального демо OpenTelemetry (OTel) для ClickHouse. Эти данные каждую ночь воспроизводятся заново, а временные метки сдвигаются под текущее временное окно, что позволяет пользователям изучать поведение системы с помощью встроенных в HyperDX логов, трассировок и метрик.
**Различия в данных**
Поскольку набор данных каждый день воспроизводится с полуночи, точные визуализации могут различаться в зависимости от того, когда вы открываете демо.
## Демонстрационный сценарий
В этой демонстрации мы разбираем инцидент, связанный с интернет-магазином, который продает телескопы и аксессуары к ним.
Команда поддержки клиентов сообщила, что у пользователей возникают проблемы с оплатой при оформлении заказа. Проблема была передана команде Site Reliability Engineering (SRE) для расследования.
С помощью HyperDX команда SRE проанализирует журналы, трассировки и метрики, чтобы диагностировать и устранить проблему, а затем изучит данные сеанса, чтобы проверить, соответствуют ли их выводы фактическому поведению пользователей.
## Демо OpenTelemetry
В этом демо используется [форк официального демо OpenTelemetry, поддерживаемый ClickStack](https://github.com/ClickHouse/opentelemetry-demo).
### Архитектура демо
Демо состоит из микросервисов, написанных на разных языках программирования, которые взаимодействуют друг с другом по gRPC и HTTP, а также генератора нагрузки, использующего Locust для имитации пользовательского трафика. Оригинальный исходный код этого демо был изменён, чтобы использовать [инструментирование ClickStack](/ru/clickstack/ingesting-data/sdks).
*Источник: [https://opentelemetry.io/docs/demo/architecture/](https://opentelemetry.io/docs/demo/architecture/)*
Дополнительные сведения о демо можно найти здесь:
* [документация OpenTelemetry](https://opentelemetry.io/docs/demo/)
* [форк, поддерживаемый ClickStack](https://github.com/ClickHouse/opentelemetry-demo)
## Шаги демонстрации
**В этой демонстрации мы настроили сбор телеметрии с помощью [ClickStack SDKs](/ru/clickstack/ingesting-data/sdks), развернули сервисы в Kubernetes и также собрали оттуда метрики и журналы.**
### Подключение к демонстрационному серверу
**Режим только для локальной работы**
Этот шаг можно пропустить, если при развертывании в локальном режиме вы нажали `Connect to Demo Server`. В этом режиме к именам источников добавляется префикс `Demo_`, например `Demo_Logs`
Перейдите в `Team Settings` и нажмите `Edit` у `Local Connection`:
Переименуйте подключение в `Demo` и заполните следующую форму, используя следующие сведения о подключении к демонстрационному серверу:
* `Connection Name`: `Demo`
* `Host`: `https://sql-clickhouse.clickhouse.com`
* `Username`: `otel_demo`
* `Password`: Оставьте пустым
### Измените источники
**Только локальный режим**
Этот шаг можно пропустить, если при развертывании в локальном режиме вы нажали `Connect to Demo Server`. В этом режиме к именам источников добавляется префикс `Demo_`, например `Demo_Logs`
Прокрутите страницу вверх до `Sources` и измените каждый источник — `Logs`, `Traces`, `Metrics` и `Sessions` — так, чтобы он использовал базу данных `otel_v2`.
Возможно, потребуется перезагрузить страницу, чтобы в каждом источнике отображался полный список баз данных.
### Настройте временной диапазон
Настройте время так, чтобы отображались все данные за предыдущий `1 day`, используя селектор времени в правом верхнем углу.
На обзорной столбчатой диаграмме можно заметить небольшую разницу в количестве ошибок: в нескольких соседних столбцах немного увеличится красная часть.
Расположение столбцов будет различаться в зависимости от того, когда вы выполняете запрос к набору данных.
### Отфильтруйте ошибки
Чтобы выделить ошибки, используйте фильтр `SeverityText` и выберите `error`, чтобы отображались только записи с уровнем error.
Теперь ошибки будут заметнее:
### Выявление шаблонов ошибок
С помощью возможности Clustering в HyperDX вы можете автоматически выявлять ошибки и группировать их в осмысленные шаблоны. Это ускоряет анализ при работе с большими объёмами логов и трассировок. Чтобы воспользоваться этой возможностью, выберите `Event Patterns` в меню `Analysis Mode` на левой панели.
Кластеры ошибок показывают проблемы, связанные со сбоями при оплате, включая именованный шаблон `Failed to place order`. Дополнительные кластеры также указывают на проблемы со списанием средств с карт и переполнением кэша.
Обратите внимание, что эти кластеры ошибок, вероятно, относятся к разным сервисам.
### Изучение паттерна ошибки
Нажмите на наиболее очевидный кластер ошибок, который соответствует зарегистрированной проблеме, из-за которой пользователи могут завершать платежи: `Failed to place order`.
Это отобразит список всех случаев этой ошибки, связанных с сервисом `frontend`:
Выберите любую из найденных ошибок. Подробно отобразятся метаданные журналов. Просмотр разделов `Overview` и `Column Values` указывает на проблему со списанием средств с карт из-за кэша:
`failed to charge card: could not charge the card: rpc error: code = Unknown desc = Visa cache full: cannot add new item.`
### Изучите инфраструктуру
Мы выявили ошибку, связанную с кэшем, которая, вероятно, вызывает сбои при оплате. Теперь нужно понять, где именно в нашей микросервисной архитектуре возникает эта проблема.
Учитывая проблему с кэшем, имеет смысл проверить базовую инфраструктуру — возможно, в связанных подах есть проблема с памятью? В ClickStack журналы и метрики объединены и показываются в контексте, что помогает быстрее найти первопричину.
Выберите вкладку `Infrastructure`, чтобы просмотреть метрики, связанные с подами, на которых работает сервис `frontend`, и расширьте временной диапазон до `1d`:
Похоже, проблема не связана с инфраструктурой — за этот период метрики заметно не менялись ни до, ни после ошибки. Закройте вкладку `Infrastructure`.
### Изучение трейса
В ClickStack трейсы также автоматически коррелируются и с журналами, и с метриками. Давайте изучим трейс, связанный с выбранной записью журнала, чтобы определить, какой сервис за это отвечает.
Выберите `Trace`, чтобы визуализировать связанный трейс. Прокрутив открывшееся представление вниз, мы увидим, как HyperDX визуализирует распределённый трейс между микросервисами, связывая спаны в каждом сервисе. Платёж явно задействует несколько микросервисов, в том числе те, которые выполняют checkout и конвертацию валют.
Прокрутив представление до самого низа, мы увидим, что ошибку вызывает сервис `payment`, и затем она распространяется вверх по цепочке вызовов.
### Поиск трейсов
Мы установили, что пользователи не могут завершить покупки из-за проблемы с кэшем в сервисе payment. Давайте подробнее изучим трейсы этого сервиса, чтобы лучше понять первопричину.
Переключитесь в основное представление Search, выбрав `Search`. Смените источник данных на `Traces` и выберите представление `Results table`. **Убедитесь, что временной диапазон по-прежнему установлен на последний день.**
В этом представлении показаны все трейсы за последний день. Мы знаем, что проблема возникает в нашем сервисе payment, поэтому примените фильтр `payment` к `ServiceName`.
Если применить к трейсам кластеризацию событий, выбрав `Event Patterns`, мы сразу увидим проблему с кэшем в сервисе `payment`.
### Изучите инфраструктуру трейса
Переключитесь в представление результатов, нажав `Results table`. Отфильтруйте ошибки с помощью фильтра `StatusCode` и значения `Error`.
Выберите ошибку `Error: Visa cache full: cannot add new item.`, перейдите на вкладку `Infrastructure` и увеличьте временной диапазон до `1d`.
Сопоставив трейсы с метриками, мы видим, что у сервиса `payment` выросло потребление памяти и CPU, а затем показатели упали до `0` (это можно связать с перезапуском пода) — это указывает на то, что проблема с кэшем привела к проблемам с ресурсами. Можно ожидать, что это повлияло на время завершения платежей.
### Event Deltas для более быстрого поиска причины
Event Deltas помогают выявлять аномалии, связывая изменения производительности или частоты ошибок с конкретными подмножествами данных, что позволяет быстрее определить первопричину.
Хотя мы знаем, что у сервиса `payment` есть проблема с кэшем, из-за которой растёт потребление ресурсов, первопричина всё ещё не установлена.
Вернитесь к представлению таблицы результатов и выберите период времени, содержащий ошибки, чтобы ограничить объём данных. Обязательно захватите несколько часов до появления ошибок и, если возможно, после них (проблема может всё ещё сохраняться):
Удалите фильтр ошибок и выберите `Event Deltas` в левом меню `Analysis Mode`.
На верхней панели показано распределение длительностей, где цвет указывает на плотность событий (количество спанов). Обычно имеет смысл исследовать подмножество событий вне основной концентрации.
Если выбрать события с длительностью больше `1ms` и применить фильтр `Filter by selection`, можно проанализировать различия между "обычными" событиями и группой высокой плотности спанов с длительностью около 0 мс:
При анализе этого подмножества данных видно, что спаны на "фоне" вне выделения — это в основном транзакции Visa, связанные с ответами длительностью 0 мс из-за ошибок кэша.
### Использование графиков для дополнительного контекста
В ClickStack можно строить графики по любым числовым значениям из журналов, трасс или метрик, чтобы получить больше контекста.
Мы установили следующее:
* Проблема связана с сервисом payment
* Кэш заполнен
* Это привело к росту потребления ресурсов
* Из-за проблемы платежи Visa не завершались или, по крайней мере, выполнялись очень долго.
Выберите `Chart Explorer` в левом меню. Заполните следующие поля, чтобы построить график времени, необходимого для завершения платежей, по типу графика:
* `Data Source`: `Traces`
* `Metric`: `Maximum`
* `SQL Column`: `Duration`
* `Where`: `ServiceName: payment`
* `Timespan`: `Last 1 day`
Нажатие `▶️` покажет, как со временем ухудшалась производительность обработки платежей.
Если задать `Group By` как `SpanAttributes['app.payment.card_type']` (просто введите `card` для автодополнения), можно увидеть, как производительность сервиса для транзакций Visa ухудшалась по сравнению с Mastercard:
Обратите внимание: после возникновения ошибки ответы возвращаются за `0s`.
### Дополнительный контекст при изучении метрик
Наконец, давайте построим график размера кэша как метрики, чтобы посмотреть, как он менялся со временем, и тем самым получить больше контекста.
Заполните следующие значения:
* `Data Source`: `Metrics`
* `Metric`: `Maximum`
* `SQL Column`: `visa_validation_cache.size (gauge)` (для автодополнения просто введите `cache`)
* `Where`: `ServiceName: payment`
* `Group By`: ``
Мы видим, как размер кэша увеличивался в течение 4–5 часов (вероятно, после выката новой версии), прежде чем достиг максимального значения `100,000`. По `Sample Matched Events` видно, что наши ошибки коррелируют с тем моментом, когда кэш достигает этого предела, после чего его размер фиксируется как `0`, а время ответа тоже становится `0s`.
Подводя итог, изучив логи, трейсы и, наконец, метрики, мы пришли к следующим выводам:
* Проблема связана с сервисом payment
* Изменение в поведении сервиса, вероятно вызванное развертыванием, привело к медленному росту кэша visa в течение 4–5 часов — до максимального значения `100,000`.
* Это привело к росту потребления ресурсов по мере увеличения кэша — вероятно, из-за неудачной реализации
* По мере роста кэша производительность платежей Visa ухудшалась
* Достигнув максимального размера, кэш начал отклонять платежи и сообщать о размере `0`.
### Использование сеансов
Сеансы позволяют воспроизводить действия пользователя, наглядно показывая, как именно произошла ошибка с его точки зрения. Хотя их обычно не используют для поиска первопричины, они полезны для подтверждения проблем, о которых сообщает служба поддержки, и могут служить отправной точкой для более глубокого расследования.
В HyperDX сеансы связаны с трассировками и журналами, что дает полное представление о первопричине.
Например, если команда поддержки передала адрес электронной почты пользователя, столкнувшегося с проблемой при оплате, `Ronny.Windler@gmail.com`, часто эффективнее начать с его сеанса, а не сразу искать в журналах или трассировках.
Перейдите на вкладку `Client Sessions` в левом меню, предварительно убедившись, что в качестве источника данных выбрано `Sessions`, а период времени установлен на `Last 1 day`:
Выполните поиск по `SpanAttributes.userEmail: Ronny.Windler`, чтобы найти сеанс нашего клиента. При выборе сеанса слева отобразятся события браузера и связанные спаны для этого сеанса, а справа — заново воспроизведенное поведение пользователя в браузере:
### Повторное воспроизведение сеансов
Сеансы можно воспроизводить, нажимая кнопку ▶️. Переключение между `Highlighted` и `All Events` позволяет менять степень детализации спанов: в первом режиме выделяются ключевые события и ошибки.
Если прокрутить список спанов до конца, можно увидеть ошибку `500`, связанную с `/api/checkout`. Нажатие кнопки ▶️ для этого конкретного спана переносит воспроизведение к этой точке сеанса, позволяя нам увидеть, что происходило у клиента: похоже, оплата просто не работает, и при этом никакая ошибка не отображается.
Выбрав этот спан, мы можем убедиться, что причиной была внутренняя ошибка. Перейдя на вкладку `Trace` и прокрутив связанные спаны, мы можем подтвердить, что клиент действительно пострадал из-за нашей проблемы с кэшем.
В этом демо разбирается реальный инцидент со сбоями платежей в приложении интернет-магазина и показывается, как ClickStack помогает находить первопричины с помощью единых логов, трассировок, метрик и воспроизведения сеансов — изучите наши [другие руководства по быстрому старту](/ru/clickstack/example-datasets), чтобы глубже познакомиться с конкретными возможностями.