Mise en production

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.

Lors du déploiement de ClickStack, provisionnez les ressources de calcul pour couvrir deux charges de travail indépendantes : ingestion et 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).

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.

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 "Creating an ingestion user" 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.