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

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

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

Не поддерживается с HyperDX в ClickHouse Cloud

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

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

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

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

Сценарий демо

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

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

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

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

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

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

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

Кредит: https://opentelemetry.io/docs/demo/architecture/

Дополнительные детали о демо можно найти в:

• документации OpenTelemetry
• форк, поддерживаемый ClickStack

Этапы демо

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

Подключение к демо-серверу

Только режим локальной работы

Этот шаг можно пропустить, если вы нажали Подключиться к демо-серверу при развертывании в локальном режиме. Если вы используете этот режим, источники будут иметь префикс Demo_, например, Demo_Logs

Перейдите в Настройки команды и нажмите Редактировать для Локального подключения:

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

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

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

Только режим локальной работы

Этот шаг можно пропустить, если вы нажали Подключиться к демо-серверу при развертывании в локальном режиме. Если вы используете этот режим, источники будут иметь префикс Demo_, например, Demo_Logs

Прокрутите вверх до Источников и измените каждый из источников - Логи, Трассировки, Метрики и Сессии - чтобы использовать базу данных otel_v2.

примечание

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

Настройка временного интервала

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

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

примечание

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

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

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

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

Определение паттернов ошибок

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

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

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

Исследование паттерна ошибки

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

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

Выберите любую из полученных ошибок. Метаданные логов будут показаны в деталях. Проходя через Обзор и Значения столбцов, можно заметить проблему с зарядкой карт из-за кэша:

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

Исследование инфраструктуры

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

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

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

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

Исследование трассировки

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

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

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

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

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

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

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

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

Исследование инфраструктуры для трасировки

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

Выберите ошибку Error: Кэш Visa переполнен: не удается добавить новый элемент., переключитесь на вкладку Инфраструктура и увеличьте временной диапазон до 1d.

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

Дельты событий для более быстрого разрешения

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

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

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

Удалите фильтр ошибок и выберите Дельты событий из левого меню Режим анализа.

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

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

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

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

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

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

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

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

• Источник данных: Трассировки
• Метрика: Максимум
• SQL Колонка: Продолжительность
• Где: ServiceName: payment
• Временной диапазон: За последние 1 день

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

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

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

Исследование метрик для большего контекста

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

Заполните следующие значения:

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

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

В итоге, исследуя логи, трассировки и, наконец, метрики, мы пришли к заключению:

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

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

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

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

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

Перейдите на вкладку Клиентские сессии в левом меню, убедившись, что источник данных установлен на Сессии, а временной период выбран на За последние 1 день:

Поиск по SpanAttributes.userEmail: Braulio позволит найти сессию нашего клиента. Выбор сессии покажет события браузера и связанные промежутки для сессии клиента слева, с повторным отображением пользовательского опыта браузера справа:

Воспроизведение сессий

Сессии могут быть воспроизведены, нажав кнопку ▶️. Переключение между Выделенными и Все события позволяет варьировать уровень детализации промежутков, при этом первое выделяет ключевые события и ошибки.

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

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

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