*作者：牛通(奇衛)*

日誌，對於一個程式的重要程度不言而喻。無論是作為排查問題的手段，記錄關鍵節點資訊，或者是預警，配置監控大盤等等，都扮演著至關重要的角色。是每一類，甚至每一個應用程式都需要記錄和檢視的重要內容。而在雲原生時代，日誌採集無論是在採集方案，還是在採集架構上，都會和傳統的日誌採集有一些差異。我們彙總了一下在日誌的採集過程中，經常會遇到一些實際的通用問題，例如：

-   部署在 K8s 的應用，磁碟大小會遠遠低於物理機，無法把所有日誌長期儲存，又有查詢歷史資料的訴求
-   日誌資料非常關鍵，不允許丟失，即使是在應用重啟例項重建後
-   希望對日誌做一些關鍵字等資訊的報警，以及監控大盤
-   許可權管控非常嚴格，不能使用或者查詢例如 SLS 等日誌系統，需要匯入到自己的日誌採集系統
-   JAVA，PHP 等應用的異常堆疊會產生換行，把堆疊異常列印成多行，如何彙總檢視呢？

那麼在實際生產環境中，使用者是如何使用日誌功能採集的呢？而面對不同的業務場景，不同的業務訴求時，採用哪種採集方案更佳呢？Serverless 應用引擎 SAE（Serverless App Engine）作為一個全託管、免運維、高彈性的通用 PaaS 平臺，提供了 SLS 採集、掛載 NAS 採集、Kafka 採集等多種採集方式，供使用者在不同的場景下使用。本文將著重介紹各種日誌採集方式的特點，最佳使用場景，幫助大家來設計合適的採集架構，並規避一些常見的問題。

## SAE 的日誌採集方式

### SLS 採集架構

SLS 採集日誌是 SAE 推薦的日誌採集方案。一站式提供資料採集、加工、查詢與分析、視覺化、告警、消費與投遞等能力。

SAE 內建整合了 SLS 的採集，可以很方便的將業務日誌，容器標準輸出採集到 SLS 。SAE 整合 SLS 的架構圖如下圖所示：

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d3a66eddf04748268da032bf0505e1d9~tplv-k3u1fbpfcp-zoom-1.image "1.png")

-   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 的架構圖如下圖所示：

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/97c39c3fb5414d519f42940adb46177c~tplv-k3u1fbpfcp-zoom-1.image "2.png")

-   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 的後設資料的一些採集監控圖：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b361f695387d4de394fd7b828ec78755~tplv-k3u1fbpfcp-zoom-1.image "3.png")

## 最佳實踐

在實際使用中，可以根據自身的業務訴求選擇不同的日誌採集方式。本身 logback 的日誌採集策略，需要對檔案大小和檔案數量做一下限制，不然比較容易把 pod 的磁碟打滿。以 JAVA 為例，下面這段配置，會保留最大 7 個檔案，每個檔案大小最大 100M。

```

</appender>
```

這段 log4j 的配置，是一種比較常見的日誌輪轉配置。

常見的日誌輪轉方式有兩種，一種是 create 模式，一種是 copytruncate 模式。而不同的日誌採集元件，對兩者的支援程度會存在一些區別。

create 模式是重新命名原日誌檔案，建立新的日誌檔案替換。log4j 使用的就是這種模式，詳細步驟如下圖所示：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/68b12fcda89f41e29da42d64889470fe~tplv-k3u1fbpfcp-zoom-1.image "4.png")

1.  當日志的 event log 寫入前會判斷是否達到檔案設定最大容量，如果沒達到，則完成寫入，如果達到了，則會進入階段二
1.  首先關閉當前 currentlyActiveFile 指向的檔案，之後對原檔案進行重新命名，並新建一個檔案，這個檔案的名字和之前 currentlyActiveFile 指向的名字一致
1.  把 currentlyActiveFile 指向的檔案變為階段二新建立的檔案

copytruncate 模式的思路是把正在輸出的日誌拷(copy)一份出來，再清空(trucate)原來的日誌。

目前主流元件的支援程度如下：

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4f7221e7918d41f79e1dd993b92386b6~tplv-k3u1fbpfcp-zoom-1.image "5.png")

## 實際案例演示

下面介紹一下客戶實際生產環境中的一些真實場景。

某客戶 A 透過日誌輪轉設定程式的日誌，並將日誌採集到 SLS。並透過關鍵字配置相關報警，監控大盤等。

首先透過 log4j 的配置，使日誌檔案最多保持 10 個，每個大小 200M，保持磁碟的監控，日誌檔案儲存在/home/admin/logs 路徑下。這裡不進行過多介紹了，可以最佳實踐場景介紹的配置。

隨後透過 SAE 的 SLS 日誌採集功能，把日誌採集到 SLS 中。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fa0d6ada364d476ba7dd821b448f140d~tplv-k3u1fbpfcp-zoom-1.image "6.png")

最後，透過程式中日誌的一些關鍵字,或者一些其他規則，例如 200 狀態碼比例等進行了報警配置。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6f43b2f0948348b8af08df0ccd95f14a~tplv-k3u1fbpfcp-zoom-1.image "7.png")

透過 Nginx 的日誌完成監控大盤的配置。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0739290996154b6584c6079c46ba119e~tplv-k3u1fbpfcp-zoom-1.image "8.png")

## 常見問題

### 日誌合併介紹

很多時候，我們需要採集日誌，並不是單純的一行一行採集，而是需要把多行日誌合併成一行進行採集，例如 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 採集適配性強，實用大多數場景
1.  NAS 採集任何場景下都不會丟失，適合對日誌要求非常嚴格的場景
1.  Kafka 採集是對 SLS 採集的一種補充，有對日誌需要二次加工處理，或者因為許可權等原因無法使用 SLS 的場景，可以選擇將日誌採集到 Kafka 自己做蒐集處理。

***

阿里雲重磅推出 SAE Job，支援 XXL-JOB、ElasticJob 任務的全託管，零改造遷移。

**目前火熱公測中，2022 年 9 月 1 日正式商業化收費，歡迎大家使用！**

SAE Job 作為面向任務的 Serverless PaaS 平臺，重點解決使用者的效率和成本問題。根據業務資料處理需求，能在短時間內快速建立大量計算任務，並且在任務完成後快速釋放計算資源。支援單機、廣播、平行計算、分片任務模型，定時、超時重試、阻塞策略等任務核心特性，比開源任務框架使用更方便（對程式碼無侵入）、更節省（任務執行完立即釋放資源）、更穩定（失敗自動重試）、更透明（視覺化監控報警）、更省心（免運維）。

更多產品內容，點選[此處](https://www.aliyun.com/product/aliware/sae)檢視~

一文搞懂 SAE 日誌採集架構

相關文章