Mise en production

Mise en production avec ClickStack

Lors du déploiement de ClickStack en production, plusieurs points supplémentaires doivent être pris en compte pour garantir la sécurité, la stabilité et une configuration correcte. Ils varient selon la distribution utilisée — Open Source ou Managed.

ClickStack managé

Pour les déploiements en production, Managed ClickStack est recommandé. Il applique par défaut des pratiques de sécurité conformes aux standards du secteur, notamment un chiffrement renforcé, l’authentification et la connectivité, ainsi que des contrôles d’accès gérés, tout en offrant les avantages suivants :

• Mise à l’échelle automatique de la capacité de calcul, indépendamment du stockage
• Rétention à faible coût et pratiquement illimitée, basée sur le stockage objet
• Possibilité d’isoler indépendamment les charges de travail de lecture et d’écriture avec les Warehouses
• Authentification intégrée
• Sauvegardes automatisées
• Mises à niveau sans interruption

Suivez ces bonnes pratiques pour ClickHouse Cloud lorsque vous utilisez Managed ClickStack.

​

Sécuriser l’ingestion

Par défaut, le ClickStack OpenTelemetry Collector n’est pas sécurisé lorsqu’il est déployé en dehors des distributions open source et ne nécessite pas d’authentification sur ses ports OTLP.

Pour sécuriser l’ingestion, spécifiez un jeton d’authentification lors du déploiement du collector à l’aide de la variable d’environnement OTLP_AUTH_TOKEN. Consultez “Securing the collector” pour plus de détails.

​

Créer un utilisateur d’ingestion

Il est recommandé de créer un utilisateur dédié pour l’OTel collector afin d’ingérer les données dans Managed ClickHouse et de garantir que l’ingestion est envoyée vers une base de données spécifique, par exemple otel. Consultez “Creating an ingestion user” pour plus de détails.

​

Configurer le Time To Live (TTL)

Assurez-vous que le Time To Live (TTL) a été configuré de manière appropriée pour votre déploiement Managed ClickStack. Il contrôle la durée de conservation des données ; la valeur par défaut de 3 jours doit souvent être modifiée.

​

Estimation des ressources

Ce qui suit propose un modèle pour estimer les ressources de calcul et de stockage nécessaires à un déploiement ClickStack en fonction du volume d’ingestion prévu. Les valeurs obtenues sont uniquement des estimations et doivent servir de référence initiale - elles ne constituent pas une recommandation prescriptive. Les besoins réels dépendent de la complexité des requêtes, de la concurrence, des politiques de rétention et des variations du débit d’ingestion. Surveillez toujours l’utilisation des ressources et adaptez le dimensionnement selon les besoins.

Tous les chiffres sont basés sur l’ingestion brute non compressée

Tous les chiffres indiqués sur cette page - débit (MB/s, TB/mois), dimensionnement CPU et stockage - sont exprimés en volume d’ingestion brute non compressée, c’est-à-dire la taille des données telles qu’elles sont produites par vos applications et envoyées au collecteur OpenTelemetry avant toute compression.

C’est ce volume que vous devez estimer à partir de vos pipelines existants de logs, de traces et de métriques. Les chiffres de stockage du tableau ci-dessous intègrent déjà le taux de compression de 10x supposé appliqué à ce volume brut.

Lors du déploiement de ClickStack, provisionnez les ressources de calcul pour couvrir deux charges de travail indépendantes : ingestion et requêtes.

Charge de travail	Ressources estimées
Ingestion	1 vCPU pour 10 MB/s de débit d’ingestion soutenu
Requêtes	1 vCPU par QPS et pour 10 MB/s de débit d’ingestion soutenu

Isolation des requêtes par rapport à l’ingestion

Dans la plupart des déploiements autogérés, l’ingestion et les requêtes partagent les mêmes nœuds. Dans ce cas, utilisez le total des CPU comme référence. Le dimensionnement isolé - où les ressources de calcul pour l’ingestion et les requêtes sont provisionnées indépendamment - est pris en charge dans ClickHouse Cloud via des pools de calcul distincts, appelés Warehouses.

Hypothèses

