一文搞懂 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 配置：

重要的參數解析：

multiline.start_pattern 是當檢測到符合這個正則的行時，會當作一條新的數據處
multiline.condition_pattern 是檢測到符合這個正則的行時，會和上一行做行合併，當作一條處理
sinks.internal_metrics_to_prom 配置了之後，會將配置一些 vector 的採集元數據上報到 prometheus

下面是配置了 vector 採集的元數據到 Prometheus，在 Grafana 的監控大盤處配置了 vector 的元數據的一些採集監控圖：

最佳實踐

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

    <appender 
             >
        <file>${user.home}/logs/test/test.log</file>
        <rollingPolicy>
            <fileNamePattern>${user.home}/logs/test/test.%i.log</fileNamePattern>
            <minIndex>1</minIndex>
            <maxIndex>7</maxIndex>
        </rollingPolicy>
        <triggeringPolicy
               >
            <maxFileSize>100MB</maxFileSize>
        </triggeringPolicy>
        <encoder>
            <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 自己做蒐集處理。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/tIJvzCvEer02QIaFLVUQkA

SLS 採集架構

NAS 採集架構

Kafka 採集架構

日誌合併介紹

日誌採集丟失分析

猜你喜歡