> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Удалённый демо-набор данных
> Начало работы с ClickStack и удалённым демо-набором данных
export const Image = ({img, alt, size = "lg"}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
return ;
};
**В этом руководстве предполагается, что вы развернули ClickStack с открытым исходным кодом, следуя [инструкциям для образа all-in-one](/docs/ru/clickstack/getting-started/oss) или [Local Mode Only](/docs/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](/docs/ru/clickstack/ingesting-data/sdks/index).
*Источник: [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](/docs/ru/clickstack/ingesting-data/sdks/index), развернули сервисы в 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`: оставьте пустым
**Только для локального режима**
Этот шаг можно пропустить, если при развертывании в Local Mode вы нажали `Connect to Demo Server`. В этом режиме к источникам будет добавляться префикс `Demo_`, например `Demo_Logs`
Прокрутите вверх до `Sources` и измените каждый из источников — `Logs`, `Traces`, `Metrics` и `Sessions` — так, чтобы они использовали базу данных `otel_v2`.
Возможно, потребуется перезагрузить страницу, чтобы в каждом источнике отображался полный список баз данных.
Настройте временной диапазон так, чтобы отображались все данные за предыдущий `1 day`, используя селектор времени в правом верхнем углу.
Вы можете заметить небольшое изменение в количестве ошибок на столбчатой диаграмме в разделе Overview: в нескольких идущих подряд столбцах красная часть немного увеличится.
Расположение столбцов будет различаться в зависимости от того, когда вы выполняете запрос к набору данных.
Чтобы выделить ошибки, используйте фильтр `SeverityText` и выберите `error`, чтобы отображались только записи уровня error.
Ошибка должна стать более заметной:
С помощью возможности Clustering в HyperDX вы можете автоматически выявлять ошибки и группировать их в осмысленные шаблоны. Это ускоряет анализ при работе с большими объёмами логов и трейсов. Чтобы использовать эту возможность, выберите `Шаблоны событий` в меню `Режим анализа` на левой панели.
Кластеры ошибок показывают проблемы, связанные с неуспешными платежами, в том числе шаблон с названием `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 визуализирует распределённый трейс между микросервисами, связывая спаны в каждом сервисе. Платёжный процесс явно затрагивает несколько микросервисов, включая те, которые отвечают за оформление заказа и конвертацию валют.
Прокрутив представление до самого низа, мы увидим, что ошибку вызывает сервис `payment`, после чего она распространяется обратно вверх по цепочке вызовов.
Мы установили, что пользователи не могут завершить покупки из-за проблемы с кэшем в сервисе payment. Давайте подробнее изучим трассировки этого сервиса, чтобы понять первопричину.
Переключитесь в основное представление Search, выбрав `Search`. Смените источник данных на `Traces` и выберите представление `Results table`. **Убедитесь, что временной диапазон по-прежнему охватывает последний день.**
В этом представлении показаны все трассировки за последний день. Мы знаем, что проблема возникает в нашем сервисе payment, поэтому примените к `ServiceName` фильтр `payment`.
Если применить к трассировкам кластеризацию событий, выбрав `Шаблоны событий`, мы сразу увидим проблему с кэшем в сервисе `payment`.
Перейдите в представление результатов, нажав `Results table`. Отфильтруйте записи с ошибками с помощью фильтра `StatusCode` и значения `Error`.
Выберите ошибку `Error: Visa cache full: cannot add new item.`, перейдите на вкладку `Infrastructure` и расширьте временной диапазон до `1d`.
Сопоставив трейсы с метриками, видно, что потребление памяти и CPU сервисом `payment` выросло, а затем упало до `0` (вероятно, из-за перезапуска пода), что указывает на проблемы с ресурсами, вызванные переполнением cache. Можно ожидать, что это повлияло на время обработки платежей.
Event Deltas помогают выявлять аномалии, связывая изменения производительности или уровня ошибок с конкретными подмножествами данных, что позволяет быстрее находить первопричину.
Хотя мы знаем, что у сервиса `payment` есть проблема с кэшем, из-за которой растёт потребление ресурсов, мы ещё не до конца выявили первопричину.
Вернитесь к представлению таблицы результатов и выберите период времени, в который есть ошибки, чтобы ограничить объём данных. Обязательно захватите несколько часов до появления ошибок и, если возможно, после них (проблема может всё ещё сохраняться):
Удалите фильтр ошибок и выберите `Event Deltas` в левом меню `Analysis Mode`.
Верхняя панель показывает распределение по длительности, где цвета обозначают плотность событий (количество спанов). Обычно стоит исследовать события, находящиеся вне основной концентрации.
Если выбрать события с длительностью больше `1ms` и применить фильтр `Filter by selection`, можно проанализировать различия между "обычными" событиями и группой высокой плотности спанов с длительностью около \~0ms:
После анализа этого подмножества данных видно, что спаны "background" вне выделения — это в основном транзакции visa, связанные с ответами 0ms из-за ошибок кэша.
В 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 сеансы связаны с трассировками и журналами, что дает полное представление о первопричине.
Например, если служба поддержки передает email пользователя, столкнувшегося с проблемой при оплате, `Ronny.Windler@gmail.com`, — часто эффективнее начать с его сеанса, чем сразу искать по журналам или трассировкам.
Перейдите на вкладку `Client Sessions` в левом меню, предварительно убедившись, что в качестве источника данных выбрано `Sessions`, а временной период установлен на `Last 1 day`:
Найдите `SpanAttributes.userEmail: Ronny.Windler`, чтобы найти сеанс нашего клиента. При выборе сеанса слева отобразятся события браузера и связанные спаны этого сеанса, а справа — воспроизведенная картина действий пользователя в браузере:
Сеансы можно воспроизводить, нажимая кнопку ▶️. Переключение между `Highlighted` и `All Events` позволяет менять уровень детализации спанов: в первом режиме выделяются ключевые события и ошибки.
Если прокрутить список спанов до конца, можно увидеть ошибку `500`, связанную с `/api/checkout`. Нажатие кнопки ▶️ для этого конкретного спана перемещает воспроизведение к этой точке сеанса, позволяя нам подтвердить впечатления клиента: похоже, что оплата просто не работает, и при этом никакая ошибка не отображается.
Выбрав этот спан, мы можем подтвердить, что причиной была внутренняя ошибка. Перейдя на вкладку `Trace` и просмотрев связанные спаны, мы можем убедиться, что клиент действительно столкнулся с нашей проблемой кэша.