【2013年9月5日 51CTO外電頭條】要是系統上哪里出現了什么岔子，日志文件是尋找線索以便排除故障的頭一個地方。Logstash是內置有分析工具的日志服務，它可以整合來自許多服務器的日志，甚至讓這些數據易于搜索。

要是企業網絡上任何環節出現了什么岔子，管理員就得馬上找出問題，并解決問題。找到出錯信息通常不是問題，畢竟大多數IT系統給出了源源不斷的系統日志條目和出錯消息，但要在包括眾多設備、系統和服務器的復雜網絡中正確地評估這些信息，卻常常是說起來容易做起來難。

一個問題是生成的大量信息。一方面，諸如Pacemaker集群管理器這些工具特別啰嗦，顯示的信息要比實際需要的信息多好多倍。另一方面，就Apache而言，要是管理員對它進行了設置，分開記錄每個虛擬主機的日志，數據最后有可能跑到好多個地方。在為許多客戶提供服務的Web服務器上，大量的日志文件會日積月累，這就意味著為某個用戶排除具體問題可能是一項沒完沒了的任務。

依賴OpenStack、CloudStack或其他云平臺的云計算環境擁有的服務器很少是少于20臺的，服務器日志的數量會激增，與服務器系統的數量成正比。

通常采用的解決辦法就是，在中央系統上由日志服務器收集日志，而不是任由日志散布于整個網絡上。這個做法可以幫助你通過SSH在多臺服務器之間瀏覽查找時，無需過于頻繁地敲鍵。有些日志文件甚至為日志編制索引，以便搜索起來既快速又方便。像Splunk這些商用工具就提供了這種增值類型的日志服務。

面對這些商用日志工具，開源社區祭出的利器就是Logstash，這項中央日志服務提供了一種選擇，可以通過Web界面來搜索現有的日志條目。

Logstash及其助手

嚴格來說，光憑Logstash無力確保對日志文件實行合理化、集中式的管理。執行任務時想取得預期的效果，Logstash就需要得到一些幫助。Logstash本身是個Java應用程序，盡管好多管理員對Java懷有種種偏見——無論這些偏見有沒有道理，Logstash開發人員決定支持Java有其充分的事實根據。因為Java還安裝在Windows上——這是理所當然的事，Logstash可以在日志文件庫里面加入Windows日志文件；在許多情況下，換成其他的Rsyslog服務，就很難做到這一點。

Logstash的安裝牽涉不止一臺服務器，它由至少五個不同的服務組成。核心角色由Logstash的自有組件shipper來扮演：shipper基本上是在每個目標系統上運行的客戶端，負責收集日志消息。下一步，shipper把日志消息發送給indexer，該組件負責按管理員指定的方式，解讀和處理日志信息。indexer所在的主機通常還運行Logstash Web服務器，這為管理員提供了查找日志文件的搜索框。在后臺，并不直接屬于Logstash，但對其功能而言很重要的另外兩個服務負責各自的任務，它們是Redis消息代理和ElasticSearch存儲及搜索環境。

Redis為shipper與indexer之間的通信起到了關鍵作用。每臺服務器上的Logstash實例將其消息傳送到Redis服務器；在該服務器上，Logstash indexer在下一步中檢索這些消息。ElasticSearch也是個Java應用程序，它在后臺編制索引，并提供界面，以便Logstash Web服務器將來自Web界面的搜索請求轉發至該界面。

模塊化設計

Logstash的一大優點在于其多樣性，這源自其模塊化設計，因而讓這個工具顯得非常靈活：比如說就在幾個月前，安裝的Logstash使用AMQP代理來取代Redis還很常見——RabbitMQ是通常的選擇。

不過，Logstash的amqp模塊沒有得到非常好的維護，也不是特別受Logstash開發者的歡迎。很容易實現改用另一種不同代理的決定，那是由于只需要為消息代理編寫接口。與此同時，Redis連接器可以順暢地工作，RabbitMQ遂成了明日黃花。

沒有限制

在其他地方，Logstash對管理員的創造力幾乎沒有什么限制：這款工具不僅提供了通過已定義過濾器存檔日志條目的功能，還提供了解讀日志條目的功能，因為每一個日志條件都編入索引、易于搜索。

比如說，一接到請求，Logstash會管理HTTP日志，以后可以在Web界面中進行有條理的搜索，查找已引起“內部錯誤”的所有可能的查詢。比如說，如果應用到Pacemaker，這意味著管理員可以明確搜索帶ERROR前綴的Pacemaker日志消息。

還可以設計過濾器，完全去除日志記錄中的各個條目。比如說，如果你想讓典型的系統日志MARK消息不出現在日志存檔中，只要改動Logstash shipper配置。

測試安裝

如果你想試一試Logstash，那么你很走運。與網站上的描述恰恰相反，安裝工作絕不是什么極為艱巨的任務。只要確保事先明確你將哪個角色分配給了哪個主機。一旦明確了Redis服務器、ElasticSearch和 Logstash indexer將運行哪個主機，你就可以準備上路了。下面這個例子基于Ubuntu 12.04，但也適用于Debian。網上也有面向典型企業發行版的Redis和ElasticSearch的RPM程序包，包括紅帽企業級Linux（RHEL）和SUSE Linux企業級服務器（SLES）等發行版。

安裝Redis有多容易，這在很大程度上取決于有沒有適用你系統的Redis服務器程序包。在Ubuntu上，一個簡單的命令：

apt-get install redis-server 

