Обзор системных таблиц
Обзор системных таблиц
Системные таблицы предоставляют информацию о:
- состояниях серверов, процессах и среде.
- внутренних процессах сервера.
- параметрах, использованных при сборке бинарного файла 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. Этоtypical для таких данных, как журналы и метрики. Эта устойчивость гарантирует, что исторические данные остаются доступными для анализа. Однако эти специфические для узла таблицы по своей природе уникальны для каждого узла.
Чтобы всесторонне просмотреть весь кластер, пользователи могут использовать функцию clusterAllReplicas
. Эта функция позволяет выполнять запросы к системным таблицам на всех репликах в кластере "default", консолидируя специфические для узла данные в единый результат. Этот подход особенно ценен для мониторинга и отладки операций на уровне кластера, обеспечивая пользователям возможность эффективно анализировать состояние и производительность своего развертывания ClickHouse Cloud.
ClickHouse Cloud обеспечивает кластеры с несколькими репликами для избыточности и аварийного восстановления. Это позволяет использовать такие функции, как динамическое автомасштабирование и обновления без простоя. В определенный момент времени новые узлы могут добавляться в кластер или удаляться из него. Чтобы пропустить эти узлы, добавьте SETTINGS skip_unavailable_shards = 1
к запросам с использованием clusterAllReplicas
, как показано ниже.
Например, рассмотрите разницу при запросе таблицы query_log
- часто необходимой для анализа.
В общем, следующие правила могут быть применены при определении, является ли системная таблица специфичной для узла:
- Системные таблицы с суффиксом
_log
. - Системные таблицы, которые отображают метрики, например,
metrics
,asynchronous_metrics
,events
. - Системные таблицы, которые отображают текущие процессы, например,
processes
,merges
.