FerroStash
Pipeline de logs compatível com Logstash nativo em Rust
Um pipeline de logs e eventos nativo em Rust e compatível com Logstash. Ele ingere, transforma e roteia eventos pelo mesmo modelo input → filter → output do Logstash, interpretando nativamente a DSL pipeline.conf do Logstash (e um formato YAML equivalente), sem JVM. Um único binário estático (cerca de 14 MB) inicia em milissegundos e usa dezenas de MB de RAM, permitindo concentrar muito mais shippers por host.
Enquanto um pipeline Logstash típico mantém cerca de um gigabyte de heap JVM e leva dezenas de segundos para iniciar, FerroStash roda como um único binário estático. A linha v1.0 implementa o subconjunto comum em produção do conjunto de plugins do Logstash 9.x — cerca de 88 percent dos plugins incluídos (98 de 111), com peso maior no hot path de parsing e filtragem. Inputs incluem beats, file, tcp, udp, http, syslog, kafka, redis, s3, sqs, jdbc, elasticsearch e cloudwatch; filters incluem grok, dissect, kv, json, mutate, date, geoip, dns, csv, xml, useragent, cidr, fingerprint, translate, aggregate e throttle, além de um filtro de script nativo em estilo Painless; outputs incluem elasticsearch / opensearch, kafka, s3, http, tcp, udp, file, redis, sqs, sns, cloudwatch, email e datadog; codecs incluem json, json_lines, multiline, cef, netflow, avro, msgpack e protobuf. Para confiabilidade, oferece uma fila persistente opcional em disco com entrega at-least-once e uma dead-letter queue (fsync opcional para durabilidade contra perda de energia) e uma API de monitoramento embutida para estatísticas de nó e pipeline. Escopo honesto: é compatível com config/pipeline do Logstash, não um drop-in 100 percent idêntico byte a byte — a cobertura é por plugin, um plugin coberto pode implementar um subconjunto de suas opções, e uma config que usa um plugin ausente falha rapidamente no carregamento.
O problema
O Logstash é um pipeline de eventos e logs flexível, mas a implantação típica consome cerca de um gigabyte de heap da JVM, leva dezenas de segundos para iniciar e executa um runtime de agente JVM separado por shipper. Isso limita a quantidade de shippers que cabem em um host e pesa bastante na memória e no tempo de inicialização, especialmente em contêineres. A necessidade é manter os investimentos existentes no pipeline.conf e em plugins, eliminando o footprint da JVM e rodando de forma leve.
Como funciona
- 1
Executa input → filter → output nativamente
O FerroStash ingere, transforma e roteia eventos usando o mesmo modelo input → filter → output do Logstash. Ele analisa a DSL pipeline.conf do Logstash (e um formato YAML equivalente) nativamente — sem uma JVM e sem um runtime de agente separado — e roda como um único binário estático.
- 2
Implementa os plugins comuns em produção
A linha v1.0 implementa 98 dos 111 plugins integrados do Logstash 9.x (cerca de 88%), com foco no hot path de análise e filtragem. Ela cobre os principais inputs, filters, outputs e codecs, e inclui um filtro de script nativo no estilo Painless. Uma configuração que usa um plugin ausente falha rapidamente no carregamento, portanto não há descarte silencioso.
- 3
Confiabilidade e monitoramento
Uma fila persistente em disco opcional oferece entrega at-least-once (separação de cursor read/ack e checkpoint após ack de saída) e uma dead-letter queue, com fsync opcional para resiliência contra perda de energia. Uma API de monitoramento integrada expõe estatísticas de nó e pipeline.
Destaques
Compatível com config/pipeline do Logstash — interpreta nativamente a DSL pipeline.conf (e YAML) e implementa cerca de 88% dos plugins incluídos no Logstash 9.x (98 de 111).
Binário estático único (~14 MB), sem JVM; inicialização em ms e dezenas de MB de RAM permitem concentrar mais shippers por host.
Confiabilidade: fila persistente em disco (at-least-once + DLQ, fsync opcional) e API de monitoramento embutida. Escopo honesto — compatível com config, não um drop-in idêntico byte a byte.
O que está incluído
- AMI do Amazon Linux 2023 com hardening (arm64 / Graviton, roda em classes t4g / c7g / m7g / r7g)
- Um único binário estático em Rust (cerca de 14 MB, sem JVM, inicialização em milissegundos) que implementa um pipeline de logs e eventos compatível com o Logstash
- Um parser nativo para a DSL pipeline.conf do Logstash and um formato YAML equivalente
- 98 dos 111 plugins integrados do Logstash 9.x (cerca de 88%): inputs (beats, file, tcp, udp, http, syslog, kafka, redis, s3, sqs, jdbc, elasticsearch, cloudwatch e mais), filters (grok, dissect, kv, json, mutate, date, geoip e mais, além de um filtro de script no estilo Painless), outputs (elasticsearch / opensearch, kafka, s3, http, file e mais) e codecs (json, json_lines, multiline, cef, netflow, avro, msgpack, protobuf)
- Uma fila persistente em disco opcional com entrega at-least-once e uma dead-letter queue (fsync opcional)
- Uma API de monitoramento integrada que expõe estatísticas de nó e pipeline
- Sem plano de controle separado, sem envio de telemetria externa e sem verificação de chave de licença (cobrado por instância por hora através da sua fatura da AWS)
Casos de uso
Manter os investimentos existentes no pipeline.conf e em plugins do Logstash enquanto roda de forma leve, sem o footprint da JVM
Ambientes de contêiner ou edge onde a memória e o tempo de inicialização são restrições e você deseja mais shippers por host
Pipelines que analisam logs com grok / dissect / json e os roteiam para Elasticsearch / OpenSearch / Kafka / S3 e similares
Execução de um pipeline de logs inteiramente dentro de sua própria VPC, sem plano de controle separado e sem envio de telemetria externa
FAQ
Qual é o nível de compatibilidade com o Logstash?
O FerroStash é compatível com as configurações e pipelines do Logstash, não sendo um drop-in 100% idêntico byte a byte. Ele analisa a DSL pipeline.conf nativamente e implementa 98 dos 111 plugins integrados do Logstash 9.x (cerca de 88%). A cobertura ocorre em nível de plugin, e um plugin suportado pode implementar apenas um subconjunto de suas opções. Uma configuração que utiliza um plugin ausente falha rapidamente no carregamento.
Ele precisa de uma JVM?
Não. O FerroStash é executado como um único binário estático em Rust (cerca de 14 MB), sem JVM e sem um runtime de agente separado. Ele inicia em milissegundos e consome apenas dezenas de MB de RAM, permitindo alocar mais shippers por host.
Existem garantias de entrega?
Uma fila persistente em disco opcional oferece entrega at-least-once (separação de cursor read/ack e checkpoint após ack de saída) e uma dead-letter queue. O fsync opcional pode ser ativado para resiliência contra perda de energia.
Isso substitui um serviço da AWS?
O Logstash é um projeto de código aberto da Elastic e não é um serviço da AWS. O FerroStash é um produto autogerenciado que executa esse pipeline de logs compatível com o Logstash em suas próprias instâncias do Amazon EC2. Ele é fornecido como uma AMI padrão do Amazon Linux 2023 que você executa dentro de sua própria VPC.
Como é feita a cobrança?
Uma taxa horária de software da AMI somada ao custo da instância EC2 que você escolher (classe t4g / c7g / m7g / r7g, Arm). Tarifado de acordo com o tipo de instância, sem plano de controle separado, sem envio de telemetria externa e sem verificação de chave de licença.
Modelo de precificação
Taxa horária de software + EC2 (classe t4g / c7g / m7g / r7g, Arm). Medição por tipo de instância.
Outros produtos S4
S4 — Squished S3
Gateway transparente de compressão S3 com GPU
S4 Logs
Arquive CloudWatch Logs em S3 com zstd
S4 Metrics
Controle a cardinalidade de métricas do CloudWatch