系統日誌管理那點事

提及日誌，你們都是耳熟能詳的，一大堆日誌插件映入眼簾，日誌收集的方式也歷歷在目，可是，今天咱們的重點不只僅是收集日誌了，今天咱們主要說說怎麼管理日誌

收集日誌

日誌管理的第一件事，就是日誌的收集。日誌收集是開發者必備的技巧，不論是哪一個開發語言，哪一個開發平臺，日誌收集的插件都是有不少選擇的。例如：

.net 平臺你們鍾愛的log4net,支持多種存儲方式（文件、數據庫），多種格式，多種日誌拆分方式。

java 平臺主流的log4j、slf4j、logback，多種選擇。

日誌收集的組件這裏就不一一說明了，使用都是很簡單的，這裏重點說明一下，日誌咱們收集應該注意的地方：

1. 日誌等級必定要規範

等級	說明
debug	調試信息
info	用來收集關注的信息
warn	警告信息
error	錯誤信息

好多開發工程師記錄日誌老是喜歡用info級別來記錄日誌，通常的組件默認級別都是info,全部info默認都是會被記錄的，而debug信息發佈後，是不會被記錄的。這是一種偷懶的作法，但這也是很廣泛的作法。正確的方式應該根據日誌自己的特性去設置日誌的級別，其實規範的日誌級別是很是重要的：

• 正確的級別便於運維。便於統一調整系統日誌級別，如特殊狀況能夠只記錄error錯誤

• 沒有正確的級別，對後期日誌分析和處理是留下很大的隱患。error是須要去關注，而且處理掉的問題。info是普通日誌的記錄，大部分時候是無需關注的。

  2. error日誌內容必定要詳實 ,info日誌要簡潔易懂

  運營過大型系統的人都知道，除了數據庫存儲外，日誌、圖片、附件是存儲的三大債主，他們是會佔用很是很是大的空間，全部記錄info的日誌，要簡潔易懂，避免空間浪費。
  而對於error級別的錯誤，記錄必定要詳實，由於error的全部問題，是後期都要去解決的。
• 請求的地址
• 請求的參數
• 請求的ip
• 請求的用戶
• error具體信息
• 輸出的內容

• ......

爲了能很好的反饋當時error產生場景，以上的這些內容都應該被記錄，並且越詳細越好。

3. error日誌必定是全局統一收集的

前文說過，error的日誌，不只是咱們須要關注的，仍是我須要解決掉的問題，全部error日誌很是重要。錯誤日誌的收集，必須是全局統一收集的，AOP是你最好的夥伴，若是你發現你的errorr日誌收集是在每一個類中，處處是

try
{
......
}
catch()
{
    log.error("......")
}

這個必定要避免，無論你用那種語言，錯誤的處理，都是能夠經過全局進行統一的處理，錯誤日誌也要經過全局統一收集。

管理日誌

每一個開發人員對日誌的收集，都是很是熟悉的，基本都是將日誌按照日期的方式進行保存，平常使用日誌的時候，也是有一些要求：

1. 單個文件的大小要控制

由於你們都是經過日期方式保存的，可是由於有的人不重視日誌，常常會看到有的系統單個日誌文件上百M，有的甚至是幾G，而實際你們處理問題關注的都是最近的日誌，因此控制單個日誌文件的大小，對日誌的性能以及後期的運維都是很是便利的。

2. 日誌要便於瀏覽

日誌文件小才便於瀏覽，日誌最好能經過網址直接訪問到，而不須要一波三折登陸服務器，花10分鐘下載下來，再來分析。

3. 日誌的安全性要獲得保障

日誌內容有時會包含敏感信息，特別是error日誌，直接把系統的具體錯誤拋出來，因此日誌除了查看方便，還須要確保日誌文件的安全。若是是日誌文件是html或者txt，請必定記得把你的日誌文件權限修改下，特定用戶才能訪問，不要隨便開放，全部人都能訪問。

4. 日誌要按期清理

日誌是很是佔用存儲的空間，日誌太大對存儲的性能也有必定的影響，全部日誌要按期進行清理。

• 空間充足能夠保留半年
• 空間不足最少也要保留3個月

固然，這個也不是必定的，根據每一個系統的狀況去制定清理計劃就能夠了。

若是你們是小型網站，一個系統一臺服務器，日誌管理就簡單了。若是系統是作了高可用，後端用了均衡負載，那麼，日誌存在當前服務器是不太明智的作法，日誌必定要統一存儲，由於均衡負載隨時均可能會切換服務器，當出現故障，你須要去找日誌究竟存在哪一個服務器，也是件很浪費時間的事情。日誌文件也能夠經過：

• 共享虛擬目錄來存儲
• 定時進行文件同步來存儲
  日誌存儲也是對性能有必定影響的，文件同步雖然看起來麻煩必定，可是比共享虛擬目錄的方式來講，性能會好，推薦使用這種方式。

說到日誌的同步，就不得不提Logstash這個日誌組件。Logstash是如今應用最廣的日誌收集組件，基於java平臺。其實不少java平臺的組件，是不用去了解java開發的，只要簡單的配置就能使用。

Logstash支持文件同步，也能夠結合rsyslog進行文件同步，固然，也支持經過tcp協議，與第三方對接，好夥伴固然是Elasticsearch。Elasticsearch下文也會作簡單的介紹。

Logstash中文手冊：點擊這裏

分析日誌

日誌的分析也是一個很大的概念，可能對於運維和安全人員關注的是系統的全部日誌，包括訪問日誌、系統監測的日誌等，可是開發人員對於日誌更多的是：

• 監控系統運行錯誤，並獲取錯誤時的相關數據包
  
• 記錄重要的信息，某些時候便於後期檢查

因此，開發人員對日誌的需求相對而言簡單一點，可是處理不當也會面臨挑戰。若是要根據某些關鍵字找日誌，沒有一個靠譜的系統處理，那麼你們只能一直在ctrl+f 或者 find 命令中來回查找本身須要的信息，使用過的人都知道，這絕對不是一個很好的體驗。那麼是否有很好的工具來處理呢？有，這裏就介紹另外的兩個工具：

• Elasticsearch——一個基於lucene的搜索引擎工具，解決日誌的搜索問題。固然，也能解決系統的搜索問題，並且是分佈式的哦。
• Kibana——一個可視化的日誌操做引擎，結合Elasticsearch能夠達到更好的效果。

Kibana 界面預覽

Elasticsearch+Logstash+Kibana 就是傳說中的ELK了，應該是如今最流行的日誌處理平臺。

Elasticsearch中文文檔：點擊這裏
ELK中文文檔：點擊這裏

尾聲

前文介紹日誌收集、日誌管理注意的事項，推薦了日誌分析中兩個比較簡單經常使用的工具，這裏簡單說明一下，本身心目中的日誌管理系統。
總體流程如圖：

推薦的幾個工具雖然是java平臺的工具，可是日誌處理的思路不論是哪一個平臺都是同樣的。ELK若是隻是做爲日誌管理的工具，也能夠應用到.net平臺，無需再進行二次開發就能夠很好的使用。ELK的使用是有必定的學習成本的，若有時間能夠另起一文探討，可是，這個學習成本是能夠忽略語言之間的差別。 固然，若是你們願意使用腳本同步或者rsyn文件同步進行日誌處理也是能夠的。