ClickHouse Série Migration

Exécutez les deux.
Prouvez la parité. Basculez.

Construisez la source Elasticsearch, écrivez simultanément les logs, traces et métriques en direct dans ClickHouse Cloud, prouvez que les deux systèmes concordent, puis retirez Elasticsearch en faisant de ClickStack l'unique interface d'observabilité.

4 à 6 heures · pratique2 charges en direct3 signaux de télémétrie10 étapes de migration

Ce n'est pas une réindexation. C'est un changement de systèmes maîtrisé.

Copier les documents est la partie facile. La véritable migration consiste à remplacer les data streams, mappings, règles ILM, pipelines d'ingestion, dashboards Kibana et règles d'alerte sans perdre les signaux dont dépendent les opérateurs.

Cet atelier propose deux charges en direct : Filebeat expédie trois formats de logs, tandis qu'OpenTelemetry Demo envoie les traces, métriques et logs de seize microservices via Elastic APM. Vous examinez le système avant de concevoir son remplaçant.

La bascule repose sur des preuves. Deux OpenTelemetry Collectors distribuent les mêmes événements vers Elasticsearch et ClickHouse Cloud, pendant que des scripts de validation comparent les comptages, schémas, enrichissements et la fraîcheur.

Ce n'est qu'après le passage de la porte de parité que vous retirez les exporters Elasticsearch et arrêtez l'ancienne stack. HyperDX devient alors l'unique interface pour la recherche, les dashboards, les traces, les métriques, les alertes et l'investigation assistée par l'IA.

Ce avec quoi vous repartez

La migration complète, opérationnelle de bout en bout.

Une source réaliste, une cible ClickHouse optimisée et une décision de bascule étayée par des mesures en direct.

01

Une source de référence réaliste

Trois data streams Elasticsearch, quatre pipelines d'ingestion, des règles ILM, six dashboards Kibana, Elastic APM et seize services instrumentés générant du trafic.

02

Une conception ClickHouse guidée par les requêtes

Des clés de tri MergeTree choisies selon les modes d'accès, les attributs OTel flexibles conservés dans Map et les champs fréquents promus en colonnes matérialisées typées.

03

Un traitement d'ingestion reconstruit explicitement

Un chemin Null → materialized view → MergeTree avec des dictionnaires IP_TRIE, des colonnes d'enrichissement matérialisées, TTL, des index textuels et des tables récapitulatives.

04

Une exécution en parallèle mesurable

Les collecteurs de fichiers et OTLP écrivent chaque signal dans les deux backends, tandis que des contrôles automatisés comparent les comptages en direct et vérifient GeoIP, la gravité et les champs analysés.

05

ClickStack comme surface opérationnelle

Des sources HyperDX pour les logs, les traces et les cinq tables de métriques, ainsi que les dashboards, recherches enregistrées, alertes et un graphique assisté par l'IA recréés.

06

Des décisions de migration que vous savez défendre

Cinq traductions de requêtes, un ADR à sept décisions, six exercices SQL avancés et une évaluation par scénarios centrée sur les compromis plutôt que sur les commandes.

Ce qui remplace quoi

data streams + ILMpartitions MergeTree + TTL
pipelines d'ingestionMVs + colonnes + dictionnaires
Filebeat / Elastic AgentOpenTelemetry Collector
ECSconventions sémantiques OTel
transforms ElasticsearchMVs AggregatingMergeTree
KibanaHyperDX / ClickStack

Le parcours · 4 à 6 heures de pratique

Cinq modules, une bascule maîtrisée.

Construisez la référence, prenez les décisions de conception, exécutez les deux systèmes ensemble et ne retirez l'ancien backend que lorsque les preuves montrent que vous pouvez le faire sans risque.

  1. 00

    Installez Docker, le client ClickHouse, curl et jq ; choisissez une source locale ou sur EC2 ; créez le compte ClickHouse Cloud et vérifiez chaque artefact.

  2. 01

    Démarrez Elasticsearch, Kibana, Filebeat, Elastic APM Server, trois générateurs de logs et OpenTelemetry Demo, puis capturez une référence dont les données augmentent.

  3. 02

    Examinez les mappings, data streams, pipelines, règles de cycle de vie et la latence des requêtes ; traduisez cinq requêtes ; puis rédigez le schéma cible et l'ADR de migration.

  4. 03

    Provisionnez ClickHouse, créez les dictionnaires et tables, lancez la double écriture, validez la parité, configurez HyperDX, testez les TTL et les résumés, migrez les alertes, puis basculez.

  5. 04

    Répondez à quinze QCM et cinq scénarios ouverts portant sur les schémas, la planification de migration, le débogage et les compromis liés aux alertes.

Autonome par défaut. La source créée dans le module 01 reste active jusqu'au module 03. N'arrêtez jamais Elasticsearch avant que les deux scripts de parité réussissent et que les configurations de bascule des collecteurs soient prêtes.

Avant de participer

À qui s'adresse l'atelier et que faut-il apporter ?

À qui s'adresse-t-il ? public

  • Ingénieurs partenaires ClickHouse et architectes solutions préparant des migrations d'observabilité
  • Équipes remplaçant le stockage Elasticsearch tout en conservant l'instrumentation OpenTelemetry
  • Toute personne devant expliquer comment la parité est prouvée avant la bascule
  • Être à l'aise avec un terminal, Docker et SQL ; aucune expérience préalable de l'exploitation de ClickHouse n'est requise

Ce qu'il faut apporter prérequis

  • Docker 24+ et Compose 2.20+ avec 16 Go de RAM disponible ; 32 Go recommandés
  • Le client ClickHouse, curl, jq et un essai ClickHouse Cloud
  • Terraform 1.5+, un compte AWS et une paire de clés EC2 uniquement si vous choisissez la source distante
  • Au moins 5 Go d'espace disque libre pour les images et volumes des conteneurs

Déroulement format

  • 100 % pratique, avec deux charges d'observabilité qui évoluent continuellement
  • Docker local ou EC2 provisionné avec Terraform pour la source ; ClickHouse Cloud pour la cible
  • Un parcours participant, les notes formateur correspondantes, des exercices modifiables et des corrigés hébergés
  • L'évaluation finale est à livre ouvert et teste le jugement, pas la mémorisation des commandes

Ce que cet atelier ne couvre pas périmètre

  • Réindexation historique massive depuis un cluster Elasticsearch de production existant
  • Identité, réseau privé, multitenance ou contrôles de conformité en production
  • Planification de capacité à long terme ou certification formelle des performances
  • Les règles d'alerte incluses valident le modèle ; l'intégration du fournisseur de notifications reste propre à votre environnement

Prêt à rendre la bascule mesurable ?

Venez avec un essai ClickHouse Cloud et une machine capable d'exécuter la stack source. Repartez avec chaque sous-système Elasticsearch cartographié, trois signaux en direct validés en parallèle et une bascule avec retour arrière que vous savez expliquer.

3Logs, traces et métriques validés sur les deux backends.
2→1Deux systèmes actifs pendant la preuve ; un seul après la bascule.
20Contrôles de connaissances, plus cinq scénarios de migration ouverts.
FR