Tableau de bord avancé dans ClickHouse Cloud

Tableau de bord avancé dans ClickHouse Cloud

Surveiller votre système de base de données dans un environnement de production est essentiel pour évaluer l’état de santé de votre déploiement et ainsi prévenir ou résoudre les pannes.

Le tableau de bord avancé est un outil léger conçu pour vous offrir une vision détaillée de votre système ClickHouse et de son environnement, afin de vous aider à anticiper les goulots d’étranglement en matière de performances, les défaillances du système et les inefficacités.

Le tableau de bord avancé est disponible à la fois dans ClickHouse OSS (logiciel open source) et dans Cloud. Dans cet article, nous vous montrerons comment utiliser le tableau de bord avancé dans Cloud.

​

Accéder au tableau de bord avancé

Pour accéder au tableau de bord avancé, accédez à :

• Panneau latéral gauche
  • Monitoring → Advanced dashboard

​

Accéder au tableau de bord avancé natif

Vous pouvez accéder au tableau de bord avancé natif en allant dans :

• Panneau latéral gauche
  • Monitoring → Advanced dashboard
  • Cliquez sur You can still access the native advanced dashboard.

Cela ouvrira le tableau de bord avancé natif dans un nouvel onglet. Vous devrez vous authentifier pour accéder au tableau de bord.

Chaque visualisation est associée à une requête SQL qui l’alimente. Vous pouvez modifier cette requête en cliquant sur l’icône en forme de stylo.

​

Visualisations prêtes à l’emploi

Les graphiques par défaut du tableau de bord avancé sont conçus pour offrir une visibilité en temps réel sur votre système ClickHouse. Vous trouverez ci-dessous une liste accompagnée d’une description pour chaque graphique. Ils sont regroupés en trois catégories pour vous aider à vous y retrouver.

​

Spécifique à ClickHouse

Ces métriques sont conçues pour surveiller l’état de santé et les performances de votre instance ClickHouse.

Métrique	Description
Requêtes par seconde	Suit le rythme de traitement des requêtes
Lignes sélectionnées/s	Indique le nombre de lignes lues par les requêtes
Lignes insérées/s	Mesure le taux d’ingestion des données
Nombre total de parts MergeTree	Affiche le nombre de parts actives dans les tables MergeTree, ce qui aide à identifier les insertions non regroupées
Nombre maximal de parts par partition	Met en évidence le nombre maximal de parts dans une partition
Requêtes en cours d’exécution	Affiche le nombre de requêtes en cours d’exécution
Octets sélectionnés par seconde	Indique le volume de données lues par les requêtes

​

Spécifique à l’état du système

Surveiller le système sous-jacent est tout aussi important que de surveiller ClickHouse lui-même.

Métrique	Description
Attente d’E/S	Suit les temps d’attente des E/S
Attente CPU	Mesure les délais causés par la contention des ressources CPU
Lecture depuis le disque	Suit le nombre d’octets lus depuis les disques ou les périphériques de bloc
Lecture depuis le système de fichiers	Suit le nombre d’octets lus depuis le système de fichiers, y compris le cache de pages
Mémoire (suivie, octets)	Affiche l’utilisation de la mémoire des processus suivis par ClickHouse
Charge moyenne (15 minutes)	Indique la charge moyenne actuelle du système sur 15 minutes
Utilisation CPU de l’OS (espace utilisateur)	Utilisation CPU lors de l’exécution de code en espace utilisateur
Utilisation CPU de l’OS (noyau)	Utilisation CPU lors de l’exécution de code noyau

​

Spécifique à ClickHouse Cloud

ClickHouse Cloud stocke les données dans un stockage objet (de type S3). Surveiller cette interface peut aider à détecter des problèmes.

Métrique	Description
Attente de lecture S3	Mesure la latence des requêtes de lecture vers S3
Erreurs de lecture S3 par seconde	Suit le taux d’erreurs de lecture
Lecture depuis S3 (octets/s)	Suit le débit de lecture des données depuis le stockage S3
Requêtes d’écriture sur disque S3/s	Surveille la fréquence des opérations d’écriture vers le stockage S3
Requêtes de lecture sur disque S3/s	Surveille la fréquence des opérations de lecture depuis le stockage S3
Taux de réussite du cache de pages	Taux de réussite du cache de pages
Taux de réussite du cache du système de fichiers	Taux de réussite du cache du système de fichiers
Taille du cache du système de fichiers	Taille actuelle du cache du système de fichiers
Octets envoyés sur le réseau/s	Suit le débit actuel du trafic réseau entrant
Octets reçus sur le réseau/s	Suit le débit actuel du trafic réseau sortant
Connexions réseau simultanées	Suit le nombre actuel de connexions réseau simultanées

​

Identifier les problèmes à l’aide du tableau de bord avancé

Disposer de cette vue en temps réel de l’état de santé de votre service ClickHouse aide grandement à atténuer les problèmes avant qu’ils n’affectent votre activité ou à les résoudre. Vous trouverez ci-dessous quelques problèmes que vous pouvez repérer à l’aide du tableau de bord avancé.

​

Insertions non regroupées

Comme indiqué dans la documentation des bonnes pratiques, il est recommandé, lorsque c’est possible de manière synchrone, de toujours insérer les données par lots dans ClickHouse.

