Передача контекста трассировки в ClickHouse
ClickHouse принимает HTTP-заголовки контекста трассировки, как описано в рекомендации W3C. Он также принимает контекст трассировки через собственный протокол, который используется для обмена данными между серверами ClickHouse или между клиентом и сервером. Для ручного тестирования заголовки контекста трассировки, соответствующие рекомендации Trace Context, можно передать вclickhouse-client с помощью флагов --opentelemetry-traceparent и --opentelemetry-tracestate.
Если родительский контекст трассировки не передан или переданный контекст трассировки не соответствует указанному выше стандарту W3C, ClickHouse может начать новую трассировку с вероятностью, задаваемой настройкой opentelemetry_start_trace_probability.
Передача контекста трассировки
Контекст трассировки передаётся в сервисы ниже по цепочке в следующих случаях:- Запросы к удалённым серверам ClickHouse, например при использовании движка таблицы Distributed.
- Табличная функция url. Информация о контексте трассировки отправляется в заголовках HTTP.
Спаны распределённых запросов
Для распределённогоSELECT каждое чтение с удалённого сегмента покрывается спаном RemoteQueryExecutor::execute. Такие спаны содержат атрибуты, идентифицирующие query fragment:
clickhouse.clusterиclickhouse.shard_num— cluster и сегмент, с которого читает исполнитель;clickhouse.query_idиclickhouse.initial_query_id— query ids с точки зрения initiator;clickhouse.target_host— адреса установленных соединений.
status_code такого спана показывает, чем завершился fragment:
OK— сегмент вернул полный результат.ERROR— fragment завершился с ошибкой: сегмент вернул exception, initiator не смог прочитать данные либо не удалось отменить работу сегмента.UNSET— ни успех, ни ошибка. Такие спаны содержат атрибут, дающий дополнительный контекст.
INSERT в Distributed table порождают аналогичные спаны в DistributedSink с теми же ключами атрибутов clickhouse.cluster и clickhouse.shard_num.
Трассировка запросов ClickHouse Keeper
ClickHouse поддерживает трассировку OpenTelemetry для запросов ClickHouse Keeper (сервиса координации, совместимого с ZooKeeper). Эта возможность обеспечивает подробную видимость всего жизненного цикла операций Keeper — от отправки клиентского запроса до его обработки на стороне сервера.Включение трассировки запросов Keeper
Чтобы включить трассировку запросов Keeper, настройте следующие параметры в конфигурации клиента ZooKeeper/Keeper:Типы спанов Keeper
Когда трассировка включена, ClickHouse создает спаны как для клиентских, так и для серверных операций Keeper: Клиентские спаны:zookeeper.create— Создание нового узлаzookeeper.get— Получение данных узлаzookeeper.set— Запись данных узлаzookeeper.remove— Удаление узлаzookeeper.list— Получение списка дочерних узловzookeeper.exists— Проверка существования узлаzookeeper.multi— Атомарное выполнение нескольких операцийzookeeper.client.requests_queue— Время ожидания запросов в очереди перед отправкой
keeper.receive_request— Получение и разбор запроса от клиентаkeeper.dispatcher.requests_queue— Ожидание запроса в очереди диспетчераkeeper.write.pre_commit— Предварительная обработка запросов на запись перед фиксацией в Raftkeeper.write.commit— Обработка запросов на запись после фиксации в Raftkeeper.read.wait_for_write— Ожидание запросов на чтение в очереди до завершения обработки текущего батча запросовkeeper.read.process— Обработка запросов на чтениеkeeper.dispatcher.responses_queue— Ожидание ответа в очереди диспетчераkeeper.send_response— Отправка ответа клиенту
Сэмплирование и производительность
Чтобы снизить накладные расходы на трассировку, Keeper использует динамическое сэмплирование. Частота сэмплирования автоматически регулируется в диапазоне от 1/10,000 до 1/10 в зависимости от размера запроса. Для мониторинга производительности значения длительности всех запросов (как сэмплированных, так и несэмплированных) записываются в метрики-гистограммы.Трассировка самого ClickHouse
ClickHouse создаетtrace spans для каждого запроса и некоторых этапов его выполнения, таких как планирование запроса или распределенные запросы.
Чтобы эта информация была полезной, ее нужно экспортировать в систему мониторинга с поддержкой OpenTelemetry, например Jaeger или Prometheus. ClickHouse не зависит от какой-либо конкретной системы мониторинга и предоставляет данные трассировки только через системную таблицу. Информация о спанах трассировки OpenTelemetry, требуемая стандартом, хранится в таблице system.opentelemetry_span_log.
Эта таблица должна быть включена в конфигурации сервера, см. элемент opentelemetry_span_log в файле конфигурации по умолчанию config.xml. По умолчанию она включена.
Теги или атрибуты сохраняются в виде двух параллельных массивов, содержащих ключи и значения. Используйте ARRAY JOIN, чтобы работать с ними.
Журналирование настроек запроса
Настройка log_query_settings позволяет журналировать изменения настроек запроса во время выполнения запроса. Когда она включена, любые изменения, внесенные в настройки запроса, будут записаны в журнал спана OpenTelemetry. Эта возможность особенно полезна в продакшн-средах для отслеживания изменений конфигурации, которые могут повлиять на производительность запросов.Интеграция с системами мониторинга
На данный момент не существует готового инструмента, который мог бы экспортировать данные трассировки из ClickHouse в систему мониторинга. Для тестирования можно настроить экспорт с помощью materialized view с движком URL поверх таблицы system.opentelemetry_span_log, которая будет отправлять поступающие записи журнала на HTTP-конечную точку коллектора трассировки. Например, чтобы отправлять минимальный набор данных спана в экземпляр Zipkin, работающий по адресуhttp://localhost:9411, в формате Zipkin v2 JSON: