Goals

Evaluate various alternative collector options for candidates to replace fluentd

Non-Goals

Motivation

The current collector option is resource expensive to run on worker nodes. This means it reduces a customer's available resources for running their own workloads. The collector should minimize its footprint

Alternatives

Acceptance Criteria

• Developer documentation providing the pros and cons of the evaluated collector
• Community Strength
• Benchmarking: throughput, memory, cpu
• Supports input: tail, journal
• Output support: elasticsearch, loki, syslog, cloudwatch, fluent forward, splunk, stackdriver, azure, kafka
• Filtering options
• Plugability
• Scriptability (e.g. lua)
• Productization support (e.g. RH base image )
• Multi-line support (e.g java stack trace)
• JSON parsing
• Regex support (e.g. log level)
• Observability (e.g. prometheus metrics)
• Provision for supporting Flow Control, Rate Limiting of  container logs

Risk and Assumptions

Documentation Considerations

Open Questions

Additional Notes