Обзор системных таблиц

Системные таблицы предоставляют информацию о:

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

Системные таблицы:

Находятся в базе данных system.
Доступны только для чтения данных.
Не могут быть удалены или изменены, но могут быть отсоединены.

Большинство системных таблиц хранят свои данные в оперативной памяти. Сервер ClickHouse создает такие системные таблицы при запуске.

В отличие от других системных таблиц, журналы системных таблиц metric_log, query_log, query_thread_log, trace_log, part_log, crash_log, text_log и backup_log обслуживаются движком таблиц MergeTree и, по умолчанию, хранят свои данные в файловой системе. Если вы удалите таблицу из файловой системы, сервер ClickHouse снова создаст пустую таблицу при следующей записи данных. Если схема системной таблицы изменилась в новой версии, ClickHouse переименует текущую таблицу и создаст новую.

Журналы системных таблиц могут быть настроены путем создания файла конфигурации с таким же именем, как и таблица, в /etc/clickhouse-server/config.d/, или путем настройки соответствующих элементов в /etc/clickhouse-server/config.xml. Настраиваемые элементы:

database: база данных, к которой относится таблица журнала системы. Эта опция устарела. Все журналы системных таблиц находятся в базе данных system.
table: таблица для вставки данных.
partition_by: укажите выражение PARTITION BY.
ttl: укажите выражение TTL таблицы.
flush_interval_milliseconds: интервал очистки данных на диск.
engine: укажите полное выражение движка (начиная с ENGINE =) с параметрами. Эта опция конфликтует с partition_by и ttl. Если указаны вместе, сервер выдаст исключение и завершит работу.

Пример:

По умолчанию рост таблицы не ограничен. Для контроля размера таблицы можно использовать TTL настройки для удаления устаревших записей журнала. Также можно использовать функцию партиционирования таблиц движка MergeTree.

Источники системных метрик

Для сбора системных метрик сервер ClickHouse использует:

Возможность CAP_NET_ADMIN.
procfs (только в Linux).

procfs

Если сервер ClickHouse не имеет возможности CAP_NET_ADMIN, он пытается вернуться к ProcfsMetricsProvider. ProcfsMetricsProvider позволяет собирать системные метрики по запросам (для CPU и I/O).

Если procfs поддерживается и включен в системе, сервер ClickHouse собирает следующие метрики:

OSCPUVirtualTimeMicroseconds
OSCPUWaitMicroseconds
OSIOWaitMicroseconds
OSReadChars
OSWriteChars
OSReadBytes
OSWriteBytes

примечание

OSIOWaitMicroseconds по умолчанию отключен в ядрах Linux начиная с 5.14.x. Вы можете включить его, использовав sudo sysctl kernel.task_delayacct=1 или создав файл .conf в /etc/sysctl.d/ с содержимым kernel.task_delayacct = 1

Системные таблицы в ClickHouse Cloud

В ClickHouse Cloud системные таблицы предоставляют критически важную информацию о состоянии и производительности сервиса, так же как и в самоуправляемых развертываниях. Некоторые системные таблицы работают на уровне всего кластера, особенно те, которые извлекают данные из узлов Keeper, которые управляют распределенными метаданными. Эти таблицы отражают общее состояние кластера и должны быть согласованными при запросе на индивидуальных узлах. Например, таблицы parts должны быть согласованными независимо от узла, с которого они запрашиваются:

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

В общем, следующие правила могут быть применены для определения, является ли системная таблица специфичной для узла:

Системные таблицы с суффиксом _log.
Системные таблицы, которые отображают метрики, например, metrics, asynchronous_metrics, events.
Системные таблицы, которые отображают текущие процессы, например, processes, merges.

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

Например, рассмотрим таблицы system.query_log, которые содержат строку для каждого запроса, выполненного узлом:

Запрос нескольких версий

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

Не полагайтесь на числовой суффикс для упорядочивания

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

Важно отметить, что эти таблицы все еще локальны для каждого узла.

Запрос через узлы

Чтобы всесторонне просмотреть весь кластер, пользователи могут использовать функцию clusterAllReplicas в сочетании с функцией merge. Функция clusterAllReplicas позволяет запрашивать системные таблицы по всем репликам в кластере "default", объединяя специфичные для узла данные в едином результате. В сочетании с функцией merge это можно использовать для нацеливания всех системных данных для определенной таблицы в кластере.

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

примечание

ClickHouse Cloud предоставляет кластеры с несколькими репликами для обеспечения избыточности и аварийного восстановления. Это позволяет использовать такие функции, как динамическое автоматическое масштабирование и обновления без простоев. В определенный момент времени новые узлы могут быть в процессе добавления в кластер или удаления из кластера. Чтобы пропустить эти узлы, добавьте SETTINGS skip_unavailable_shards = 1 к запросам, использующим clusterAllReplicas, как показано ниже.

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

Запрос через узлы и версии

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