FerroStash Container

Build en container de FerroStash. Despliegue el pipeline de logs y eventos compatible con Logstash, nativo en Rust, como un único binario estático en Amazon EKS mediante el Helm chart incluido. Implementa el subconjunto habitual en producción de los plugins incluidos en Logstash 9.x (98 de 111, ~88%), interpreta la DSL `pipeline.conf` de forma nativa, no requiere JVM y arranca en milisegundos. Medición por pod-hour.

Mientras un pipeline típico de Logstash mantiene alrededor de un gigabyte de heap JVM y tarda decenas de segundos en arrancar, FerroStash Container ejecuta un único binario Rust como pod de EKS. Es el mismo binario de la línea v1.0 que la build AMI y cubre ~88% de los plugins incluidos en Logstash 9.x — las inputs incluyen beats, file, tcp, udp, http, syslog, kafka, redis, s3, sqs, jdbc, elasticsearch y cloudwatch; los filters incluyen grok, dissect, kv, json, mutate, date, geoip, dns, csv, xml, useragent, cidr, fingerprint, translate, aggregate, throttle y un script nativo de estilo Painless; los outputs incluyen elasticsearch / opensearch, kafka, s3, http, tcp, udp, file, redis, sqs, sns, cloudwatch, email y datadog; los codecs incluyen json, json_lines, multiline, cef, netflow, avro, msgpack y protobuf — todo impulsado por un `pipeline.conf` con plantilla renderizado en un `ConfigMap`. El Helm chart expone Elastic Beats en tcp/5044 y la API de monitorización en tcp/9600. El container verifica el entitlement mediante `RegisterUsage` al arrancar, excluye el filter opcional `ruby` y se admite en una topología de un solo nodo. Alcance honesto: es compatible con la configuración/pipeline de Logstash, no un drop-in 100% idéntico byte a byte.

Características destacadas