作者：牛通(奇卫)
日志，关于一个程序的重要程度显而易见。无论是作为排查问题的手法，记载要害节点信息，或许是预警，装备监控大盘等等，都扮演着至关重要的角色。是每一类，乃至每一个运用程序都需求记载和检查的重要内容。而在云原生时代，日志收集无论是在收集计划，还是在收集架构上，都会和传统的日志收集有一些差异。我们汇总了一下在日志的收集过程中，经常会遇到一些实践的通用问题，例如：
- 布置在 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 渠道，要点处理用户的效率和本钱问题。依据事务数据处理需求，能在短时间内快速创立大量核算使命，并且在使命完成后快速释放核算资源。支撑单机、广播、并行核算、分片使命模型，守时、超时重试、堵塞策略等使命中心特性，比开源使命结构运用更便利（对代码无侵入）、更节约（使命运转完当即释放资源）、更安稳（失利主动重试）、更透明（可视化监控报警）、更省心（免运维）。
更多产品内容，点击此处检查~
