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.

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

• Panneau latéral gauche
  • Monitoring → Advanced dashboard

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.

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.

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

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

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

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é.

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 Ligne inséré et Nombre maximal de part par partition

L’exemple ci-dessus montre deux pics de Ligne inséré et de Nombre maximal de part par 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 Nombre maximal de part par partition après 16h, mais un Ligne inséré 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.

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.

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 :

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

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.