SLS 采集日志是 SAE 推荐的日志采集方案。一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等能力。
SLS 适合大部分的业务场景，并且支持配置告警和监控图。绝大多数适合直接选择 SLS 就可以了。
NAS 是一种可共享访问、弹性扩展、高可靠以及高性能的分布式文件系统。本身提供高吞吐和高 IOPS 的同时支持文件的随机读写和在线修改。比较适合日志场景。如果想把比较多或比较大的日志在本地留存，可以通过挂载 NAS，然后将日志文件的保存路径指向 NAS 的挂载目录即可。NAS 挂载到 SAE 不牵扯到太多技术点和架构，这里就略过不做过多的介绍了。
NAS 作为日志采集时，可以看作是一块本地盘，即使实例崩溃重建等等各种以外情况，也都不会出现日志丢失的情况，对于非常重要，不允许丢失数据的场景，可以考虑此方案。
用户本身也可以将日志文件的内容采集到 Kafka，然后通过消费 Kafka 的数据，来实现日志的采集。后续用户可以结合自身的需求，将 Kafka 中的日志导入到 ElasticSearch ，或者程序去消费 Kafka 数据做处理等。
Kafka 采集算是对 SLS 采集的一种补充完善。实际生产环境下，有些客户对权限的控制非常严格，可能只有 SAE 的权限，却没有 SLS 的权限，因此需要把日志采集到 Kafka 做后续的查看，或者本身有需求对日志做二次处理加工等场景，也可以选择 Kafka 日志采集方案。 下面是一份基础的 vector.toml 配置：
重要的参数解析：
下面是配置了 vector 采集的元数据到 Prometheus，在 Grafana 的监控大盘处配置了 vector 的元数据的一些采集监控图：
在实际使用中，可以根据自身的业务诉求选择不同的日志采集方式。本身 logback 的日志采集策略，需要对文件大小和文件数量做一下限制，不然比较容易把 pod 的磁盘打满。以 JAVA 为例，下面这段配置，会保留最大 7 个文件，每个文件大小最大 100M。
这段 log4j 的配置，是一种比较常见的日志轮转配置。
copytruncate 模式的思路是把正在输出的日志拷(copy)一份出来，再清空(trucate)原来的日志。
目前主流组件的支持程度如下：
下面介绍一下客户实际生产环境中的一些真实场景。
最后，通过程序中日志的一些关键字,或者一些其他规则，例如 200 状态码比例等进行了报警配置。
通过 Nginx 的日志完成监控大盘的配置。
很多时候，我们需要采集日志，并不是单纯的一行一行采集，而是需要把多行日志合并成一行进行采集，例如 JAVA 的异常日志等。这个时候就需要用到日志合并功能了。
在 SLS 中，有多行模式的采集模式，这个模式需要用户设置一个正则表达式，用来做多行合并。 vector 采集也有类似的参数，multiline.start_pattern 用于设置新行的正则，符合此正则会被认为是一个新行。可以结合 multiline.mode 参数一起使用。更多参数请参看vector官网。
无论是 SLS 采集和 vector 采集到 Kafka 为了保证采集日志不丢失。都会将采集的点位（CheckPoint）信息保存到本地，如果遇到服务器意外关闭、进程崩溃等异常情况时，会从上一次记录的位置开始采集数据，尽量保证数据不会丢失。
但是这并不能保证日志一定不会丢失。在一些极端场景下，是有可能造成日志采集丢失的，例如：
本文着重介绍了 SAE 提供了多种日志采集方案，以及相关的架构，场景使用特点。总结起来三点：
阿里云重磅推出 SAE Job，支持 XXL-JOB、ElasticJob 任务的全托管，零改造迁移。
目前火热公测中，2022 年 9 月 1 日正式商业化收费，欢迎大家使用！
更多内容关注 Serverless 微信公众号（ID：serverlessdevs），汇集 Serverless 技术最全内容，定期举办 Serverless 活动、直播，用户最佳实践。 2023年2月28日0时53分22秒