Vue d’ensemble des tables système

Présentation des tables système et de leur utilité.

​

Vue d’ensemble des tables système

Les tables système fournissent des informations sur :

• Les états, les processus et l’environnement du serveur.
• Les processus internes du serveur.
• Les options utilisées lors de la compilation du binaire ClickHouse.

Tables système :

• Situées dans la base de données system.
• Disponibles en lecture seule.
• Ne peuvent pas être supprimées ni modifiées, mais peuvent être détachées.

La plupart des tables système stockent leurs données en RAM. Un serveur ClickHouse crée ces tables système au démarrage.

Contrairement aux autres tables système, les tables de journaux système metric_log, query_log, query_thread_log, trace_log, part_log, crash_log, text_log et backup_log utilisent le moteur de table MergeTree et stockent leurs données dans un système de fichiers par défaut. Si vous supprimez une table du système de fichiers, le serveur ClickHouse en recrée une vide lors de la prochaine écriture de données. Si le schéma d’une table système a changé dans une nouvelle version, ClickHouse renomme la table actuelle et en crée une nouvelle.

Les tables de journaux système peuvent être personnalisées en créant un fichier de configuration portant le même nom que la table dans /etc/clickhouse-server/config.d/, ou en définissant les éléments correspondants dans /etc/clickhouse-server/config.xml. Les éléments personnalisables sont :

• database : base de données à laquelle appartient la table de journaux système. Cette option est désormais obsolète. Toutes les tables de journaux système se trouvent dans la base de données system.
• table : table dans laquelle insérer les données.
• partition_by : spécifie l’expression PARTITION BY.
• ttl : spécifie l’expression TTL de la table.
• flush_interval_milliseconds : intervalle de vidage des données sur disque.
• engine : fournit l’expression complète du moteur (commençant par ENGINE = ) avec ses paramètres. Cette option entre en conflit avec partition_by et ttl. S’ils sont définis ensemble, le serveur renverra une exception et s’arrêtera.

Un exemple :

<clickhouse>
    <query_log>
        <database>system</database>
        <table>query_log</table>
        <partition_by>toYYYYMM(event_date)</partition_by>
        <ttl>event_date + INTERVAL 30 DAY DELETE</ttl>
        <!--
        <engine>ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, event_time) SETTINGS index_granularity = 1024</engine>
        -->
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </query_log>
</clickhouse>

Par défaut, la croissance d’une table est illimitée. Pour contrôler la taille d’une table, vous pouvez utiliser les paramètres TTL afin de supprimer les anciennes entrées de journal. Vous pouvez également utiliser le partitionnement des tables utilisant le moteur MergeTree.

​

Sources des métriques système

Pour collecter les métriques système, le serveur ClickHouse utilise :

• la capacité CAP_NET_ADMIN ;
• procfs (uniquement sous Linux).

procfs

Si le serveur ClickHouse ne dispose pas de la capacité CAP_NET_ADMIN, il tente de se rabattre sur ProcfsMetricsProvider. ProcfsMetricsProvider permet de collecter des métriques système par requête (pour le CPU et les E/S).

Si procfs est pris en charge et activé sur le système, le serveur ClickHouse collecte les métriques suivantes :

• OSCPUVirtualTimeMicroseconds
• OSCPUWaitMicroseconds
• OSIOWaitMicroseconds
• OSReadChars
• OSWriteChars
• OSReadBytes
• OSWriteBytes

OSIOWaitMicroseconds est désactivé par défaut dans les noyaux Linux à partir de la version 5.14.x. Vous pouvez l’activer avec sudo sysctl kernel.task_delayacct=1 ou en créant un fichier .conf dans /etc/sysctl.d/ contenant kernel.task_delayacct = 1

​

Tables système dans ClickHouse Cloud

Dans ClickHouse Cloud, les tables système fournissent des informations essentielles sur l’état et les performances du service, tout comme dans les déploiements autogérés. Certaines tables système s’appliquent à l’ensemble du cluster, en particulier celles qui tirent leurs données des nœuds Keeper, lesquels gèrent les métadonnées distribuées. Ces tables reflètent l’état global du cluster et doivent être cohérentes lorsqu’elles sont interrogées depuis des nœuds individuels. Par exemple, les parts doivent être cohérentes, quel que soit le nœud depuis lequel elles sont interrogées :

