使用接入工具和缓存组件构建日志采集方案时，我们需要考虑的三个要素：时效性、数量级、复杂度。
• 时效性就是日志是否需要保障低时间延迟的传输，即我的设备和程序发生的事件需要在最短时间内拿到，还是可以允许有延迟，允许多长时间的延迟，几分钟还是几小时、或者半天也行。在方案制定过程中，时效性决定了是否要选择 Storm 实时流式方案。并作为测试过程的硬指标发挥作用，在模拟测试环节判断方案是否可用。
• 数量级是对于日志条目数和空间大小的衡量要素。运行出错才做事件记录的程序日志和每秒收集一次传感器日志在数据条目和文件占用的磁盘空间上是有很大区别的，进行采集的时候对于采集组件的要求也是不同的。数量级影响采集工具和缓存组件的选择，在方案制定过程中，每天采集的条目数超过百万时候就需要增加缓存组件了，条目数过亿时候就需要考虑如何平衡数据写入和数据查询的资源了。
• 最后一个要素就是复杂度，采集方案复杂度的产生主要由于原因：数量级、网络环境和采集工具。在数量级要求下，我们不得不添加缓存组件，把日志先写到 Kafka，再把日志写到 ES，增加一个 Kafka，就需要考虑 Kafka 的高可用问题和数据丢失问题，方案复杂度就提升了。方案的复杂度会影响方案的实施难度和维护难度，复杂度太高的方案即使设计出来也比较难落地。
考虑到这三种因素，我们在选择日志采集方案的时候要考虑到四个原则。
• 时效性要求不高，数量级也不大的情况优先采集文件，因为文件是最简单的也是最好采集的。
• 在日志生成的过程中解决解析问题，而不是在传输过程中，也就是在日志生成的过程中就约束它的格式，而不是考虑在传输过程中统一它的格式。大部分的采集工具都支持中间改写日志信息，增加内容或者拆分内容，这些操作实际上增加了采集方案的复杂度，也使得替换采集工具的成本增加，需要尽量避免。
• 不同的日志都有它的特点，那么是不是我们每一个具体的场景，都要选择不同的工具呢 ？我觉得是需要比较这个工具的特点带来的收益和增加工具来的的复杂度变化，如果新增工具不会对于原来的组件产生影响，也不会新增开发内容，运维上也能接受；那么是可以增加工具的，否则工具数量越少越好。
• 如果数据量比较大的话，就要考虑多级的缓存处理。引入缓存主要就是为了分离上下游操作，在不影响 ES 性能的情况下，写入更多的数据。
除了 Logstash 还有几种常用日志采集工具
• Rsyslog 一般用于收集系统的 syslog 日志；
• Fluentd 主要用于容器日志收集；
• Filebeat go 语言编写，专注于文件日志收集；
• Flume 在传输链路中增加了 Channel 组件作为数据缓存，可以把数据保存到磁盘上以避免数据丢失。
收集日志时除了收集工具还会用到缓存组件，主要的有 2 个：Kafka 消息队列和 Redis 内存数据库。
• Redis 主要用于小数据量低延迟要求的场景，多数情况下和 Storm 联用来处理实时数据。
• Kafka 是通用的消息队列组件，适合场景比较多，类似 Kafka 的消息队列组件还有几种。