多租户隔离

然而日志采集并不仅仅是单一用户/应用需要完成的工作，例如一个典型的服务器上需要采集的日志数据有：资源类Metric数据、系统监控日志、Nginx访问数据、中间件请求数据、安全审计日志、各类应用中各个不同组件的日志等等；如果应用docker话，保守估计一个docker内的应用有6-7类日志，一台物理机运行50个docker，那即使采集docker内的日志就有300多种配置。

多租户隔离技术早在20世纪60年代的大型主机中就已经开始使用，发展到今天非常多的应用/系统都应用了该技术。在每种不同的应用/系统中对于多租户隔离都有不同的诠释。

首先需要搞清楚日志采集场景下的多租户隔离需具备哪些特性，这里我们总结以下5点：隔离性、公平性、可靠性、可控性、性价比

隔离性：多租户隔离最基本特性，多个采集工作之间互不影响，部分采集配置阻塞不影响其他正常采集 公平性：保证各个阶段（读取、处理、发送）多个配置之间的公平性，不能因为某个配置下日志写入量大而导致其他配置被处理的概率降低 可靠性：无论在何种场景，可靠性都至关重要，多租户隔离下，如果部分采集阻塞，agent可以暂停该配置采集，但恢复时需尽可能保证数据不丢失 可控性：可控性主要体现在资源和行为的可控，agent需要具备控制各个配置的资源占用在合理范围，并且具备控制采集速率、暂停/开启等行为 性价比：以上特性最终方案实现时最需要关注的就是性价比，如何在尽可能少的资源占用情况下实现尽可能优的多租户隔离方案才是技术可行性与适用性的关键

Logstash、Fluentd和Filebeat都属于pipeline的架构，根据语言不同，分别使用独立的线程/go runtime实现了pipeline功能，每个pipeline内部顺序执行，各个pipeline间互相独立运行，此种方式隔离性较好，实现较为简单，在小规模场景下较为适用。然而随着配置数量增长，相应的线程数/go runtime呈等比上升，在采集配置较多的情况下资源难以控制；而且由于各个pipeline间完全依赖底层（操作系统/go runtime）调度，当CPU资源无法全部满足时，数据量较高的配置会占用较多的执行时间，导致其他数据较少的配置获取资源的概率降低。