導讀：網易從2015年就開始了雲原生的探索與實踐，作為可觀測性的重要一環，日志平台也經曆了從主機到容器的演進，支撐了集團内各業務部門的大規模雲原生化改造。本文會講述在這個過程中我們遇到的問題，如何演進和改造，并從中沉澱了哪些經驗與最佳實踐。
主要内容包括：
- Operator化的⽇志采集
- ⼤規模場景下的困境與挑戰
- 開源Loggie的現在與未來
01
雲原⽣最初的探索
早期公司内部業務跑在實體機上時，各業務使用的日志采集工具、日志中轉和存儲、配置下發都比較混亂，選型種類多。公司内基于輕舟平台推進了各服務容器化和雲原生化，随着服務不斷地遷移到K8s上，我們關于采集K8s容器日志和日志平台方面積累很多實踐經驗。
雲原生日志是什麼樣的，容器日志采集和主機上服務的日志采集有什麼差異？首先Pod在K8s中會頻繁地發生遷移，手動去節點上變更配置日志采集配置不太切實際。 同時，雲原生環境中日志存儲的形式多樣，有容器标準輸出和HostPath，EmptyDir，PV等。另外，采集日志後，一般會根據雲原生環境的Namespace、Pod、Container、Node甚至容器環境變量、Label等次元進行檢索和過濾，這些元資訊需要在日志采集時被注入。
常見的雲原生環境日志采集有以下三種思路：
1. 隻采集标準輸出
日志列印到标準輸出的操作雖然符合雲原生十二要素，但是很多業務還是習慣輸出到日志檔案中，而且隻采集标準輸出日志難以滿足一些複雜業務的需求。正常的采集标準輸出日志的方式是挂載/var/lib/docker，/var/log/pods下的目錄。同時需要注意選型的日志Agent是否支援注入k8s元資訊。
2. Agent⽇志路徑全局挂載
日志可以放在EmptyDir，HostPath或PV存儲中，通過DaemonSet方式把日志采集Agent部署到每一台k8s節點上。EmptyDir等存儲映射到節點的目錄可以通過通配的方式配置到Agent進行采集，由Agent讀取配置路徑下的日志檔案。
但這種通用比對的方式無法根據服務級别進行單獨配置。如果需要配置隻采集某些服務的日志、或是某一個應用和其他應用的格式不同，例如某個應用的日志是多行的日志，此時需要單獨修改配置，管理成本比較高。
3. Sidecar⽅式
每個業務Pod在部署時都增加一個日志采集的Agent SideCar，可以通過容器平台或k8s webhook的方式把日志采集Agent注入到Pod内。Agent可以通過挂載相同的HostPath或EmptyDir的方式采集到業務容器的日志。
這種方式的弊端是對Pod侵入性強，Pod數量多時資源消耗較大。
對比DaemonSet和SideCar兩種部署方式，DaemonSet在穩定性、侵入性、資源占用方面有優勢，但隔離性、性能方面SideCar方式更好。我們實踐中會優先使用DaemonSet方式采集日志。如果某個服務日志量較大、吞吐量較高，可以考慮為該服務的Pod配置Sidecar方式采集日志。
針對日志采集方面的痛點，我們提出的第一個初步方案是：自研的Ripple Operator配合開源的日志采集用戶端Filebeat進行業務日志采集。
部署方面，FileBeat、Ripple通過SideCar方式部署在一起，Ripple監聽k8s。在使用方面，使用者通過CRD，一個CRD可以表示一個服務的日志采集配置，Ripple可以和k8s互動感覺到Pod生命周期。Ripple可以下發配置到Agent，自動添加Pod相關元資訊并注入到日志中。存儲方面HostPath、EmptyDir、PV、Docker Rootfs都可以支援。
圖中日志采集的架構先在網易嚴選進行了應用， 後面逐漸地被公司内絕大多數部門參考落地，具體架構會根據實際環境有所差別。首先日志平台下發配置，Ripple監聽到K8s的CRD配置變動後，把配置下發給Filebeat。Filebeat把采集到的日志發送到中轉機，中轉機發送給Kafka，Flink消費Kafka資料進行處理後轉發給後端日志存儲。
02
進⼊深⽔區
随着接入的業務越來越多，1.0版本的日志架構逐漸暴露了一些問題：超大規模下系統的穩定性問題、日志平台性能問題、排障困難和排障需求不斷增多、維護人力成本直線升高等。
在前面介紹的架構中，Filebeat會把每個服務的日志發送給中轉機。但是Filebeat是一個單一的隊列架構，在中轉機的阻塞會影響整個節點的Filebeat日志上報。
我們嘗試把Filebeat改造成多隊列的模式增強隔離性，但是由于Filebeat本身的設計架構局限，重構的效果和運作狀态都不理想，同時與開源版本的維護和更新存在很大困難。
Filebeat隻支援單個Output，當使用者需要把日志發送到多個Kafka叢集時，隻能在同一個節點上部署多個Filebeat。導緻運維成本高、計算資源消耗大、水準擴充困難。
Filebeat設計之初是為了解決Logstash的問題，作為輕量級的日志采集端運作，不适合作為中轉。Logstash在日志切分、解析等方面表現出色，但是問題在于性能較弱。雖然Flink性能和表現出色，但我們的很多場景隻需要簡單的日志切分，Flink一般依賴流式處理基礎平台的支援，同時在傳遞過程中使用者要額外付出Flink的機器和運維成本，是以我們需要一個更輕量、成本更低的方案。
此外，日志采集過程的可觀測性和穩定性也很重要。在使用者使用過程中經常會遇到日志沒有按預期采集、日志采集延遲、日志丢失、日志量增長速度過快磁盤爆滿等問題，Filebeat沒有提供這些完善等監控名額，同時還需要額外部署prometheus exporter。
我們以一個線上問題為例。線上某叢集經常遇到磁盤使用量短時間内暴增到90%以上并觸發報警的情況。實際登入節點排查問題後，發現報警的原因在于下遊Kafka吞吐量不夠，一些日志檔案沒有完全采集完畢，Filebeat程序預設保留檔案句柄直到檔案采集完畢，由于檔案句柄沒有釋放，底層的檔案無法被真正删除。但在這種情況下，Filebeat缺乏輸入延遲、發送延遲和堆積情況等名額，影響穩定性。
在一個大流量的節點，我們發現Filebeat發送資料到下遊Kafka時整體資料處理速度不理想，于是進行了很多優化的嘗試，比如換SSD的Kafka叢集、改Kafka配置、優化Filebeat配置等調優。我們發現在Filebeat不打開資料壓縮的情況下，最大資料發送速度達到80MB/s後很難再有提升，打開資料壓縮後Filebeat的CPU的消耗又暴增。調整Kafka或Filebeat參數、機器等配置的優化效果不明顯。
那麼除了Filebeat外，其他的日志采集工具能不能滿足需求？目前主流的日志采集Agent對容器化場景下的日志采集支援不太理想，大部分開源日志采集工具僅支援到容器标準輸出的采集，對雲原生下日志采集也沒有整體解決方案。
03
新的征程
開源Loggie的現在和未來
基于Filebeat和現有主流資料采集工具的情況，我們決定自研日志采集Agent——Loggie。它是基于Golang的輕量級、⾼性能、雲原⽣⽇志采集、聚合Agent，⽀持多Pipeline群組件熱插拔，整體架構如圖。
我們加強了Agent的監控和穩定性，可以利用Monitor EventBus上報Agent運作情況，同時暴露了可調用的Restful API和Prometheus拉取監控資料的接口。配置管理方面，目前使用K8S進行配置下發和管理，後續會接入更多配置中心供使用者管理配置。
Loggie提供了一棧式日志解決方案，新Agent不再分開維護Agent和中轉機。作為一個可插拔元件，Agent既可以作為日志采集端使用，也可以作為中轉機使用，同時支援日志中轉、過濾、解析、切分、⽇志報警。Loggie同時提供了雲原生日志采集完整解決方案，比如通過CRD的形式利用K8s的能力下發配置、部署等。基于我們長期的大規模運維日志收集服務的經驗，Loggie沉澱了全⽅位的可觀測性、快速排障、異常預警、⾃動化運維能⼒的功能。Loggie基于Golang開發，性能非常好，它資源占⽤小、吞吐性能優異、開發效率高維護成本低。
1. ⼀棧式⽇志解決⽅案
Agent既可以作為日志采集用戶端，也可以作為中轉機使用。在日志中轉方面，我們通過實作Interceptor子產品邏輯實作日志的分流、聚合、轉存、解析、切分等。通過K8s的CRD可以下發日志采集Agent配置。新的日志采集架構整體維護成本更低。
在采用Loggie之前我們有兩種報警方案：第一種是基于ElastAlert輪詢Elasticsearch進行日志報警，該方案存在配置下發需要手動配置、告警接入不能自動化和高可用不完善等問題；第二種是基于Flink解析關鍵字或是對日志進行正則比對進行報警，在前面我們已經介紹過，對于整體日志采集服務而言Flink是比較重量級的。
在采用Loggie後，我們可以使用logAlert Interceptor，在日志采集過程中就可以通過關鍵字比對識别info或error進行報警。也可以通過單獨部署Elasticsearch Source的Loggie Aggregator對Elasticsearch進行輪詢，把資訊發送到Prometheus進行報警。新版日志報警架構更輕量，維護起來也更簡單。
在項目開發方面，我們秉承微核心、插件化、元件化的原則，把所有元件抽象為component。開發者通過實作生命周期接口，可以快速開發資料發送端邏輯、資料源讀取邏輯、處理邏輯和服務注冊邏輯。這樣的設計讓需求能更快更靈活地實作，大大了日志采集側的開發效率。
基于靈活高效的Agent資料源設計，我們可以配置kubeEvent source采集K8S Event資料作為監控報警的補充。相比重新實作一個采集K8S Event項目，隻需要在Loggie上實作對應的source，其他如隊列緩存、解析日志、發送日志的邏輯都可以複用。
2. 雲原⽣的⽇志形态
使用者通過配置LogConfig CRD，可以指定采集Pod、節點、叢集日志資訊。圖中的例子是通過labelSelector比對要采集的Pod，并配置容器内日志路徑；通過Sink CRD和Interceptor CRD可以配置日志發送和日志處理、解析方式。
通過CRD的方式打通日志處理鍊路，使用者可以通過配置CRD定義日志中轉、聚合和發送的方案，可以配置日志的解析、限流、報警規則，在進行私有化部署和将日志服務平台化時大大降低了配置管理的複雜度，一旦有配置變更，k8s可以快速地把配置同步到日志采集服務中。
在k8s中我們提供了多種部署方案, 作為Agent部署時，我們提供了DaemonSet或SideCar方式進行部署。作為中轉節點部署時可以作為StatefulSet部署。日志采集的架構上更加靈活，可以直接發送到ES，也可以發送給Kafka再交給中轉節點，部署友善。
3. ⽣産級特性
我們為日志采集Agent添加了完善的名額，包括日志采集進度、長期采集未完成、采集發送延遲、FD數量、輸出QPS和其他服務級别名額，提供了原生Prometheus格式的接口、RestAPI和名額發送Kafka等方式暴露名額。
日志采集服務大規模部署的穩定性和排障兩方面有很大提升。我們通過獨立各個采集任務Pipeline增強服務隔離性，還可以通過Interceptor提供了QPS限制，定時清理日志防止磁盤寫滿，增加了日志檔案突發增長檢測和合理的Fd保留機制等。
4. 資源與性能
我們利用Filebeat進行了基準測試，在處理單⾏、單⽂件、相同發送并發度、⽆解析的場景下，發送日志⾄Kafka。
測試結果上看Loggie性能大幅度提升，消耗CPU為Filebeat的1/4、吞吐量為Filebeat的1.6-2.6倍，且極限吞吐量與Filebeat的80MB/s瓶頸提升到200MB/s以上。
04
Loggie開源計劃
Loggie已經開源，下面是我們項目推進的RoadMap和正在做的事，歡迎感興趣的開發者一起參與項目。
Loggie項目位址：
https://github.com/loggie-io/loggie/
今天的分享就到這裡，謝謝大家。
在文末分享、點贊、在看，給個3連擊呗~
分享嘉賓：
分享嘉賓：傅轶 網易數帆
編輯整理：張德通 Treelab
出品平台：DataFunTalk
添加小助手連結：
1.免費資料領取：點選上方連結添加小助手回複【大資料合集】免費領取《大資料典藏版合集》
回複【算法合集】免費領取《網際網路核心算法合集》
2.添加交流群：點選點選上方連結添加小助手回複【大資料交流群】加入“大資料交流群”
回複【算法交流群】加入“算法交流群”