SELECT hostname(), count()
FROM system.parts
WHERE `table` = 'pypi'

┌─hostname()────────────────────┬─count()─┐
│ c-ecru-qn-34-server-vccsrty-0 │      26 │
└───────────────────────────────┴─────────┘

1 row in set. Elapsed: 0.005 sec.

SELECT
 hostname(),
    count()
FROM system.parts
WHERE `table` = 'pypi'

┌─hostname()────────────────────┬─count()─┐
│ c-ecru-qn-34-server-w59bfco-0 │      26 │
└───────────────────────────────┴─────────┘

1 row in set. Elapsed: 0.004 sec.

À l’inverse, d’autres tables système sont spécifiques à un nœud, par exemple parce qu’elles résident en mémoire ou qu’elles persistent leurs données à l’aide du moteur de table MergeTree. C’est généralement le cas de données telles que les logs et les métriques. Cette persistance garantit que les données historiques restent disponibles pour l’analyse. Cependant, ces tables spécifiques à un nœud sont, par nature, propres à chaque nœud.

De manière générale, les règles suivantes peuvent être appliquées pour déterminer si une table système est spécifique à un nœud :

• Les tables système avec un suffixe _log.
• Les tables système qui exposent des métriques, par exemple metrics, asynchronous_metrics, events.
• Les tables système qui exposent des processus en cours, par exemple processes, merges.

En outre, de nouvelles versions de tables système peuvent être créées à la suite de mises à niveau ou de modifications de leur schéma. Ces versions sont nommées à l’aide d’un suffixe numérique.

Par exemple, prenons les tables system.query_log, qui contiennent une ligne pour chaque requête exécutée par le nœud :

SHOW TABLES FROM system LIKE 'query_log%'

┌─name─────────┐
│ query_log    │
│ query_log_1  │
│ query_log_10 │
│ query_log_2  │
│ query_log_3  │
│ query_log_4  │
│ query_log_5  │
│ query_log_6  │
│ query_log_7  │
│ query_log_8  │
│ query_log_9  │
└──────────────┘

11 rows in set. Elapsed: 0.004 sec.

​

Interroger plusieurs versions

Nous pouvons interroger l’ensemble de ces tables à l’aide de la fonction merge. Par exemple, la requête ci-dessous identifie la requête la plus récente adressée au nœud cible dans chaque table query_log :

SELECT
    _table,
    max(event_time) AS most_recent
FROM merge('system', '^query_log')
GROUP BY _table
ORDER BY most_recent DESC

┌─_table───────┬─────────most_recent─┐
│ query_log    │ 2025-04-13 10:59:29 │
│ query_log_1  │ 2025-04-09 12:34:46 │
│ query_log_2  │ 2025-04-09 12:33:45 │
│ query_log_3  │ 2025-04-07 17:10:34 │
│ query_log_5  │ 2025-03-24 09:39:39 │
│ query_log_4  │ 2025-03-24 09:38:58 │
│ query_log_6  │ 2025-03-19 16:07:41 │
│ query_log_7  │ 2025-03-18 17:01:07 │
│ query_log_8  │ 2025-03-18 14:36:07 │
│ query_log_10 │ 2025-03-18 14:01:33 │
│ query_log_9  │ 2025-03-18 14:01:32 │
└──────────────┴─────────────────────┘

11 rows in set. Elapsed: 0.373 sec. Processed 6.44 million rows, 25.77 MB (17.29 million rows/s., 69.17 MB/s.)
Peak memory usage: 28.45 MiB.

Ne vous fiez pas au suffixe numérique pour déterminer l’ordre

Bien que le suffixe numérique des tables puisse laisser penser qu’il indique l’ordre des données, il ne faut jamais s’y fier. C’est pourquoi vous devez toujours utiliser la fonction de table merge, associée à un filtre sur la date, lorsque vous ciblez des plages de dates spécifiques.

