介紹各種日志采集方式的特點(diǎn)及其最佳使用場(chǎng)景

日志，對(duì)于一個(gè)程序的重要程度不言而喻。無(wú)論是作為排查問(wèn)題的手段，記錄關(guān)鍵節(jié)點(diǎn)信息，或者是預(yù)警，配置監(jiān)控大盤(pán)等等，都扮演著至關(guān)重要的角色。是每一類(lèi)，甚至每一個(gè)應(yīng)用程序都需要記錄和查看的重要內(nèi)容。而在云原生時(shí)代，日志采集無(wú)論是在采集方案，還是在采集架構(gòu)上，都會(huì)和傳統(tǒng)的日志采集有一些差異。我們匯總了一下在日志的采集過(guò)程中，經(jīng)常會(huì)遇到一些實(shí)際的通用問(wèn)題，例如：

部署在 K8s 的應(yīng)用，磁盤(pán)大小會(huì)遠(yuǎn)遠(yuǎn)低于物理機(jī)，無(wú)法把所有日志長(zhǎng)期存儲(chǔ)，又有查詢歷史數(shù)據(jù)的訴求

日志數(shù)據(jù)非常關(guān)鍵，不允許丟失，即使是在應(yīng)用重啟實(shí)例重建后

希望對(duì)日志做一些關(guān)鍵字等信息的報(bào)警，以及監(jiān)控大盤(pán)

權(quán)限管控非常嚴(yán)格，不能使用或者查詢例如 SLS 等日志系統(tǒng)，需要導(dǎo)入到自己的日志采集系統(tǒng)

JAVA，PHP 等應(yīng)用的異常堆棧會(huì)產(chǎn)生換行，把堆棧異常打印成多行，如何匯總查看呢？

那么在實(shí)際生產(chǎn)環(huán)境中，用戶是如何使用日志功能采集的呢？而面對(duì)不同的業(yè)務(wù)場(chǎng)景，不同的業(yè)務(wù)訴求時(shí)，采用哪種采集方案更佳呢？Serverless 應(yīng)用引擎 SAE（Serverless App Engine）作為一個(gè)全托管、免運(yùn)維、高彈性的通用 PaaS 平臺(tái)，提供了 SLS 采集、掛載 NAS 采集、Kafka 采集等多種采集方式，供用戶在不同的場(chǎng)景下使用。本文將著重介紹各種日志采集方式的特點(diǎn)，最佳使用場(chǎng)景，幫助大家來(lái)設(shè)計(jì)合適的采集架構(gòu)，并規(guī)避一些常見(jiàn)的問(wèn)題。

SAE 的日志采集方式

Cloud Native

SLS 采集架構(gòu)

SLS 采集日志是 SAE 推薦的日志采集方案。一站式提供數(shù)據(jù)采集、加工、查詢與分析、可視化、告警、消費(fèi)與投遞等能力。

SAE 內(nèi)置集成了 SLS 的采集，可以很方便的將業(yè)務(wù)日志，容器標(biāo)準(zhǔn)輸出采集到 SLS 。SAE 集成 SLS 的架構(gòu)圖如下圖所示：

SAE 會(huì)在 pod 中，掛載一個(gè) logtail （SLS 的采集器）的 Sidecar。

然后將客戶配置的，需要采集的文件或者路徑，用 volume 的形式，給業(yè)務(wù) Container 和 logtail Sidecar 共享。這也是 SAE 日志采集不能配置/home/admin 的原因。因?yàn)榉?wù)的啟動(dòng)容器是放在/home/admin 中，掛載 volume 會(huì)覆蓋掉啟動(dòng)容器。

同時(shí) logtail 的數(shù)據(jù)上報(bào)，是通過(guò) SLS 內(nèi)網(wǎng)地址去上報(bào)，因此無(wú)需開(kāi)通外網(wǎng)。

SLS 的 Sidecar 采集，為了不影響業(yè)務(wù) Container 的運(yùn)行，會(huì)設(shè)置資源的限制，例如 CPU 限制在 0.25C ，內(nèi)存限制在 100M。

SLS 適合大部分的業(yè)務(wù)場(chǎng)景，并且支持配置告警和監(jiān)控圖。絕大多數(shù)適合直接選擇 SLS 就可以了。

NAS 采集架構(gòu)

NAS 是一種可共享訪問(wèn)、彈性擴(kuò)展、高可靠以及高性能的分布式文件系統(tǒng)。本身提供高吞吐和高 IOPS 的同時(shí)支持文件的隨機(jī)讀寫(xiě)和在線修改。比較適合日志場(chǎng)景。如果想把比較多或比較大的日志在本地留存，可以通過(guò)掛載 NAS，然后將日志文件的保存路徑指向 NAS 的掛載目錄即可。NAS 掛載到 SAE 不牽扯到太多技術(shù)點(diǎn)和架構(gòu)，這里就略過(guò)不做過(guò)多的介紹了。

NAS 作為日志采集時(shí)，可以看作是一塊本地盤(pán)，即使實(shí)例崩潰重建等等各種以外情況，也都不會(huì)出現(xiàn)日志丟失的情況，對(duì)于非常重要，不允許丟失數(shù)據(jù)的場(chǎng)景，可以考慮此方案。

Kafka 采集架構(gòu)

用戶本身也可以將日志文件的內(nèi)容采集到 Kafka，然后通過(guò)消費(fèi) Kafka 的數(shù)據(jù)，來(lái)實(shí)現(xiàn)日志的采集。后續(xù)用戶可以結(jié)合自身的需求，將 Kafka 中的日志導(dǎo)入到 ElasticSearch ，或者程序去消費(fèi) Kafka 數(shù)據(jù)做處理等。

日志采集到 Kafka本身有多種方式，例如最常見(jiàn)的 logstach，比較輕量級(jí)的采集組建 filebeat，vector 等等。SAE 使用的采集組件是 vector，SAE 集成 vector 的架構(gòu)圖如下圖所示：

SAE 會(huì)在 pod 中，掛載一個(gè) logtail（vector 采集器）的 Sidecar。

然后將客戶配置的，需要采集的文件或者路徑，用 volume 的形式，給業(yè)務(wù) Container 和 vector Sidecar 共享

vector 會(huì)將采集到的日志數(shù)據(jù)定時(shí)發(fā)送到 Kafka。vector 本身有比較豐富的參數(shù)設(shè)置，可以設(shè)置采集數(shù)據(jù)壓縮，數(shù)據(jù)發(fā)送間隔，采集指標(biāo)等等。

Kafka 采集算是對(duì) SLS 采集的一種補(bǔ)充完善。實(shí)際生產(chǎn)環(huán)境下，有些客戶對(duì)權(quán)限的控制非常嚴(yán)格，可能只有 SAE 的權(quán)限，卻沒(méi)有 SLS 的權(quán)限，因此需要把日志采集到 Kafka 做后續(xù)的查看，或者本身有需求對(duì)日志做二次處理加工等場(chǎng)景，也可以選擇 Kafka 日志采集方案。 下面是一份基礎(chǔ)的 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"

重要的參數(shù)解析：

multiline.start_pattern 是當(dāng)檢測(cè)到符合這個(gè)正則的行時(shí)，會(huì)當(dāng)作一條新的數(shù)據(jù)處

multiline.condition_pattern 是檢測(cè)到符合這個(gè)正則的行時(shí)，會(huì)和上一行做行合并，當(dāng)作一條處理

sinks.internal_metrics_to_prom 配置了之后，會(huì)將配置一些 vector 的采集元數(shù)據(jù)上報(bào)到 prometheus

下面是配置了 vector 采集的元數(shù)據(jù)到 Prometheus，在 Grafana 的監(jiān)控大盤(pán)處配置了 vector 的元數(shù)據(jù)的一些采集監(jiān)控圖：

最佳實(shí)踐

Cloud Native

在實(shí)際使用中，可以根據(jù)自身的業(yè)務(wù)訴求選擇不同的日志采集方式。本身 logback 的日志采集策略，需要對(duì)文件大小和文件數(shù)量做一下限制，不然比較容易把 pod 的磁盤(pán)打滿。以 JAVA 為例，下面這段配置，會(huì)保留最大 7 個(gè)文件，每個(gè)文件大小最大 100M。

class="ch.qos.logback.core.rolling.RollingFileAppender">
${user.home}/logs/test/test.log

${user.home}/logs/test/test.%i.log
1
7


class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
100MB



UTF-8
%d{yyyy-MM-dd HH:mm:ss}|%msg%n

這段 log4j 的配置，是一種比較常見(jiàn)的日志輪轉(zhuǎn)配置。 常見(jiàn)的日志輪轉(zhuǎn)方式有兩種，一種是 create 模式，一種是 copytruncate 模式。而不同的日志采集組件，對(duì)兩者的支持程度會(huì)存在一些區(qū)別。 create 模式是重命名原日志文件，創(chuàng)建新的日志文件替換。log4j 使用的就是這種模式，詳細(xì)步驟如下圖所示：

當(dāng)日志的 event log 寫(xiě)入前會(huì)判斷是否達(dá)到文件設(shè)置最大容量，如果沒(méi)達(dá)到，則完成寫(xiě)入，如果達(dá)到了，則會(huì)進(jìn)入階段二

