关于阿里云:一文搞懂-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 的同时反对文件的随机读写和在线批改。比拟适宜日志场景。如果想把比拟多或比拟大的日志在本地留存，能够通过挂载 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 应用的就是这种模式，具体步骤如下图所示：

1. 当日志的 event log 写入前会判断是否达到文件设置最大容量，如果没达到，则实现写入，如果达到了，则会进入阶段二
2. 首先敞开以后 currentlyActiveFile 指向的文件，之后对原文件进行重命名，并新建一个文件，这个文件的名字和之前 currentlyActiveFile 指向的名字统一
3. 把 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）信息保留到本地，如果遇到服务器意外敞开、过程解体等异常情况时，会从上一次记录的地位开始采集数据，尽量保证数据不会失落。

然而这并不能保障日志肯定不会失落。在一些极其场景下，是有可能造成日志采集失落的，例如：

1. K8s pod 过程解体，liveness 间断失败等异样导致 pod 重建
2. 日志轮转速度极快，例如 1 秒轮转 1 次。
3. 日志采集速度长期无奈达到日志产生速度。

针对场景 2，3，须要去查看本身的应用程序，是否打印了过多不必要的日志，或者日志轮转设置是否异样。因为失常状况下，这些状况不应该呈现。针对场景 1，如果对日志要求十分严格，在 pod 重建后也不能失落的话，能够将挂载的 NAS 作为日志保留门路，这样即便在 pod 重建后，日志也不会失落。

总结

本文着重介绍了 SAE 提供了多种日志采集计划，以及相干的架构，场景应用特点。总结起来三点：

1. SLS 采集适配性强，实用大多数场景
2. NAS 采集任何场景下都不会失落，适宜对日志要求十分严格的场景
3. Kafka 采集是对 SLS 采集的一种补充，有对日志须要二次加工解决，或者因为权限等起因无奈应用 SLS 的场景，能够抉择将日志采集到 Kafka 本人做收集解决。

阿里云重磅推出 SAE Job，反对 XXL-JOB、ElasticJob 工作的全托管，零革新迁徙。

目前炽热公测中，2022 年 9 月 1 日正式商业化免费，欢送大家应用！

SAE Job 作为面向工作的 Serverless PaaS 平台，重点解决用户的效率和老本问题。依据业务数据处理需要，能在短时间内疾速创立大量计算工作，并且在工作实现后疾速开释计算资源。反对单机、播送、并行计算、分片任务模型，定时、超时重试、阻塞策略等工作外围个性，比开源工作框架应用更不便（对代码无侵入）、更节俭（工作运行完立刻开释资源）、更稳固（失败主动重试）、更通明（可视化监控报警）、更省心（免运维）。

更多产品内容，点击此处查看~