• Un taux de compression de 10x pour le stockage - généralement une hypothèse prudente pour les logs et les traces.
• Des SLA de requête avec un P50 de 1,5 seconde et un P99 de 5 secondes.
• Nous supposons que la plupart des requêtes portent sur des données récentes, selon une distribution log-normale qui culmine autour d’une heure et décroît jusqu’à environ six heures. Les utilisateurs peuvent souhaiter provisionner des ressources de calcul dédiées pour interroger des données plus anciennes. Dans ClickHouse Cloud, celles-ci peuvent rester inactives (et donc ne pas engendrer de coûts) lorsqu’elles ne sont pas utilisées.
• Bien que les ressources de calcul des requêtes puissent être dimensionnées indépendamment de celles de l’ingestion, elles restent intrinsèquement liées au volume d’ingestion. Nous partons du principe qu’à mesure que l’ingestion augmente, la densité des données croît, ce qui entraîne des volumes analysés plus importants au moment des requêtes et, par conséquent, des besoins plus élevés en ressources de calcul pour les requêtes.

Le tableau suivant présente des exemples de dimensionnement basés sur un débit d’ingestion croissant en mégaoctets par seconde, ainsi que les volumes de données correspondants en téraoctets par mois. Il suppose une moyenne soutenue de 1 QPS depuis ClickStack sur l’ensemble des types de requêtes (recherche, tableaux de bord, alertes).

MB/s	TB/mois	CPU d’ingestion	CPU de requête	CPU totaux	Stockage total (par mois) (GB)
10	25.92	1	3	4	2,592
20	51.84	2	6	8	5,184
50	129.6	5	15	20	12,960
100	259.2	10	30	40	25,920
200	518.4	20	60	80	51,840
500	1,296	50	150	200	129,600
1000	2,592	100	300	400	259,200

Pour plus de détails sur l’affinage des hypothèses de dimensionnement pour votre environnement, consultez “Refining sizing assumptions for your environment”.

​

Isoler les charges de travail d’observabilité

Si vous ajoutez ClickStack à un service ClickHouse Cloud existant qui prend déjà en charge d’autres charges de travail, comme l’analytique applicative en temps réel, il est fortement recommandé d’isoler le trafic d’observabilité.

Utilisez les Managed Warehouses pour créer un service enfant dédié à ClickStack. Cela vous permet de :

• Isoler la charge d’ingestion et de requête des applications existantes
• Mettre à l’échelle indépendamment les charges de travail d’observabilité
• Empêcher les requêtes d’observabilité d’avoir un impact sur l’analytique de production
• Partager, si nécessaire, les mêmes jeux de données sous-jacents entre les services

Cette approche garantit que vos charges de travail existantes ne sont pas affectées tout en permettant à ClickStack de monter en charge indépendamment à mesure que les données d’observabilité augmentent.

Pour les déploiements plus importants ou pour obtenir des recommandations de dimensionnement personnalisées, veuillez contacter le support pour une estimation plus précise.

ClickStack Open Source

​

Sécurité réseau et des ports

Par défaut, Docker Compose expose les ports sur l’hôte, les rendant accessibles depuis l’extérieur du conteneur — même si des outils comme ufw (Uncomplicated Firewall) sont activés. Ce comportement est lié à la pile réseau Docker, qui peut contourner les règles de pare-feu au niveau de l’hôte si elle n’est pas explicitement configurée.

Recommandation :

N’exposez que les ports nécessaires à un usage en production. En général, les endpoints OTLP, le serveur API et le frontend.

Par exemple, supprimez ou commentez les mappages de ports inutiles dans votre fichier docker-compose.yml :

ports:
  - "4317:4317"  # OTLP gRPC
  - "4318:4318"  # OTLP HTTP
  - "8080:8080"  # Only if needed for the API
# Avoid exposing internal ports like ClickHouse 8123 or MongoDB 27017.

Consultez la documentation sur la mise en réseau Docker pour plus d’informations sur l’isolation des conteneurs et le renforcement des accès.

​

Configuration du secret de session

En production, vous devez définir une valeur forte et aléatoire pour la variable d’environnement EXPRESS_SESSION_SECRET de la ClickStack UI (HyperDX) — afin de protéger les données de session et d’empêcher toute altération.

Voici comment l’ajouter à votre fichier docker-compose.yml pour le service applicatif :

  app:
    image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION}
    ports:
      - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
      - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
    environment:
      FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
      HYPERDX_API_KEY: ${HYPERDX_API_KEY}
      HYPERDX_API_PORT: ${HYPERDX_API_PORT}
      HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
      HYPERDX_APP_URL: ${HYPERDX_APP_URL}
      HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
      MINER_API_URL: 'http://miner:5123'
      MONGO_URI: 'mongodb://db:27017/hyperdx'
      NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
      OTEL_SERVICE_NAME: 'hdx-oss-api'
      USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
      EXPRESS_SESSION_SECRET: "super-secure-random-string"
    networks:
      - internal
    depends_on:
      - ch-server
      - db1

