多租户隔离

然而日志采集并不仅仅是单一用户/应用需要完成的工作，例如一个典型的服务器上需要采集的日志数据有：资源类 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 资源无法全部满足时，数据量较高的配置会占用较多的执行时间，导致其他数据较少的配置获取资源的概率降低。