即可安裝相關組件。之后，建議修改/etc/redis/redis.conf中的127.0.0.1 bind條目，那樣它含有該主機的IP地址。要不然，Redis只連接到本地主機，這會阻止其他主機將各自的Logstash消息直接發送到Redis。重視安全的那些管理員應該通過redis.conf里面的requirepass指令，設定一個訪問密碼。

安裝ElasticSearch

ElasticSearch（見圖1）是個類似Logstash的Java應用程序；遺憾的是，Ubuntu里面沒有任何程序包。

圖1：日志消息的組織和管理工作不是由Logstash來處理，而由在后臺運行的ElasticSearch來處理。

幸好，可以從Upstream得到幫助，Upstream在其網站上為Ubuntu提供了預制的.deb程序包；它也可以通過dpkg –i來安裝。由于未遇到依賴項，該命令起初返回了出錯消息。執行了apt-get -f install命令后，ElasticSearch已準備就緒。

默認情況下，ElasticSearch還可以對127.0.0.1進行監聽，所以indexer必須在同一個主機上運行。如果你想讓ElasticSearch和Logstash索引服務在不同的主機上運行，就要在/etc/elasticsearch/elasticsearch.yml中找到必要的參數選項符；它們帶有network.bind_host和network.host名稱。

發送

下一步，你必須配置Logstash本身。Logstash并不以面向客戶端和服務器的單個Java庫這個方式出現，而是以涵蓋所有服務的一個大文件這個方式出現，這很重要。下載了Logstash JAR文件（截至截稿為止，最新版本是1.1.9）后，你只要選擇合適的參數就行了。

對shipper而言，你的shipper.conf file應該像是代碼片段1中的那樣。

代碼片段1：shipper.conf

input{ 
file{ 
type=>"syslog" 
# 通配符在此適用：） 
path=>["/var/log/messages","/var/log/ 
syslog","/var/log/*.log"] 
} 
file{ 
type=>"apache-access" 
path=>"/var/log/apache2/access.log" 
} 
file{ 
type=>"apache-error" 
path=>"/var/log/apache2/error.log" 
} 
} 
output{ 
stdout{debug=>truedebug_format=>"json"} 
redis{host=>"192.168.122.165"data_type=> 
"list"key=>"logstash"} 
} 

有了這種配置，Logstash會將來自系統日志文件和Apache的消息發送給“默認”虛擬域中的indexer。該示例中帶indexer的主機是192.168.122.165。

第22行中的key可能讓人覺得有點困惑；它不是指為驗證身份而設置的密鑰，而是指Redis所用的、作為Logstash隊列名稱的值。有了這個配置文件，

java -jar logstash-1.1.9-monolithic.jar agent -f shipper.conf 

命令會啟動Logstash。

索引

如果你從合適的配置開始入手，設置indexer也不復雜（代碼片段2）。

代碼片段2：Indexer.conf

input{ 
redis{ 
host=>"192.168.122.165" 
type=>"redis-input" 
data_type=>"list" 
key=>"logstash" 
format=>"json_event" 
} 
} 
output{ 
elasticsearch{ 
host=>"192.168.122.165" 
} 
} 

Logstash配置因而分成了輸入塊和輸出塊——顧名思義，這兩個塊指明了某項服務如何得到消息、該服務在何處轉發消息。

indexer用這個命令開始其日常工作：

java -jar logstash-1.1.9-monolithic.jar agent -f indexer.conf 

較之shipper，indexer在標準輸出通道中幾乎不生成自己的任何輸出，所以要是一切很平靜，你用不著擔心。

服務

最后，你需要Logstash Web服務器本身；它不需要自己的配置文件，可以用這個命令來開啟：

java -jar logstash-1.1.9-monolithic.jar web --backend elasticsearch://192.168.122.165/ 

該命令運行后，你應該能夠通過端口9292，立即登錄到Logstash系統（見圖2）。在這個例子中，完整的地址應該是：http://192.168.122.165:9292。

圖2：在Logstash記錄里面搜索“Network Manager”會顯示按時間排序的消息。

在首次啟動后，日志消息應該會立即開始出現（見圖3）；此外，你可以通過搜索框來核實這個過程。這基本上算是Logstash安裝過程的最后一個主要步驟。

圖3：Logstash shipper的狀態更新表明了軟件在如何運行：它將收到的日志消息發送給Redis。

系統操作人員可以隨意修改設置，以符合各自的需要。比如說，你通常希望啟動時在所有系統上運行Logstash shipper，這意味著只要編寫一個匹配的init腳本（如果你想避免自編腳本，可以在網上找到這方面的預定義腳本。）

還建議創建針對特定應用的過濾器，以便充分利用該解決方案的所有選項。供應商網站上概述了各種可能的Logstash過濾器選項（https://github.com/logstash/grok-patterns），它們也支持正則表達式，網站還有內容全面的說明文檔。

結論

Logstash是一種非常精巧的中央日志解決方案。已經有Chef菜譜（Chef cookbook）和Puppet配方（Puppet recipe），這對平時維護龐大計算機集群，需要進行集中式配置文件管理的管理員來說特別有用。Logstash在這類環境下可以很容易地改動。不過，搜索日志時，Logstash確實可以大顯身手。曾手動搜索成千上萬行日志條目的管理員會發現，借助Logstash排除故障確實讓人眼前一亮。只有對Java明顯不感冒的管理員才無法認識到其真正的價值。

原文鏈接：http://www.linuxpromagazine.com/Online/Features/Consolidating-Logs-with-Logstash