轉自：http://blog.163.com/guaiguai_family/blog/static/20078414520132181010189/

寫代碼的人都知道日志很重要，機器不多的時候，查看日志很簡單，ssh 上去 grep + awk + perl 啥的 ad hoc 的搞幾把就行，但面對上百臺甚至上千臺機器時，如何有效的收集和分析日志就成了個很頭疼的事情。日志處理必然有如下過程：

從各個服務器讀取日志
把日志存放到集中的地方
挖掘日志數據，用友好的 UI 展示出來，最好能做到實時的輸入表達式做過濾、聚合

下面分三個方面聊聊，整個過程是需要多方配合的，包括寫日志、讀日志、轉儲日志、分析日志，注意聊這些的背景是互聯網行業，機器多，日志多，服務質量對機器負載和帶寬消耗很敏感。最后再簡單介紹下 Splunk 這個牛逼的商業軟件。

一、讀取日志

這個事情猛一想是很簡單的事情，scp、rsync 一下不是很簡單么，但是要想做細致了還是很有嚼頭的：

寫日志一般會先寫到一個固定文件，到了一定大小或者某個時間會關閉文件并改名，然后有某個定時任務在后臺以很低的進程調度優先級以及很低的 IO 優先級對其壓縮（不在寫日志或者更名時直接壓縮是為了避免影響提供服務的那個進程的性能，尤其是在 log 寫速率很快時），這種情況下顯然首選讀取壓縮過的日志文件以節省帶寬以及壓縮的開銷
上面這個方式是批量的，有延時，比如每小時壓縮一次，那么有一小時的延遲，如果線上突然出問題了，運維人員打電話催著調查，咱不大好說“等會，日志還沒出來呢”，批量方式適合研究后臺算法的人員分析日志，對于開發人員來說往往需要實時日志收集，實時收集有兩種，a) 應用直接支持通過網絡發送日志的方式，b) 應用通過某個代理服務發送日志，比如 rsyslog 和 syslog-ng，通過管道發給 netcat 什么的，或者寫到磁盤上，再用 tail -f 或者類似原理的工具不斷讀取并轉發出去。實時日志收集看起來很美好，但實現是相當麻煩而且有風險的，如果應用自身不是直接寫磁盤，那么網絡和管道可能導致應用寫日志阻塞，這時的解決辦法往往會想到異步記錄日志，但異步記錄日志實現變復雜而且還要擔心異步那個線程能否及時刷出日志，還有轉發的那個進程是否性能夠好而且夠穩定。
讀取日志的那個進程如果崩潰了，怎么恢復呢？對于批量收集，需要記錄一個狀態表明某個日志文件是收集過了，這個是很好實現的，斷點續傳也可靠，因為那個日志文件不會被修改或者重命名，而對于實時收集，syslog 那種那就只能是丟了就丟了，對于 tail -f 的做法，需要記錄讀取的偏移量，以及小心處理日志文件寫滿后被改名的狀況(這個問題可以用一個粗暴的辦法繞過去，就是收集完日志后去掉重復的，在讀取日志和存儲日志時多了點開銷）。這個地方是需要讀寫日志雙方合作的，單個日志文件多大(太大了失敗重傳開銷大)，什么時候滾動日志，日志名字規則，放在什么目錄下面，等等。
除了批量和實時的區分，讀取日志還分 push 和 pull 兩種模式，模式的區分是看哪方發起的日志讀取。push 模式的主要問題是帶寬消耗不大容易控制，pull 就很簡單了，收集日志的服務器一個個機器的輪流收集就好了，對于批量收集，最好用 pull 模式，因為批量收集是突然消耗大量帶寬傳輸一個打包的大文件，很有必要控制帶寬，而對于實時收集，很自然是 push 模式了，但其實有時也是可以用 pull 方式的，比如 "ssh HOST tail -f /some/log"，收集一端衡量帶寬分配。pull 模式需要注意一點，如何讓多臺 log collector 機器不要同時去收集同一臺機器，這個地方主要是為了控制帶寬和對目標機的性能影響。
收集日志腳本在讀取一個文件出錯時會跳過剩下的文件還是會繼續收集下去？后一種方式是推薦的，否則磁盤一旦壞了一個文件，除非人為干預，就永遠收集不了其它文件了。
寫本地文件還是直接通過網絡發送出去？我個人是推薦直接寫磁盤的，一是磁盤比網絡可靠，二是磁盤上緩存一份方便 ad hoc 的 ssh 上去查看一把，用 tail -f 還可以實現近乎實時的日志收集，三是實現簡單，有哪個程序員不懂往磁盤上寫日志么？
真的需要實時收集嗎？其實，我個人覺得只有在開發的時候需要實時收集，能很方便的實時看到各個子系統的錯誤日志，上線之后運維人員有實時的 monitoring 系統，這個針對性更強，傳輸數據量很小，日志還是數據量太大，拿來做 monitoring 用途簡直就是偷懶。而到了發現問題、聯系上人員、開始調查，往往一小時過去了，批量收集的日志已經到位(對于實時分析用戶行為來說，實時日志收集很有意義，這時日志的作用不是為了調試問題了）。

說的很復雜的樣子，總結一句，我個人是覺得記日志到本地文件，然后 log collector 機器定期的主動 pull 日志文件是綜合來說最優的日志收集方式。

二、轉儲日志

日志讀取出來了，發到網絡上了，被某個收集程序拿到了，然后就需要考慮存儲了，在互聯網行業呆過的人一開始可能會很意外的發現硬盤居然是如此不靠譜的東西，兩三百臺機器，三天兩頭的壞磁盤，搞的都讓人懷疑是不是采購硬盤的家伙搞貓膩。存儲可靠性是一個問題，安全性也是一個問題，有時候日志里包含敏感信息，或者日志存儲只允許接收某幾臺機器的寫入，這時候就需要有日志轉發了，對于寫日志方不寫磁盤直接往外丟的實時收集，還需要日志轉發方緩存一下，以應對遠程日志存儲暫時失敗的情況，這時候其實就又出來了上面讀取日志的許多撓頭問題——日志收集真不是個看起來那么簡單的事情啊！

雖然日志往往是個丟一點也無所謂的事情，但能不丟自然最好，而且分析日志往往會用到 Hadoop 的一套工具，所以用 HDFS/HBase 做日志存儲是相當直接的做法，這一套可以參考 Facebook 的復雜日志收集、存儲、分析流程：http://www-conf.slac.stanford.edu/xldb2011/talks/xldb2011_tue_0940_facebookrealtimeanalytics.pdf，從這里可以看到實時事件流處理的整個過程真是叫處處頭大如斗！所以上“實時”系統之前，捫心自問一下，真的有必要嗎？十分鐘級別延遲夠么？一分鐘級別延遲夠么？盲目的把所有日志收集做到秒級別延時是超級浪費的事情。

寫的太長了點，總結一下，可靠的實時收集是很困難的，可靠的批量收集容易的多的多的多。。。。從被收集機器批量讀取日志，通過網絡發送到日志收集服務器，不經過磁盤，直接再次通過網絡傳到 HDFS 或者 HBase，這個流程容易實現而且很可靠，可靠性是通過重復運行修復失敗達到的，前幾天我就整了個兩百行的 Shell 腳本做這個事情。

三、日志分析

數據就位了，浩如煙海，想查點東西就得有好用的日志分析輔助工具，不能有需求了就臨時湊一段 hadoop M/R job 等半天才能得到結果，做日志分析需要做這些事情：

解析原始日志格式，分解成有意義的字段，有的 log 收集方案在第一階段就解析日志只發送關心的字段，以節省帶寬。
根據時間戳，request ID，session ID，user ID 等關聯日志條目，以盡量清晰當時各個子系統的狀態；
根據分析的目的做過濾、聚合、統計等等，最后整一份漂亮的報表出來。

這三個步驟往往是需要不斷反復以得到理想結果，所以有一個實時交互系統是很方便的，這也是為什么大多 log 收集方案最后總會牽扯進 MySQL、ElasticSearch 之類的東西，尤其是 ElasticSearch，簡直是搞搜索的狗皮膏藥，其 percolate 特性相當有創意。另外，交互系統自然有個實時的圖形顯示就更直觀了，比如顯示某個時間段某個用戶的訪問模式，某個錯誤的出現模式，等等。

一不小心，又啰嗦了很長的一篇，最后聊一下牛逼的商業日志解決方案 Splunk，它牛逼的地方在于上面第三點，對于第一點和第二點我覺得沒啥驚奇的，甚至不是很強悍，比如貌似并不直接支持帶寬控制。在日志分析方面，其 Web UI 做的相當出色，第一，它的 web 應用是插件模式的，可以往里頭加入很多第三方的插件，技術上沒啥驚奇，跟 Tomcat 里跑多個 servlet 似的，但產品思路很好的，把日志分析這種通常覺得是很零碎的活拔升到一個平臺高度了；第二，我也不知道是不是它首創，其搜索界面有一個時間軸的圖，可以實時的顯示搜索結果的分布，比如最近幾天的 HTTP 503 錯誤出現頻率，比如最近幾天某個 user ID 的訪問頻率，注意搜索條件是可以非常復雜的，不只是關鍵詞搜索，所以用下來頗有 data insight 的感覺，這個圖是會根據數據量和時間范圍自動縮放的，技術上不驚奇，但從產品設計上講是很贊的；第三，并不要求用戶一開始就定義日志格式，伊會自己猜測，比如 url 里的 name=param，日志里的 key=val，等等，猜測的還是八九不離十的，猜測不準的地方伊的 UI 上可以支持定制，不用寫配置文件，這個地方的 UI 設計也很贊，大家有興趣可以去下載下來試用下；第四，伊的搜索語法很強大，內置了很多函數，不知道是不是借了 Lucene 的東風，更牛逼的是伊的管道符可以把搜索結果送給報表系統，報表系統很美觀很強大，不愧是商業軟件，第四，伊支持流式搜索（類似 ElasticSearch 里 percolate 特性），所以伊順勢就支持了 alert，一旦日志符合某個條件，就發個警報出來。

說了 Splunk 不少好話，現在說說壞話。

首先，這玩意真不便宜，它有兩部分費用，一次性收費，按每天的數據量計算，比如一天 1GB log，那么要一次性給一萬美刀，一天 1000GB，一次性要給 120 萬美刀(數據量大有優惠)，然后是每年的費用，按一次性費用的 20% 收取，雖然我覺得其 Web UI 做的很棒，但我還是覺得這錢花的真心疼，自己整個 UI，糙點就糙點，能有百分之七八十的功能就行了，而且 UI 上一些很友好方便的東西，對于 coder 來說也不過是浮云，自己定義配置文件，寫點統計腳本，不是啥嚇人的事情，分析日志本來就不是指望 manager 上去點點鼠標就能搞定的，splunk 的那套搜索語言還是需要花點力氣學習的。

其次，這東西的日志收集并不是特別有創意，甚至可以說不是很強大，如果主要需求就是收集日志供 Hadoop 上的任務分析，不需要實時的日志搜索和報表，那么也沒必要花這么一大筆錢，簡單需求可以用 Graylog2 以及 logstash 湊合湊合。

總結

以上是生活随笔為你收集整理的日志收集以及分析：Splunk的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。