FerroStash
Pipeline de logs compatible Logstash natif Rust
Un pipeline de logs et d’événements natif Rust, compatible Logstash. Il ingère, transforme et route les événements via le même modèle input → filter → output que Logstash, en analysant nativement le DSL Logstash pipeline.conf (et une forme YAML équivalente), sans JVM. Un binaire statique unique (environ 14 MB) démarre en millisecondes et consomme quelques dizaines de MB de RAM, ce qui permet de concentrer beaucoup plus de shippers par hôte.
Là où un pipeline Logstash typique conserve environ un gigaoctet de heap JVM et met des dizaines de secondes à démarrer, FerroStash s’exécute comme un binaire statique unique. La ligne v1.0 implémente le sous-ensemble couramment utilisé en production du jeu de plugins Logstash 9.x — environ 88 pour cent des plugins inclus (98 sur 111), avec un accent sur le hot path d’analyse et de filtrage. Les inputs incluent beats, file, tcp, udp, http, syslog, kafka, redis, s3, sqs, jdbc, elasticsearch et cloudwatch ; les filters incluent grok, dissect, kv, json, mutate, date, geoip, dns, csv, xml, useragent, cidr, fingerprint, translate, aggregate et throttle, plus un filtre script natif de style Painless ; les outputs incluent elasticsearch / opensearch, kafka, s3, http, tcp, udp, file, redis, sqs, sns, cloudwatch, email et datadog ; les codecs incluent json, json_lines, multiline, cef, netflow, avro, msgpack et protobuf. Pour la fiabilité, il propose une file persistante optionnelle sur disque avec livraison at-least-once et dead-letter queue (fsync opt-in pour la durabilité en cas de perte d’alimentation) ainsi qu’une API de monitoring intégrée pour les statistiques de nœud et de pipeline. Périmètre honnête : il est compatible avec les configs/pipelines Logstash, pas un drop-in 100 pour cent identique octet pour octet — la couverture est au niveau plugin, un plugin couvert peut implémenter un sous-ensemble de ses options, et une config utilisant un plugin manquant échoue rapidement au chargement.
Le problème
Logstash est un pipeline de logs et d'événements flexible, mais le déploiement habituel occupe environ un gigaoctet de heap JVM, prend des dizaines de secondes à démarrer et exécute un runtime d'agent JVM distinct par shipper. Cela limite le nombre de shippers pouvant être hébergés sur un hôte et pèse lourdement sur la mémoire et le temps de démarrage, en particulier dans les conteneurs. Le besoin est de conserver les investissements existants dans pipeline.conf et les plug-ins tout en se débarrassant de l'empreinte JVM pour fonctionner de manière légère.
Fonctionnement
- 1
Exécute input → filter → output nativement
FerroStash ingère, transforme et route les événements via le même modèle input → filter → output que Logstash. Il analyse nativement le DSL pipeline.conf de Logstash (ainsi qu'un format YAML équivalent) — sans JVM et sans runtime d'agent distinct — et s'exécute sous la forme d'un unique binaire statique.
- 2
Implémente les plug-ins couramment utilisés en production
La branche v1.0 implémente 98 des 111 plug-ins Logstash 9.x intégrés (environ 88 %), avec une priorité donnée au hot path d'analyse et de filtrage. Elle couvre les principaux inputs, filters, outputs et codecs, et intègre un filtre de script natif de style Painless. Une configuration utilisant un plug-in manquant échoue rapidement au chargement, de sorte qu'il n'y a pas de perte silencieuse.
- 3
Fiabilité et monitoring
Une file d'attente persistante sur disque en option fournit une livraison au moins une fois (at-least-once) (séparation des curseurs read/ack, checkpoint après ack d'output) et une dead-letter queue, avec un fsync optionnel pour la durabilité face aux pertes d'alimentation. Une API de monitoring intégrée expose les statistiques des nœuds et des pipelines.
Points forts
Compatible config/pipeline Logstash — analyse nativement le DSL pipeline.conf (et YAML) et implémente environ 88% des plugins Logstash 9.x inclus (98 sur 111).
Binaire statique unique (~14 MB), sans JVM ; démarrage en ms et quelques dizaines de MB de RAM permettent de concentrer davantage de shippers par hôte.
Fiabilité : file persistante sur disque (at-least-once + DLQ, fsync opt-in) et API de monitoring intégrée. Périmètre honnête — compatible config, pas un drop-in identique octet pour octet.
Ce qui est inclus
- AMI Amazon Linux 2023 durcie (arm64 / Graviton, s'exécute sur les classes t4g / c7g / m7g / r7g)
- Un unique binaire statique Rust (environ 14 MB, sans JVM, démarrage en ms) implémentant un pipeline de logs et d'événements compatible Logstash
- Un analyseur natif pour le DSL pipeline.conf de Logstash et un format YAML équivalent
- 98 des 111 plug-ins Logstash 9.x intégrés (environ 88 %) : inputs (beats, file, tcp, udp, http, syslog, kafka, redis, s3, sqs, jdbc, elasticsearch, cloudwatch, et plus), filters (grok, dissect, kv, json, mutate, date, geoip, et plus, plus un filtre de script de style Painless), outputs (elasticsearch / opensearch, kafka, s3, http, file, et plus), et codecs (json, json_lines, multiline, cef, netflow, avro, msgpack, protobuf)
- Une file d'attente persistante sur disque en option avec livraison au moins une fois (at-least-once) et une dead-letter queue (fsync optionnel)
- Une API de monitoring intégrée exposant les statistiques des nœuds et des pipelines
- Pas de plan de contrôle distinct, pas d'appel de télémétrie vers l'extérieur et pas de vérification de clé de licence (facturé par instance par heure via votre facture AWS)
Cas d'usage
Conserver les investissements existants dans pipeline.conf et les plug-ins Logstash tout en fonctionnant de manière légère et sans l'empreinte JVM
Environnements de conteneurs ou edge où la mémoire et le temps de démarrage sont des contraintes et où vous souhaitez plus de shippers par hôte
Pipelines qui analysent les logs avec grok / dissect / json et les routent vers Elasticsearch / OpenSearch / Kafka / S3 et similaires
Exécuter un pipeline de logs entièrement au sein de votre propre VPC, sans plan de contrôle distinct ni appel de télémétrie vers l'extérieur
FAQ
Dans quelle mesure est-il compatible avec Logstash ?
FerroStash est compatible avec la configuration et les pipelines de Logstash, mais n'est pas un drop-in 100 % identique à l'octet près. Il analyse nativement le DSL pipeline.conf et implémente 98 des 111 plug-ins Logstash 9.x intégrés (environ 88 %). La couverture se situe au niveau des plug-ins, et un plug-in pris en charge peut n'implémenter qu'un sous-ensemble de ses options. Une configuration utilisant un plug-in manquant échoue rapidement au chargement.
Nécessite-t-il une JVM ?
Non. FerroStash s'exécute sous la forme d'un unique binaire statique Rust (environ 14 MB) sans JVM ni runtime d'agent distinct. Il démarre en quelques millisecondes et consomme des dizaines de MB de RAM, ce qui permet d'héberger plus de shippers par hôte.
Existe-t-il des garanties de livraison ?
Une file d'attente persistante sur disque en option fournit une livraison au moins une fois (at-least-once) (séparation des curseurs read/ack, checkpoint après ack d'output) et une dead-letter queue. L'option fsync peut être activée pour la durabilité face aux pertes d'alimentation.
S'agit-il d'un remplacement pour un service AWS ?
Logstash est un projet open-source d'Elastic et n'est pas un service AWS. FerroStash est un produit autogéré qui exécute ce pipeline de logs compatible Logstash sur vos propres instances Amazon EC2. Il est fourni sous la forme d'une AMI Amazon Linux 2023 normale que vous exécutez dans votre propre VPC.
Comment est-il facturé ?
Des frais logiciels horaires pour l'AMI plus l'instance EC2 que vous choisissez (classe t4g / c7g / m7g / r7g, Arm). Facturé selon le type d'instance, sans plan de contrôle distinct, sans appel de télémétrie vers l'extérieur et sans vérification de clé de licence.
Modèle de tarification
Frais logiciel horaires + EC2 (classe t4g / c7g / m7g / r7g, Arm). Facturation à l’usage par type d’instance.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch