一文搞懂 SAE 日志采集架构

日志，对于一个程序的重要程度不言而喻。无论是作为排查问题的手段，记录关键节点信息，或者是预警，配置监控大盘等等，都扮演着至关重要的角色。是每一类，甚至每一个应用程序都需要记录和查看的重要内容。而在云原生时代，日志采集无论是在采集方案，还是在采集架构上，都会和传统的日志采集有一些差异。我们汇总了一下在日志的采集过程中，经常会遇到一些实际的通用问题，例如：

• 部署在 K8s 的应用，磁盘大小会远远低于物理机，无法把所有日志长期存储，又有查询历史数据的诉求
• 日志数据非常关键，不允许丢失，即使是在应用重启实例重建后
• 希望对日志做一些关键字等信息的报警，以及监控大盘
• 权限管控非常严格，不能使用或者查询例如 SLS 等日志系统，需要导入到自己的日志采集系统
• JAVA，PHP 等应用的异常堆栈会产生换行，把堆栈异常打印成多行，如何汇总查看呢？

那么在实际生产环境中，用户是如何使用日志功能采集的呢？而面对不同的业务场景，不同的业务诉求时，采用哪种采集方案更佳呢？Serverless 应用引擎 SAE（Serverless App Engine）作为一个全托管、免运维、高弹性的通用 PaaS 平台，提供了 SLS 采集、挂载 NAS 采集、Kafka 采集等多种采集方式，供用户在不同的场景下使用。本文将着重介绍各种日志采集方式的特点，最佳使用场景，帮助大家来设计合适的采集架构，并规避一些常见的问题。

SAE 的日志采集方式

SLS 采集架构

SLS 采集日志是 SAE 推荐的日志采集方案。一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等能力。

SAE 内置集成了 SLS 的采集，可以很方便的将业务日志，容器标准输出采集到 SLS 。SAE 集成 SLS 的架构图如下图所示：

• SAE 会在 pod 中，挂载一个 logtail （SLS 的采集器）的 Sidecar。
• 然后将客户配置的，需要采集的文件或者路径，用 volume 的形式，给业务 Container 和 logtail Sidecar 共享。这也是 SAE 日志采集不能配置/home/admin 的原因。因为服务的启动容器是放在/home/admin 中，挂载 volume 会覆盖掉启动容器。
• 同时 logtail 的数据上报，是通过 SLS 内网地址去上报，因此无需开通外网。
• SLS 的 Sidecar 采集，为了不影响业务 Container 的运行，会设置资源的限制，例如 CPU 限制在 0.25C ，内存限制在 100M。

SLS 适合大部分的业务场景，并且支持配置告警和监控图。绝大多数适合直接选择 SLS 就可以了。

NAS 采集架构

NAS 是一种可共享访问、弹性扩展、高可靠以及高性能的分布式文件系统。本身提供高吞吐和高 IOPS 的同时支持文件的随机读写和在线修改。比较适合日志场景。如果想把比较多或比较大的日志在本地留存，可以