首先關(guān)閉當(dāng)前 currentlyActiveFile 指向的文件，之后對(duì)原文件進(jìn)行重命名，并新建一個(gè)文件，這個(gè)文件的名字和之前 currentlyActiveFile 指向的名字一致

把 currentlyActiveFile 指向的文件變?yōu)殡A段二新創(chuàng)建的文件

copytruncate 模式的思路是把正在輸出的日志拷(copy)一份出來(lái)，再清空(trucate)原來(lái)的日志。 目前主流組件的支持程度如下：

實(shí)際案例演示

Cloud Native

下面介紹一下客戶實(shí)際生產(chǎn)環(huán)境中的一些真實(shí)場(chǎng)景。

某客戶 A 通過(guò)日志輪轉(zhuǎn)設(shè)置程序的日志，并將日志采集到 SLS。并通過(guò)關(guān)鍵字配置相關(guān)報(bào)警，監(jiān)控大盤(pán)等。 首先通過(guò) log4j 的配置，使日志文件最多保持 10 個(gè)，每個(gè)大小 200M，保持磁盤(pán)的監(jiān)控，日志文件保存在/home/admin/logs 路徑下。這里不進(jìn)行過(guò)多介紹了，可以最佳實(shí)踐場(chǎng)景介紹的配置。 隨后通過(guò) SAE 的 SLS 日志采集功能，把日志采集到 SLS 中。

最后，通過(guò)程序中日志的一些關(guān)鍵字,或者一些其他規(guī)則，例如 200 狀態(tài)碼比例等進(jìn)行了報(bào)警配置。



通過(guò) Nginx 的日志完成監(jiān)控大盤(pán)的配置。

常見(jiàn)問(wèn)題

Cloud Native

日志合并介紹

很多時(shí)候，我們需要采集日志，并不是單純的一行一行采集，而是需要把多行日志合并成一行進(jìn)行采集，例如 JAVA 的異常日志等。這個(gè)時(shí)候就需要用到日志合并功能了。

在 SLS 中，有多行模式的采集模式，這個(gè)模式需要用戶設(shè)置一個(gè)正則表達(dá)式，用來(lái)做多行合并。 vector 采集也有類(lèi)似的參數(shù)，multiline.start_pattern 用于設(shè)置新行的正則，符合此正則會(huì)被認(rèn)為是一個(gè)新行?？梢越Y(jié)合 multiline.mode 參數(shù)一起使用。更多參數(shù)請(qǐng)參看vector官網(wǎng)。

日志采集丟失分析

無(wú)論是 SLS 采集和 vector 采集到 Kafka 為了保證采集日志不丟失。都會(huì)將采集的點(diǎn)位（CheckPoint）信息保存到本地，如果遇到服務(wù)器意外關(guān)閉、進(jìn)程崩潰等異常情況時(shí)，會(huì)從上一次記錄的位置開(kāi)始采集數(shù)據(jù)，盡量保證數(shù)據(jù)不會(huì)丟失。

但是這并不能保證日志一定不會(huì)丟失。在一些極端場(chǎng)景下，是有可能造成日志采集丟失的，例如： 1. K8s pod 進(jìn)程崩潰，liveness 連續(xù)失敗等異常導(dǎo)致 pod 重建 2. 日志輪轉(zhuǎn)速度極快，例如1秒輪轉(zhuǎn)1次。 3. 日志采集速度長(zhǎng)期無(wú)法達(dá)到日志產(chǎn)生速度。 針對(duì)場(chǎng)景 2，3，需要去檢查自身的應(yīng)用程序，是否打印了過(guò)多不必要的日志，或者日志輪轉(zhuǎn)設(shè)置是否異常。因?yàn)檎Ｇ闆r下，這些情況不應(yīng)該出現(xiàn)。針對(duì)場(chǎng)景 1，如果對(duì)日志要求非常嚴(yán)格，在 pod 重建后也不能丟失的話，可以將掛載的 NAS 作為日志保存路徑，這樣即使在 pod 重建后，日志也不會(huì)丟失。

總結(jié)

Cloud Native

本文著重介紹了 SAE 提供了多種日志采集方案，以及相關(guān)的架構(gòu)，場(chǎng)景使用特點(diǎn)。總結(jié)起來(lái)三點(diǎn)：

1、SLS 采集適配性強(qiáng)，實(shí)用大多數(shù)場(chǎng)景

2、NAS 采集任何場(chǎng)景下都不會(huì)丟失，適合對(duì)日志要求非常嚴(yán)格的場(chǎng)景

3、Kafka 采集是對(duì) SLS 采集的一種補(bǔ)充，有對(duì)日志需要二次加工處理，或者因?yàn)闄?quán)限等原因無(wú)法使用 SLS 的場(chǎng)景，可以選擇將日志采集到 Kafka 自己做搜集處理。

審核編輯：劉清