共计 5684 个字符，预计需要花费 15 分钟才能阅读完成。
日志，对于一个程序的重要水平显而易见。无论是作为排查问题的伎俩，记录要害节点信息，或者是预警，配置监控大盘等等，都扮演着至关重要的角色。是每一类，甚至每一个应用程序都须要记录和查看的重要内容。而在云原生时代，日志采集无论是在采集计划，还是在采集架构上，都会和传统的日志采集有一些差别。咱们汇总了一下在日志的采集过程中，常常会遇到一些理论的通用问题，例如：
- 部署在 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 的同时反对文件的随机读写和在线批改。比拟适宜日志场景。如果想把比拟多或比拟大的日志在本地留存，能够通过挂载 NAS，而后将日志文件的保留门路指向 NAS 的挂载目录即可。NAS 挂载到 SAE 不牵扯到太多技术点和架构，这里就略过不做过多的介绍了。
NAS 作为日志采集时，能够看作是一块本地盘，即便实例解体重建等等各种以外状况，也都不会呈现日志失落的状况，对于十分重要，不容许失落数据的场景，能够思考此计划。
Kafka 采集架构
用户自身也能够将日志文件的内容采集到 Kafka，而后通过生产 Kafka 的数据，来实现日志的采集。后续用户能够联合本身的需要，将 Kafka 中的日志导入到 ElasticSearch，或者程序去生产 Kafka 数据做解决等。
日志采集到 Kafka 自身有多种形式，例如最常见的 logstach，比拟轻量级的采集组建 filebeat，vector 等等。SAE 应用的采集组件是 vector，SAE 集成 vector 的架构图如下图所示：
- SAE 会在 pod 中，挂载一个 logtail（vector 采集器）的 Sidecar。
- 而后将客户配置的，须要采集的文件或者门路，用 volume 的模式，给业务 Container 和 vector Sidecar 共享
- vector 会将采集到的日志数据定时发送到 Kafka。vector 自身有比拟丰盛的参数设置，能够设置采集数据压缩，数据发送距离，采集指标等等。
Kafka 采集算是对 SLS 采集的一种补充欠缺。理论生产环境下，有些客户对权限的管制十分严格，可能只有 SAE 的权限，却没有 SLS 的权限，因而须要把日志采集到 Kafka 做后续的查看，或者自身有需要对日志做二次解决加工等场景，也能够抉择 Kafka 日志采集计划。
上面是一份根底的 vector.toml 配置：
data_dir = "/etc/vector"
[sinks.sae_logs_to_kafka]
type = "kafka"
bootstrap_servers = "kafka_endpoint"
encoding.codec = "json"
encoding.except_fields = ["source_type","timestamp"]
inputs = ["add_tags_0"]
topic = "{{topic}}"
[sources.sae_logs_0]
type = "file"
read_from = "end"
max_line_bytes = 1048576
max_read_bytes = 1048576
multiline.start_pattern = '^[^\s]'
multiline.mode = "continue_through"
multiline.condition_pattern = '(?m)^[\s|\W].*$|(?m)^(Caused|java|org|com|net).+$|(?m)^\}.*$'
multiline.timeout_ms = 1000
include = ["/sae-stdlog/kafka-select/0.log"]
[transforms.add_tags_0]
type = "remap"
inputs = ["sae_logs_0"]
source = '.topic ="test1"'
[sources.internal_metrics]
scrape_interval_secs = 15
type = "internal_metrics_ext"
[sources.internal_metrics.tags]
host_key = "host"
pid_key = "pid"
[transforms.internal_metrics_filter]
type = "filter"
inputs = ["internal_metrics"]
condition = '.tags.component_type =="file"|| .tags.component_type =="kafka"|| starts_with!(.name,"vector")'
[sinks.internal_metrics_to_prom]
type = "prometheus_remote_write"
inputs = ["internal_metrics_filter"]
endpoint = "prometheus_endpoint"重要的参数解析：
- multiline.start_pattern 是当检测到合乎这个正则的行时，会当作一条新的数据处
- multiline.condition_pattern 是检测到合乎这个正则的行时，会和上一行做行合并，当作一条解决
- sinks.internal_metrics_to_prom 配置了之后，会将配置一些 vector 的采集元数据上报到 prometheus
上面是配置了 vector 采集的元数据到 Prometheus，在 Grafana 的监控大盘处配置了 vector 的元数据的一些采集监控图：
最佳实际
在理论应用中，能够依据本身的业务诉求抉择不同的日志采集形式。自身 logback 的日志采集策略，须要对文件大小和文件数量做一下限度，不然比拟容易把 pod 的磁盘打满。以 JAVA 为例，上面这段配置，会保留最大 7 个文件，每个文件大小最大 100M。
<appender name="TEST"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${user.home}/logs/test/test.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
<fileNamePattern>${user.home}/logs/test/test.%i.log</fileNamePattern>
<minIndex>1</minIndex>
<maxIndex>7</maxIndex>
</rollingPolicy>
<triggeringPolicy
class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<maxFileSize>100MB</maxFileSize>
</triggeringPolicy>
<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
<charset>UTF-8</charset>
<pattern>%d{yyyy-MM-dd HH:mm:ss}|%msg%n</pattern>
</encoder>
</appender>这段 log4j 的配置，是一种比拟常见的日志轮转配置。
常见的日志轮转形式有两种，一种是 create 模式，一种是 copytruncate 模式。而不同的日志采集组件，对两者的反对水平会存在一些区别。
create 模式是重命名原日志文件，创立新的日志文件替换。log4j 应用的就是这种模式，具体步骤如下图所示：
- 当日志的 event log 写入前会判断是否达到文件设置最大容量，如果没达到，则实现写入，如果达到了，则会进入阶段二
- 首先敞开以后 currentlyActiveFile 指向的文件，之后对原文件进行重命名，并新建一个文件，这个文件的名字和之前 currentlyActiveFile 指向的名字统一
- 把 currentlyActiveFile 指向的文件变为阶段二新创建的文件
copytruncate 模式的思路是把正在输入的日志拷 (copy) 一份进去，再清空 (trucate) 原来的日志。
目前支流组件的反对水平如下：
理论案例演示
上面介绍一下客户理论生产环境中的一些实在场景。
某客户 A 通过日志轮转设置程序的日志，并将日志采集到 SLS。并通过关键字配置相干报警，监控大盘等。
首先通过 log4j 的配置，使日志文件最多放弃 10 个，每个大小 200M，放弃磁盘的监控，日志文件保留在 /home/admin/logs 门路下。这里不进行过多介绍了，能够最佳实际场景介绍的配置。
随后通过 SAE 的 SLS 日志采集性能，把日志采集到 SLS 中。
最初，通过程序中日志的一些关键字, 或者一些其余规定，例如 200 状态码比例等进行了报警配置。
通过 Nginx 的日志实现监控大盘的配置。
常见问题
日志合并介绍
很多时候，咱们须要采集日志，并不是单纯的一行一行采集，而是须要把多行日志合并成一行进行采集，例如 JAVA 的异样日志等。这个时候就须要用到日志合并性能了。
在 SLS 中，有多行模式的采集模式，这个模式须要用户设置一个正则表达式，用来做多行合并。
vector 采集也有相似的参数，multiline.start_pattern 用于设置新行的正则，合乎此正则会被认为是一个新行。能够联合 multiline.mode 参数一起应用。更多参数请参看 vector 官网。
日志采集失落剖析
无论是 SLS 采集和 vector 采集到 Kafka 为了保障采集日志不失落。都会将采集的点位（CheckPoint）信息保留到本地，如果遇到服务器意外敞开、过程解体等异常情况时，会从上一次记录的地位开始采集数据，尽量保证数据不会失落。
然而这并不能保障日志肯定不会失落。在一些极其场景下，是有可能造成日志采集失落的，例如：
- K8s pod 过程解体，liveness 间断失败等异样导致 pod 重建
- 日志轮转速度极快，例如 1 秒轮转 1 次。
-
日志采集速度长期无奈达到日志产生速度。
针对场景 2，3，须要去查看本身的应用程序，是否打印了过多不必要的日志，或者日志轮转设置是否异样。因为失常状况下，这些状况不应该呈现。针对场景 1，如果对日志要求十分严格，在 pod 重建后也不能失落的话，能够将挂载的 NAS 作为日志保留门路，这样即便在 pod 重建后，日志也不会失落。总结
本文着重介绍了 SAE 提供了多种日志采集计划，以及相干的架构，场景应用特点。总结起来三点：
- SLS 采集适配性强，实用大多数场景
- NAS 采集任何场景下都不会失落，适宜对日志要求十分严格的场景
- Kafka 采集是对 SLS 采集的一种补充，有对日志须要二次加工解决，或者因为权限等起因无奈应用 SLS 的场景，能够抉择将日志采集到 Kafka 本人做收集解决。
阿里云重磅推出 SAE Job，反对 XXL-JOB、ElasticJob 工作的全托管，零革新迁徙。
目前炽热公测中，2022 年 9 月 1 日正式商业化免费，欢送大家应用！
SAE Job 作为面向工作的 Serverless PaaS 平台，重点解决用户的效率和老本问题。依据业务数据处理需要，能在短时间内疾速创立大量计算工作，并且在工作实现后疾速开释计算资源。反对单机、播送、并行计算、分片任务模型，定时、超时重试、阻塞策略等工作外围个性，比开源工作框架应用更不便（对代码无侵入）、更节俭（工作运行完立刻开释资源）、更稳固（失败主动重试）、更通明（可视化监控报警）、更省心（免运维）。
https://www.aliyun.com/product/aliware/sae
更多内容关注 Serverless 微信公众号（ID：serverlessdevs），会集 Serverless 技术最全内容，定期举办 Serverless 流动、直播，用户最佳实际。