Toute solution d’observability nécessite un moyen de collecter et d’exporter les logs et les traces. À cette fin, ClickHouse recommande le projet OpenTelemetry (OTel).
“OpenTelemetry est un framework et une boîte à outils d’observability conçus pour créer et gérer des données de télémétrie telles que les traces, les metrics et les logs.”
Contrairement à ClickHouse ou à Prometheus, OpenTelemetry n’est pas un backend d’observability ; il se concentre plutôt sur la génération, la collecte, la gestion et l’export de données de télémétrie. Si l’objectif initial d’OpenTelemetry était de vous permettre d’instrumenter facilement vos applications ou vos systèmes à l’aide de SDKs propres à chaque langage, il s’est depuis étendu à la collecte de logs via l’OpenTelemetry collector, un agent ou proxy qui reçoit, traite et exporte des données de télémétrie.
Composants pertinents pour ClickHouse
- L’OpenTelemetry Collector est un proxy qui reçoit, traite et exporte les données de télémétrie. Une solution reposant sur ClickHouse utilise ce composant à la fois pour collecter les logs et traiter les événements avant leur mise en lot et leur insertion.
- Les SDKs de langage qui implémentent la spécification, les API et l’export des données de télémétrie. Ces SDKs garantissent concrètement que les traces sont correctement enregistrées dans le code d’une application, en générant les spans qui les composent et en veillant à ce que le contexte soit propagé entre les services via les métadonnées, ce qui permet de constituer des traces distribuées et de corréler les spans. Ces SDKs sont complétés par un écosystème qui instrumente automatiquement les bibliothèques et frameworks courants, ce qui signifie que l’utilisateur n’a pas besoin de modifier son code et bénéficie d’une instrumentation prête à l’emploi.
Une solution d’observabilité reposant sur ClickHouse tire parti de ces deux outils.
Le collecteur OpenTelemetry existe en plusieurs distributions. Le receiver filelog ainsi que l’exporter ClickHouse, nécessaires pour une solution ClickHouse, ne sont disponibles que dans la distribution OpenTelemetry Collector Contrib.
Cette distribution contient de nombreux composants et permet d’expérimenter diverses configurations. Cependant, pour une exécution en production, il est recommandé de limiter le collecteur aux seuls composants nécessaires à l’environnement. Voici quelques raisons de le faire :
- Réduire la taille du collecteur, et donc le temps de déploiement du collecteur
- Améliorer la sécurité du collecteur en réduisant la surface d’attaque disponible
Il est possible de créer un collecteur personnalisé à l’aide d’OpenTelemetry Collector Builder.
Ingestion de données avec OTel
Rôles de déploiement du collecteur
- Agent - Les instances d’agent collectent les données en périphérie, par exemple sur des serveurs ou des nœuds Kubernetes, ou reçoivent directement des événements d’applications instrumentées avec un SDK OpenTelemetry. Dans ce dernier cas, l’instance d’agent s’exécute avec l’application ou sur le même hôte que celle-ci (par exemple en sidecar ou sous forme de DaemonSet). Les agents peuvent envoyer leurs données directement à ClickHouse ou à une instance de passerelle. Dans le premier cas, on parle du modèle de déploiement Agent.
- Gateway - Les instances de passerelle fournissent un service autonome (par exemple, un déploiement dans Kubernetes), généralement par cluster, par centre de données ou par région. Elles reçoivent les événements des applications (ou d’autres collecteurs agissant comme agents) via un point de terminaison OTLP unique. En règle générale, plusieurs instances de passerelle sont déployées, avec un équilibreur de charge prêt à l’emploi pour répartir la charge entre elles. Lorsque tous les agents et toutes les applications envoient leurs signaux vers ce point de terminaison unique, on parle souvent du modèle de déploiement Gateway.
Dans la suite, nous partons du principe qu’un collecteur agent simple envoie directement ses événements à ClickHouse. Voir Scaling with Gateways pour plus de détails sur l’utilisation des passerelles et les cas où elles sont pertinentes.
Le principal avantage de l’utilisation d’un collecteur est qu’il permet à vos services d’évacuer rapidement les données, en laissant au Collector le soin de gérer les traitements supplémentaires tels que les nouvelles tentatives, le regroupement par lots, le chiffrement ou encore le filtrage des données sensibles.
Le Collector utilise les termes receiver, processor et exporter pour ses trois principales étapes de traitement. Les receivers servent à collecter les données et peuvent fonctionner en mode pull ou push. Les processors permettent d’effectuer des transformations et d’enrichir les messages. Les exporters se chargent d’envoyer les données vers un service en aval. Bien que ce service puisse, en théorie, être un autre collecteur, nous partons ici du principe que toutes les données sont envoyées directement à ClickHouse.
Nous recommandons aux utilisateurs de se familiariser avec l’ensemble des receivers, processors et exporters.
Le collecteur fournit deux receivers principaux pour la collecte des logs :
Via OTLP - Dans ce cas, les logs sont envoyés (push) directement au collecteur depuis les OpenTelemetry SDKs via le protocole OTLP. La OpenTelemetry demo utilise cette approche, les exporters OTLP de chaque langage supposant un endpoint local du collecteur. Le collecteur doit alors être configuré avec l’OTLP receiver — voir la démo ci-dessus pour un exemple de configuration. L’avantage de cette approche est que les données de logs contiennent automatiquement des trace IDs, ce qui permet ensuite d’identifier les traces associées à un log donné, et inversement.
Cette approche exige que les utilisateurs instrumentent leur code avec le SDK adapté à leur langage.
- Scraping via le receiver filelog - Ce receiver lit les fichiers sur disque en continu, génère des messages de log, puis les envoie à ClickHouse. Il prend en charge des tâches complexes telles que la détection des messages multilignes, la gestion de la rotation des logs, les checkpoints pour une meilleure robustesse au redémarrage, ainsi que l’extraction de structure. Il peut également suivre les logs des conteneurs Docker et Kubernetes, et être déployé via un chart Helm, en extrayant leur structure et en les enrichissant avec les détails du pod.
La plupart des déploiements utiliseront une combinaison des receivers ci-dessus. Nous recommandons aux utilisateurs de lire la documentation du collecteur et de se familiariser avec les concepts de base, ainsi qu’avec la structure de configuration et les méthodes d’installation.
Astuce : otelbin.iootelbin.io est utile pour valider et visualiser les configurations. Structuré ou non structuré
json_parser, puisque nos logs sont structurés. Modifiez le chemin vers le fichier access-structured.log.
config-structured-logs.yaml
Vous pouvez suivre les instructions officielles pour installer le collector localement. Veillez toutefois à adapter ces instructions afin d’utiliser la distribution contrib (qui contient le receiver filelog) ; par exemple, au lieu de otelcol_0.102.1_darwin_arm64.tar.gz, les utilisateurs devront télécharger otelcol-contrib_0.102.1_darwin_arm64.tar.gz. Les releases sont disponibles ici.
Une fois installé, l’OTel Collector peut être exécuté à l’aide des commandes suivantes :
En utilisant des logs structurés, les messages prendront la forme suivante en sortie :
Le contenu ci-dessus représente un seul message de log tel que produit par l’OTel collector. Nous ingérons ces mêmes messages dans ClickHouse dans les sections suivantes.
Le schéma complet des messages de log, ainsi que les colonnes supplémentaires qui peuvent être présentes si vous utilisez d’autres receivers, est maintenu ici. Nous recommandons vivement aux utilisateurs de se familiariser avec ce schéma.
L’élément essentiel ici est que la ligne de log elle-même est stockée sous forme de chaîne dans le champ Body, tandis que le JSON a été extrait automatiquement dans le champ Attributes grâce à json_parser. Ce même operator a également été utilisé pour extraire le timestamp vers la colonne Timestamp appropriée. Pour des recommandations sur le traitement des logs avec OTel, voir Processing.
OpérateursLes opérateurs constituent l’unité la plus élémentaire du traitement des logs. Chaque opérateur remplit une fonction unique, comme lire des lignes depuis un fichier ou analyser du JSON à partir d’un champ. Les opérateurs sont ensuite chaînés dans un pipeline afin d’obtenir le résultat souhaité.
TraceID ni SpanID. S’ils étaient présents, par exemple dans les cas où des utilisateurs mettent en œuvre le traçage distribué, ils pourraient être extraits du JSON en utilisant les mêmes techniques que celles présentées ci-dessus.
Pour les utilisateurs qui doivent collecter des fichiers de log locaux ou des fichiers de log Kubernetes, nous recommandons de se familiariser avec les options de configuration disponibles pour le filelog receiver, ainsi qu’avec la façon dont le suivi des offsets et l’analyse multiligne des logs sont gérés.
Collecte des logs Kubernetes
ResourceAttributes. ClickHouse utilise actuellement le type Map(String, String) pour cette colonne. Voir Using Maps et Extracting from maps pour plus de détails sur la gestion et l’optimisation de ce type.
Pour les utilisateurs qui souhaitent instrumenter leur code et collecter des traces, nous recommandons de suivre la documentation officielle d’OTel.
Pour transmettre des événements à ClickHouse, vous devrez déployer un OTel collector afin de recevoir les événements de trace via le protocole OTLP à l’aide du receiver approprié. OpenTelemetry demo fournit un exemple d’instrumentation pour chaque langage pris en charge et d’envoi des événements à un collector. Un exemple de configuration de collector appropriée, qui envoie les événements vers stdout, est présenté ci-dessous :
Comme les traces doivent être reçues via OTLP, nous utilisons l’outil telemetrygen pour générer des données de trace. Suivez les instructions d’installation ici.
La configuration suivante reçoit des événements de trace via un receiver OTLP avant de les envoyer vers stdout.
config-traces.xml
Exécutez cette configuration comme suit :
Envoyez des événements de trace au collector avec telemetrygen :
Cela produira des messages de trace similaires à l’exemple ci-dessous, envoyés vers stdout :
Ce qui précède représente un seul message de trace tel que produit par l’OTel collector. Nous ingérons ces mêmes messages dans ClickHouse dans les sections suivantes.
Le schéma complet des messages de trace est documenté ici. Nous recommandons vivement aux utilisateurs de se familiariser avec ce schéma.
Comme l’a montré l’exemple précédent de définition du timestamp d’un événement de log, vous aurez presque toujours besoin de filtrer, transformer et enrichir les messages d’événement. Pour cela, OpenTelemetry offre plusieurs mécanismes :
-
Processors - Les processors prennent les données collectées par les receivers et les modifient ou les transforment avant de les envoyer aux exporters. Les processors sont appliqués dans l’ordre défini dans la section
processors de la collector configuration. Ils sont facultatifs, mais l’ensemble minimal est généralement recommandé. Lors de l’utilisation d’un OTel collector avec ClickHouse, nous recommandons de limiter les processors à :
- Un memory_limiter sert à éviter les situations de saturation mémoire sur le collector. Consultez Estimating Resources pour les recommandations.
- Tout processor qui effectue un enrichissement basé sur le contexte. Par exemple, le Kubernetes Attributes Processor permet de définir automatiquement les resource attributes des spans, metrics et logs à partir des métadonnées k8s, par ex. en enrichissant les événements avec l’identifiant de leur pod source.
- Le tail sampling ou head sampling, si nécessaire pour les traces.
- Le filtrage de base - suppression des événements inutiles si cela ne peut pas être fait via un opérateur (voir ci-dessous).
- Le batching - indispensable avec ClickHouse pour garantir l’envoi des données par lots. Voir « Exporting to ClickHouse ».
-
Opérateurs - Les opérateurs constituent l’unité de traitement la plus élémentaire disponible au niveau du receiver. Ils prennent en charge le parsing de base, ce qui permet de définir des champs tels que Severity et Timestamp. Le parsing JSON et regex est pris en charge ici, ainsi que le filtrage d’événements et les transformations de base. Nous recommandons d’effectuer le filtrage des événements à ce niveau.
Nous recommandons aux utilisateurs d’éviter un traitement excessif des événements à l’aide d’opérateurs ou de transform processors. Ceux-ci peuvent entraîner une surcharge importante en mémoire et en CPU, en particulier le parsing JSON. Il est possible d’effectuer tout le traitement dans ClickHouse au moment de l’insert à l’aide de materialized views et de colonnes, à quelques exceptions près — notamment l’enrichissement dépendant du contexte, par ex. l’ajout de métadonnées k8s. Pour plus de détails, voir Extracting structure with SQL.
Si le traitement est effectué à l’aide de l’OTel collector, nous recommandons d’exécuter les transformations sur les instances passerelle et de réduire au minimum le travail effectué sur les instances agent. Cela permet de limiter autant que possible les ressources requises par les agents en périphérie, exécutés sur les servers. En pratique, nous constatons que les utilisateurs n’effectuent généralement dans les agents que le filtrage (pour limiter l’utilisation réseau inutile), la définition des timestamps (via des opérateurs) et l’enrichissement lorsqu’il nécessite du contexte. Par exemple, si les instances passerelle se trouvent dans un Kubernetes cluster différent, l’enrichissement k8s devra être effectué dans l’agent.
La configuration suivante montre la collecte d’un fichier de logs non structuré. Notez l’utilisation d’opérateurs pour extraire une structure des lignes de log (regex_parser) et filtrer les événements, ainsi que d’un processeur pour traiter les événements par lot et limiter la consommation mémoire.
config-unstructured-logs-with-processor.yaml
Exportation vers ClickHouse
- pipelines - La configuration ci-dessus met en évidence l’utilisation des pipelines, composés d’un ensemble de receivers, de processeurs et d’exporters, avec un pipeline pour les logs et un pour les traces.
- endpoint - La communication avec ClickHouse est configurée via le paramètre
endpoint. La chaîne de connexion tcp://localhost:9000?dial_timeout=10s&compress=lz4&async_insert=1 fait en sorte que la communication s’effectue sur TCP. Si vous préférez HTTP pour des raisons de basculement de trafic, modifiez cette chaîne de connexion comme décrit ici. Les détails complets de la connexion, y compris la possibilité de spécifier un nom d’utilisateur et un mot de passe dans cette chaîne de connexion, sont décrits ici.
Important : Notez que la chaîne de connexion ci-dessus active à la fois la compression (lz4) et les insertions asynchrones. Nous recommandons que les deux soient toujours activées. Consultez regroupement par lots pour plus de détails sur les insertions asynchrones. La compression doit toujours être spécifiée et ne sera pas activée par défaut sur les anciennes versions de l’exportateur.
- ttl - la valeur indiquée ici détermine la durée de conservation des données. Pour plus de détails, voir “Gestion des données”. Cette valeur doit être spécifiée sous forme d’une unité de temps en heures, par exemple 72h. Nous désactivons le TTL dans l’exemple ci-dessous, car nos données datent de 2019 et seront immédiatement supprimées par ClickHouse si elles sont insérées.
- traces_table_name et logs_table_name - détermine le nom des tables de logs et de traces.
- create_schema - détermine si les tables sont créées avec les schémas par défaut au démarrage. La valeur par défaut est true pour démarrer. Vous devriez le définir sur false et définir votre propre schéma.
- database - base de données cible.
- retry_on_failure - paramètres qui déterminent si les batches en échec doivent être retentés.
- batch - un batch processor garantit que les événements sont envoyés par batches. Nous recommandons une valeur d’au moins 10 000 avec un timeout de 5s (des valeurs allant jusqu’à 100 000 peuvent être utilisées si la mémoire le permet). Le premier de ces seuils atteint déclenchera l’envoi d’un batch à l’exportateur. Réduire ces valeurs permet d’obtenir un pipeline à plus faible latence, avec des données disponibles plus tôt pour les requêtes, au prix d’un plus grand nombre de connections et de batches envoyés à ClickHouse. Cela n’est pas recommandé si vous n’utilisez pas les insertions asynchrones, car cela peut provoquer des problèmes de Too many parts dans ClickHouse. À l’inverse, si vous utilisez les insertions asynchrones, la disponibilité de ces données pour les requêtes dépendra également des paramètres d’insertion asynchrone, même si les données seront tout de même transmises plus tôt par le connecteur. Consultez regroupement par lots pour plus de détails.
- sending_queue - contrôle la taille de la file d’envoi. Chaque élément de la file contient un batch. Si cette file est saturée, par exemple parce que ClickHouse est inaccessible alors que les événements continuent d’arriver, les batches seront abandonnés.
En supposant que les utilisateurs aient extrait le fichier de logs structuré et disposent d’une instance locale de ClickHouse en cours d’exécution (avec l’authentification par défaut), vous pouvez exécuter cette configuration à l’aide de la commande :
Pour envoyer des données de traçage à ce collecteur, exécutez la commande suivante à l’aide de l’outil telemetrygen :
Une fois en fonctionnement, vérifiez la présence d’événements de log à l’aide d’une requête simple :
ClickStack est livré avec un schéma par défaut optimiséClickStack fournit des schémas prêts à l’emploi pour les logs, les traces et les métriques qui intègrent les dernières fonctionnalités de ClickHouse (index textuels pour la recherche en texte intégral et par clé de Map, colonnes matérialisées et arrays ALIAS pour le filtrage en lecture directe, recherche de lignes par numéro de bloc) et ont été benchmarkés pour offrir de solides performances prêtes à l’emploi pour les charges de travail de logging et de traces. Utilisez-les comme point de départ pour votre propre conception. create_schema. En outre, les noms des tables de logs et de traces peuvent être modifiés par rapport à leurs valeurs par défaut, otel_logs et otel_traces, via les paramètres mentionnés ci-dessus.
Dans les schémas ci-dessous, nous supposons que TTL est configuré à 72 h.
otelcol-contrib v0.102.1) :
Les colonnes présentées ici correspondent à la spécification officielle d’OTel pour les logs, décrite ici.
Quelques remarques importantes concernant ce schéma :
- Par défaut, la table est partitionnée par date via
PARTITION BY toDate(Timestamp). Cela permet de supprimer efficacement les données expirées.
- Le TTL est défini via
TTL toDateTime(Timestamp) + toIntervalDay(3) et correspond à la valeur définie dans la configuration du collector. ttl_only_drop_parts=1 signifie que seules des parts entières sont supprimées lorsque toutes les lignes qu’elles contiennent ont expiré. C’est plus efficace que de supprimer des lignes à l’intérieur des parts, ce qui implique un delete coûteux. Nous recommandons de toujours définir ce paramètre. Consultez Gestion des données avec TTL pour plus de détails.
- La table utilise le moteur classique
MergeTree. C’est la recommandation pour les logs et les traces, et il ne devrait pas être nécessaire de le modifier.
- La table est ordonnée par
ORDER BY (ServiceName, SeverityText, toUnixTimestamp(Timestamp), TraceId). Cela signifie que les requêtes seront optimisées pour les filtres sur ServiceName, SeverityText, Timestamp et TraceId : les colonnes placées plus tôt dans la liste seront filtrées plus rapidement que les suivantes ; par exemple, un filtrage sur ServiceName sera nettement plus rapide qu’un filtrage sur TraceId. Vous devez modifier cet ordre en fonction des schémas d’accès attendus ; voir Choisir une clé primaire.
- Le schéma ci-dessus applique
ZSTD(1) aux colonnes. Cela offre la meilleure compression pour les logs. Vous pouvez augmenter le niveau de compression ZSTD (au-dessus de la valeur par défaut de 1) pour obtenir une meilleure compression, bien que cela soit rarement avantageux. Augmenter cette valeur entraînera une surcharge CPU plus importante au moment de l’insert (pendant la compression), même si la décompression (et donc les requêtes) devrait rester comparable. Consultez ce lien pour plus de détails. Un encodage delta supplémentaire est appliqué à Timestamp afin de réduire sa taille sur disque.
- Notez que
ResourceAttributes, LogAttributes et ScopeAttributes sont des maps. Il est important de bien comprendre les différences entre ces éléments. Consultez “Utiliser les maps” pour savoir comment accéder à ces maps et optimiser l’accès aux clés qu’elles contiennent.
- La plupart des autres types ici, par exemple
ServiceName en LowCardinality, sont optimisés. Notez que Body, qui est du JSON dans nos logs d’exemple, est stocké sous forme de String.
- Des bloom filters sont appliqués aux clés et valeurs des maps, ainsi qu’à la colonne
Body. Ils visent à améliorer le temps d’exécution des requêtes qui accèdent à ces colonnes, mais ne sont généralement pas nécessaires. Consultez Indices secondaires / data skipping indices.
Là encore, cela s’alignera sur les colonnes correspondant à la spécification officielle d’OTel pour les traces, documentée ici. Le schéma utilise ici bon nombre des mêmes paramètres que le schéma de logs ci-dessus, avec des colonnes Link supplémentaires propres aux spans.
Nous recommandons aux utilisateurs de désactiver la création automatique du schéma et de créer leurs tables manuellement. Cela permet de modifier les clés primaire et secondaire, ainsi que d’ajouter des colonnes supplémentaires pour optimiser les performances des requêtes. Pour plus de détails, consultez Schema design.
Optimisation des insertions
- (1) Si le nœud qui reçoit les données rencontre un problème, la requête d’insertion expire (ou renvoie une erreur plus spécifique) et ne reçoit pas d’accusé de réception.
- (2) Si les données ont bien été écrites par le nœud, mais que l’accusé de réception ne peut pas être renvoyé à l’émetteur de la requête en raison d’interruptions réseau, l’émetteur recevra soit un délai d’expiration, soit une erreur réseau.
Du point de vue du collector, il peut être difficile de distinguer (1) de (2). Cependant, dans les deux cas, l’insertion non acquittée peut simplement être retentée immédiatement. Tant que la requête d’insertion retentée contient les mêmes données dans le même ordre, ClickHouse ignorera automatiquement cette nouvelle tentative si l’insertion d’origine (non acquittée) a réussi.
Nous recommandons aux utilisateurs d’utiliser le batch processor présenté dans les configurations précédentes pour répondre à ces exigences. Cela garantit que les insertions sont envoyées sous forme de lots cohérents de lignes respectant les conditions ci-dessus. Si un collector doit traiter un débit élevé (événements par seconde) et qu’au moins 10 000 événements peuvent être envoyés à chaque insertion, c’est généralement le seul regroupement par lots nécessaire dans le pipeline. Des valeurs allant jusqu’à 100 000 peuvent être utilisées si la mémoire le permet. Dans ce cas, le collector flush les lots avant que le timeout du batch processor ne soit atteint, ce qui garantit une faible latence de bout en bout du pipeline ainsi qu’une taille de lot cohérente.
Utiliser les insertions asynchrones
timeout du batch processor. Cela peut poser problème, et c’est précisément dans ce type de situation que les insertions asynchrones deviennent nécessaires. Ce cas se présente généralement lorsque des collectors dans le rôle d’agent sont configurés pour envoyer directement vers ClickHouse. Les passerelles, en jouant un rôle d’agrégation, peuvent atténuer ce problème ; voir Scaling with Gateways.
S’il n’est pas possible de garantir de gros lots, vous pouvez déléguer le regroupement par lots à ClickHouse en utilisant les insertions asynchrones. Avec les insertions asynchrones, les données sont d’abord insérées dans un buffer, puis écrites ultérieurement dans le stockage de la base de données, donc de manière asynchrone.
Lorsque les insertions asynchrones sont activées, quand ClickHouse ① reçoit une insert query, les données de la requête sont ② immédiatement écrites dans un buffer en mémoire. Lors du ③ prochain flush du buffer, les données du buffer sont triées et écrites sous forme de part dans le stockage de la base de données. Notez que les données ne peuvent pas être interrogées avant d’avoir été flushées vers le stockage de la base de données ; le flush du buffer est configurable.
Pour activer les insertions asynchrones pour le collector, ajoutez async_insert=1 à la chaîne de connexion. Nous recommandons d’utiliser wait_for_async_insert=1 (valeur par défaut) afin d’obtenir des garanties de livraison ; voir ici pour plus de détails.
Les données d’une async insert sont insérées une fois le buffer ClickHouse flushé. Cela se produit soit lorsque async_insert_max_data_size est dépassé, soit après async_insert_busy_timeout_ms millisecondes à partir de la première INSERT query. Si async_insert_stale_timeout_ms est défini sur une valeur non nulle, les données sont insérées après async_insert_stale_timeout_ms milliseconds depuis la dernière query. Vous pouvez ajuster ces settings pour contrôler la latence de bout en bout de votre pipeline. D’autres settings permettant d’ajuster le flush du buffer sont documentés ici. En règle générale, les valeurs par défaut conviennent.
Envisagez les insertions asynchrones adaptativesDans les cas où un petit nombre d’agents est utilisé, avec un débit faible mais des exigences strictes en matière de latence de bout en bout, les insertions asynchrones adaptatives peuvent être utiles. En règle générale, elles ne s’appliquent pas aux cas d’usage d’observability à haut débit, comme ceux observés avec ClickHouse. async_insert_deduplicate.
Tous les détails sur la configuration de cette fonctionnalité sont disponibles ici, avec une analyse approfondie ici.
Architectures de déploiement
- Mise à l’échelle des connexions - Chaque agent établit une connexion à ClickHouse. Bien que ClickHouse puisse maintenir des centaines, voire des milliers, de connexions d’insertion concurrentes, cela finit par devenir un facteur limitant et par rendre les insertions moins efficaces : ClickHouse consacre alors davantage de ressources au maintien de ces connexions. L’utilisation de passerelles réduit le nombre de connexions et améliore l’efficacité des insertions.
- Traitement à la périphérie - Dans cette architecture, toute transformation ou tout traitement des événements doit être effectué à la périphérie ou dans ClickHouse. En plus d’être contraignant, cela peut impliquer soit des vues matérialisées ClickHouse complexes, soit le déplacement d’une part importante du calcul vers la périphérie, où les ressources sont limitées et les services critiques peuvent être affectés.
- Petits lots et latences - Les collectors agents peuvent, individuellement, collecter très peu d’événements. Cela signifie généralement qu’ils doivent être configurés pour envoyer leurs données à intervalle défini afin de respecter les SLA de livraison. Le collector peut alors envoyer de petits lots à ClickHouse. Bien que ce soit un inconvénient, il peut être atténué avec les insertions asynchrones - voir Optimiser les insertions.
Mise à l’échelle avec des passerelles
Estimation des ressources