Une insertion en bloc avec une taille de lot raisonnable réduit le nombre de parts créées pendant l’ingestion, ce qui se traduit par des écritures sur disque plus efficaces et moins d’opérations de fusion.

Les métriques clés pour repérer des insertions non optimisées sont Inserted Rows/sec et Max Parts for Partition

L’exemple ci-dessus montre deux pics de Inserted Rows/sec et de Max Parts for Partition entre 13h et 14h. Cela indique que nous ingérons les données à un rythme raisonnable.

On observe ensuite un autre pic important de Max Parts for Partition après 16h, mais un Inserted Rows/sec très faible. Beaucoup de parts sont créées alors que très peu de données sont générées, ce qui indique que la taille des parts est sous-optimale.

​

Requête gourmande en ressources

Il est courant d’exécuter des requêtes SQL qui consomment beaucoup de ressources, comme le CPU ou la mémoire. Il est toutefois important de surveiller ces requêtes et de comprendre leur impact sur les performances globales de votre déploiement.

Une variation soudaine de la consommation de ressources sans changement du débit des requêtes peut indiquer l’exécution de requêtes plus coûteuses. Selon le type de requêtes que vous exécutez, cela peut être normal, mais il est utile de pouvoir les repérer dans le tableau de bord avancé.

Vous trouverez ci-dessous un exemple où l’utilisation du CPU atteint un pic sans modifier de manière significative le nombre de requêtes exécutées par seconde.

​

Mauvaise conception de la clé primaire

Un autre problème que vous pouvez repérer à l’aide du tableau de bord avancé est une mauvaise conception de la clé primaire. Comme décrit dans “Une introduction pratique aux index primaires dans ClickHouse”, choisir une clé primaire bien adaptée à votre cas d’usage améliorera considérablement les performances en réduisant le nombre de lignes que ClickHouse doit lire pour exécuter votre requête.

L’une des métriques à surveiller pour repérer d’éventuelles améliorations des clés primaires est Lignes sélectionnées par seconde. Un pic soudain du nombre de lignes sélectionnées peut indiquer à la fois une augmentation générale du débit global des requêtes, ainsi que des requêtes qui sélectionnent un grand nombre de lignes pour être exécutées.

En utilisant l’horodatage comme filtre, vous pouvez trouver les requêtes exécutées au moment du pic dans la table system.query_log.

Par exemple, exécutez une requête qui affiche toutes les requêtes exécutées entre 11 h et 11 h un jour donné, afin de comprendre quelles requêtes lisent trop de lignes :

Query

SELECT
    type,
    event_time,
    query_duration_ms,
    query,
    read_rows,
    tables
FROM system.query_log
WHERE has(databases, 'default') AND (event_time >= '2024-12-23 11:20:00') AND (event_time <= '2024-12-23 11:30:00') AND (type = 'QueryFinish')
ORDER BY query_duration_ms DESC
LIMIT 5
FORMAT VERTICAL

Response

Row 1:
──────
type:              QueryFinish
event_time:        2024-12-23 11:22:55
query_duration_ms: 37407
query:             SELECT
    toStartOfMonth(review_date) AS month,
    any(product_title),
    avg(star_rating) AS avg_stars
FROM amazon_reviews_no_pk
WHERE
    product_category = 'Home'
GROUP BY
    month,
    product_id
ORDER BY
    month DESC,
    product_id ASC
LIMIT 20
read_rows:         150957260
tables:            ['default.amazon_reviews_no_pk']

Row 2:
──────
type:              QueryFinish
event_time:        2024-12-23 11:26:50
query_duration_ms: 7325
query:             SELECT
    toStartOfMonth(review_date) AS month,
    any(product_title),
    avg(star_rating) AS avg_stars
FROM amazon_reviews_no_pk
WHERE
    product_category = 'Home'
GROUP BY
    month,
    product_id
ORDER BY
    month DESC,
    product_id ASC
LIMIT 20
read_rows:         150957260
tables:            ['default.amazon_reviews_no_pk']

Row 3:
──────
type:              QueryFinish
event_time:        2024-12-23 11:24:10
query_duration_ms: 3270
query:             SELECT
    toStartOfMonth(review_date) AS month,
    any(product_title),
    avg(star_rating) AS avg_stars
FROM amazon_reviews_pk
WHERE
    product_category = 'Home'
GROUP BY
    month,
    product_id
ORDER BY
    month DESC,
    product_id ASC
LIMIT 20
read_rows:         6242304
tables:            ['default.amazon_reviews_pk']

Row 4:
──────
type:              QueryFinish
event_time:        2024-12-23 11:28:10
query_duration_ms: 2786
query:             SELECT
    toStartOfMonth(review_date) AS month,
    any(product_title),
    avg(star_rating) AS avg_stars
FROM amazon_reviews_pk
WHERE
    product_category = 'Home'
GROUP BY
    month,
    product_id
ORDER BY
    month DESC,
    product_id ASC
LIMIT 20
read_rows:         6242304
tables:            ['default.amazon_reviews_pk']

Dans cet exemple, on voit la même requête exécutée sur deux tables amazon_reviews_no_pk et amazon_reviews_pk. On peut en conclure que quelqu’un testait une option de clé primaire pour la table amazon_reviews.