【生產環境K8S從搭建到運維的實錄（五）】K8S環境日志采集方案
1.前述
??今天想跟大家聊一聊在k8s環境里關于日志采集的解決方案，主要介紹一下我們的系統都有哪些日志檔案，以及各種日志檔案是如何被采集和應用的，
2.日志種類
??這里的分類是按照我們現有生產環境所處理的log進行劃分，按照集群劃分，可以分為以下3種：
- K8S集群log
- PKS集群log
- 監控機器log
按照業務種類劃分，又可以分為以下2種：
- 業務log
- 系統log
3.Log Systerm構成
??下面構成圖中關于PKS Cluster，K8S Cluster，Monitor System的詳細介紹請參照本系列文章的其他章節，
3-1 日志收集
-
PKS集群日志收集備份
?PKS集群中所有服務器的系統log都是通過syslog服務從集群中將log轉送到監控服務器所掛載的NAS中，
-
K8S集群日志收集備份
?K8S集群，也就是所謂Node節點上的log分為兩種：系統log和業務log，
?系統log和PKS集群一樣，也是通過syslog服務進行轉送，將Node節點上的系統log轉送到監控服務器掛載的NAS中，
?業務log則是通過fluent-bit服務進行收集，然后轉送到監控服務器中，再由監控服務器上的fluentd服務進行聚合處理，最終的log檔案存貯在NAS中，這里我們需要注意的是，最終存盤在NAS中的log檔案并不是K8S集群中的原始檔案，是經過fluent-bit和fluentd加工處理過得log檔案，
-
監控服務器日志收集備份
?監控服務器是獨立于K8S集群和PKS集群的虛擬服務器，這臺機器上的log收集備份，通過腳本來實作，我們設定了Crontab，定期執行，最終也是備份到NAS里，
3-2 fluent-bit VS fluentd
??上面我們提到K8S集群各個節點上的業務log是通過fluent-bit和fluentd來進行收集和聚合的，那么我們來簡單介紹一下這兩個服務，
??fluent bit是一個用c寫成的插件式、輕量級、多平臺開源日志收集工具，它允許從不同的源收集資料并發送到多個目的地，完全兼容docker和kubernetes生態環境，概括來說，fluent-bit是一個簡單日志收集，處理工具，而fluentd與fluent-bit類似，也是一個日志收集，處理工具，但是相較fluent-bit來說，fluentd有更強大的聚合功能，這里我列出它們的對比進行參考，
| fluentd | fluent-bit | |
|---|---|---|
| 范圍 | 容器/服務器 | 容器/服務器 |
| 語言 | C和Ruby | C |
| 大小 | 約40MB | 約450KB |
| 性能 | 高性能 | 高性能 |
| 依賴關系 | 作為Ruby Gem構建，主要依賴gems | 除了一些安裝編譯插件（GCC、CMAKE）其它零依賴， |
| 插件支持 | 超過650個可用插件 | 大約35個可用插件 |
| 許可證 | Apache許可證2.0版 | Apache許可證2.0版 |
3-3 日志監控
??日志采集最關鍵的一個作用就是用于監控，關于監控，我們有專門的章節進行說明，這里我只簡單的介紹一下日志采集與監控的設計概要，K8S集群中每一個Node節點上都有運行著一個flunet-bit服務，用來采集log資訊，監控服務器上的fluntd將fluent-bit采集到的log資訊進行聚合，過濾，prometheus對fluntd處理之后的資訊進行監控，最終通過grafana將監控資訊可視化展示，這里需要說明的一點，K8S集群中fluent-bit是以Pod形式存在，而監控服務器中的fluentd，prometheus，grafana都是容器形式運行，
4.結束語
?用來進行日志采集分析的工具以及解決方案有很多，但是不論用什么方法進行采集，日志洗掉也是需要考慮的一個問題，如果不定期洗掉，Node節點會因為磁盤空間被日志檔案占滿而崩潰，我們的環境在運行程序中就遇到過這樣的問題，因為一些業務log沒有及時被洗掉，而導致運行在Node節點上的其他Pod無法正常作業，其中就包括flunt-bit，因此log也無法正常被收集，
作者：rm * 小組
日期：2020/9/20
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/110493.html
標籤：其他
上一篇：漫畫：什么是 “黑天鵝事件” ？