Vous pouvez générer un secret robuste à l’aide d’openssl :

openssl rand -hex 32

Évitez de committer des secrets dans le contrôle de source. En production, envisagez d’utiliser des outils de gestion des variables d’environnement (par exemple Docker Secrets, HashiCorp Vault, ou des configs CI/CD spécifiques à l’environnement).

​

Ingestion sécurisée

Toute ingestion doit s’effectuer via les ports OTLP exposés par la distribution ClickStack du collecteur OpenTelemetry (OTel). Par défaut, cela nécessite une clé API d’ingestion sécurisée générée au démarrage. Cette clé est requise pour envoyer des données vers les ports OTel et se trouve dans l’interface HyperDX UI sous Team Settings → API Keys.

Il est également recommandé d’activer le TLS pour les endpoints OTLP.

​

Créer un utilisateur d’ingestion

Il est recommandé de créer un utilisateur dédié pour l’OTel collector afin d’ingérer les données dans ClickHouse et de s’assurer que l’ingestion est envoyée vers une base de données spécifique, par exemple otel. Consultez “Création d’un utilisateur d’ingestion” pour plus de détails.

​

ClickHouse

Les utilisateurs qui gèrent leur propre instance ClickHouse doivent respecter les bonnes pratiques suivantes.

​

Bonnes pratiques de sécurité

Si vous gérez votre propre instance ClickHouse, il est indispensable d’activer le TLS, d’imposer l’authentification et de suivre les bonnes pratiques pour renforcer la sécurité des accès. Consultez cet article de blog pour avoir un aperçu des erreurs de configuration rencontrées en production et savoir comment les éviter.

ClickHouse OSS offre des fonctionnalités de sécurité robustes prêtes à l’emploi. Celles-ci nécessitent toutefois une configuration :

• Utilisez TLS via tcp_port_secure et <openSSL> dans config.xml. Voir guides/sre/configuring-tls.
• Définissez un mot de passe robuste pour l’utilisateur default ou désactivez cet utilisateur.
• Évitez d’exposer ClickHouse à l’extérieur sauf si c’est explicitement nécessaire. Par défaut, ClickHouse n’écoute que sur localhost, sauf si listen_host est modifié.
• Utilisez des méthodes d’authentification telles que des mots de passe, des certificats, des clés SSH ou des authentificateurs externes.
• Restreignez l’accès à l’aide du filtrage IP et de la clause HOST. Voir sql-reference/statements/create/user#user-host.
• Activez le contrôle d’accès basé sur les rôles (RBAC) pour accorder des privilèges granulaires. Voir operations/access-rights.
• Appliquez des quotas et des limites à l’aide des quotas, des profils de paramètres et des modes en lecture seule.
• Chiffrez les données au repos et utilisez un stockage externe sécurisé. Voir operations/storing-data et cloud/security/CMEK.
• Évitez de coder les identifiants en dur. Utilisez des collections nommées ou des IAM roles dans ClickHouse Cloud.
• Auditez les accès et les requêtes à l’aide des journaux système et des journaux de session.

Voir aussi les authentificateurs externes et les paramètres de complexité des requêtes pour la gestion des utilisateurs et l’application de limites sur les requêtes et les ressources.

​

Permissions utilisateur pour le ClickStack UI

L’utilisateur ClickHouse pour la ClickStack UI doit uniquement être un utilisateur readonly ayant la possibilité de modifier les paramètres suivants :

• max_rows_to_read (au moins jusqu’à 1 million)
• read_overflow_mode
• cancel_http_readonly_queries_on_client_close
• wait_end_of_query

Par défaut, l’utilisateur default dans OSS et ClickHouse Cloud dispose de ces permissions, mais il est recommandé de créer un nouvel utilisateur dédié avec ces permissions.

​

Configurer le Time To Live (TTL)

Assurez-vous que le Time To Live (TTL) a été correctement configuré pour votre déploiement ClickStack. Ce paramètre contrôle la durée de rétention des données — la valeur par défaut de 3 jours doit souvent être modifiée.

​

Directives MongoDB

Suivez la liste de contrôle de sécurité MongoDB officielle.