Il est important de noter que ces tables restent locales à chaque nœud.

​

Interroger l’ensemble des nœuds

Pour obtenir une vue complète du cluster, les utilisateurs peuvent exploiter la fonction clusterAllReplicas en combinaison avec la fonction merge. La fonction clusterAllReplicas permet d’interroger les tables système sur toutes les répliques du cluster “default”, en regroupant les données propres à chaque nœud dans un résultat unifié. Combinée à la fonction merge, elle permet de cibler l’ensemble des données système d’une table donnée dans un cluster.

Cette approche est particulièrement utile pour la surveillance et le débogage des opérations à l’échelle du cluster, afin d’analyser efficacement l’état de santé et les performances de leur déploiement ClickHouse Cloud.

ClickHouse Cloud propose des clusters avec plusieurs répliques pour la redondance et le basculement. Cela permet des fonctionnalités telles que l’autoscaling dynamique et les mises à niveau sans interruption de service. À un instant donné, de nouveaux nœuds peuvent être en cours d’ajout au cluster ou de suppression du cluster. Pour ignorer ces nœuds, ajoutez SETTINGS skip_unavailable_shards = 1 aux requêtes utilisant clusterAllReplicas, comme indiqué ci-dessous.

Par exemple, comparez la différence lors de l’interrogation de la table query_log, souvent essentielle à l’analyse.

SELECT
    hostname() AS host,
    count()
FROM system.query_log
WHERE (event_time >= '2025-04-01 00:00:00') AND (event_time <= '2025-04-12 00:00:00')
GROUP BY host

┌─host──────────────────────────┬─count()─┐
│ c-ecru-qn-34-server-s5bnysl-0 │  650543 │
└───────────────────────────────┴─────────┘

1 row in set. Elapsed: 0.010 sec. Processed 17.87 thousand rows, 71.51 KB (1.75 million rows/s., 7.01 MB/s.)

SELECT
    hostname() AS host,
    count()
FROM clusterAllReplicas('default', system.query_log)
WHERE (event_time >= '2025-04-01 00:00:00') AND (event_time <= '2025-04-12 00:00:00')
GROUP BY host SETTINGS skip_unavailable_shards = 1

┌─host──────────────────────────┬─count()─┐
│ c-ecru-qn-34-server-s5bnysl-0 │  650543 │
│ c-ecru-qn-34-server-6em4y4t-0 │  656029 │
│ c-ecru-qn-34-server-iejrkg0-0 │  641155 │
└───────────────────────────────┴─────────┘

3 rows in set. Elapsed: 0.026 sec. Processed 1.97 million rows, 7.88 MB (75.51 million rows/s., 302.05 MB/s.)

​

Interroger sur plusieurs nœuds et versions

En raison du versionnement des tables système, cela ne représente toujours pas l’ensemble des données du cluster. En combinant ce qui précède avec la fonction merge, nous obtenons un résultat exact pour notre intervalle de dates :

SELECT
    hostname() AS host,
    count()
FROM clusterAllReplicas('default', merge('system', '^query_log'))
WHERE (event_time >= '2025-04-01 00:00:00') AND (event_time <= '2025-04-12 00:00:00')
GROUP BY host SETTINGS skip_unavailable_shards = 1

┌─host──────────────────────────┬─count()─┐
│ c-ecru-qn-34-server-s5bnysl-0 │ 3008000 │
│ c-ecru-qn-34-server-6em4y4t-0 │ 3659443 │
│ c-ecru-qn-34-server-iejrkg0-0 │ 1078287 │
└───────────────────────────────┴─────────┘

3 rows in set. Elapsed: 0.462 sec. Processed 7.94 million rows, 31.75 MB (17.17 million rows/s., 68.67 MB/s.)

​

Contenu connexe

• Blog : Tables système et aperçu du fonctionnement interne de ClickHouse
• Blog : Requêtes de supervision essentielles - partie 1 - requêtes INSERT
• Blog : Requêtes de supervision essentielles - partie 2 - requêtes SELECT