摘要：最終，軟件服務操作組成員使用這些圖形展示系統性能。配置文件看上去類似下面使用是另一個容器組件。容器檢查清單鏈接輸出文件的腳本腳本文件的配置上面用到的鏡像可以在上拉取，鏈接解析數據在收集和裝箱發送后，我們需要做數據的解析。

每當我解決一些應用性能問題的時候，我常常會看到一個服務由于高的CPU利用率而使得一臺或者多臺服務器運行變得非常緩慢。這也許意味著它因為高負載而導致資源缺乏，但是通常情況下這其實是代碼有bug，一個異常或者一個錯誤的流程導致過多占用了系統資源。為了把這些問題找出來，我不得不在NewRelic/Nagios和ELK之間查看信息。

所以我確信我需要有一個單一的管理面板來查看從各個應用，操作系統以及網絡設備上收集來的事件組合而成的性能指標

為了使用ELK來監控你平臺的性能，你需要集成一系列的工具。Probes是必須包含的組件，它運行在各個主機上用來收集各種系統性能指標。然后，采集的數據需要發送給Logstash，然后在Elasticsearch中進行聚集，最后由Kibana轉換成圖形。最終，軟件服務操作組成員使用這些圖形展示系統性能。在這篇文章中，我將分享我們如何建構我們的ELK軟件棧來監控服務的性能。

在收集和傳送數據到Logstash中的第一個步驟，我們使用一個名為 Collectl 的工具。該工具來自于一個開源項目，它包含的大量的選項允許系統管理員從多個不同的IT系統中獲取各種指標，并且運行保存這些數據供以后分析。我們使用它來生成，追蹤，以及保存指標數據，例如網絡吞吐量，CPU的磁盤IO等待時間，空閑的內存，以及CPU的空閑時間（指出過度/未充分使用計算機資源）。它也常被用于監控其他類型的系統資源，例如inode的使用以及打開的socket數量。

Collectl命令輸出樣例

最后，Collectl使用指定格式(in plot format)將采集的指標輸出到一個日志文件中。該開源項目知道如何收集信息但是它并不會自動發送數據到ELK軟件棧中。

我們把Collectl封裝到了一個Docker容器中來獲取一個Docker鏡像，該鏡像會包含了數據采集和數據發送的基本軟件。我們使用版本4.0.0的Collectl以及下面提到的配置，這樣可以避免一系列的問題：

—— 為了避免數據在容器中過載，我們只保存了當天的數據。更久的數據都是維護在ELK軟件棧中，因此你無需擔心在容器的日志中保存所有的數據導致的問題。

—— Collectl可以以指定的時間周期收集各種采樣數據，當它會用不同的時間周期把數據持久到磁盤。這被稱為刷新周期。如果數據每秒鐘都被刷新到磁盤那么你可以得到近乎實時的數據。不過例如對于一個30秒的采集間隔，那么選擇一個十分激進的采樣周期不是必須的。一個輸出格式化器會用于輸出指定格式(a plot format)的輸出，默認它會在每一行輸出多個值，每個值用空格分開。

Collectl配置文件看上去類似下面：

DaemonCommands = -f /var/log/collectl/performance-tab -r00:00,0 -F1 -s+YZ -oz -P --interval 30
PQuery =   /usr/sbin/perfquery:/usr/bin/perfquery:/usr/local/ofed/bin/perfquery
PCounter = /usr/mellanox/bin/get_pcounter
VStat =    /usr/mellanox/bin/vstat:/usr/bin/vstat
OfedInfo = /usr/bin/ofed_info:/usr/local/ofed/bin/ofed_info
Resize=/usr/bin/resize:/usr/X11R6/bin/resize
Ipmitool =  /usr/bin/ipmitool:/usr/local/bin/ipmitool:/opt/hptc/sbin/ipmitool
IpmiCache = /var/run/collectl-ipmicache
IpmiTypes = fan,temp,current

RSYSLOG是另一個容器組件。它用來從日志文件中提取數據，并且發送數據到ELK軟件棧中。為了讓Logstash專注于需要字段而不是所有的數據上，這里建議使用RSYSLOG在日志里增加一些元數據來對日志進行篩選。這里可以在數據發送前對指標進行過濾或者增加一些信息比如實例名稱以及IP地址。附加上了時間戳后，這些信息可以被發送到Logstash。

在本步驟，有兩個問題需要注意：

1 - 時間戳： 首先，Collectl并不在采集的數據中輸出它的時間戳。因此如果你不同的主機運行在不同的時區，它們在你的ELK里面并不會對齊。為了解決這個問題，我們需要查詢容器當前運行的時區，然后設置相應的時間戳。

2 - 遵循Collectl日志文件名： 另一個復雜的問題是Collectl輸出數據到一個文件中，但是該文件名不是固定不變的。僅僅文件名的前綴是可以自定義的，然后Collectl自動在文件名上加上了當前日期。這個問題導致RSYSLOG不能通過文件名來監視文件，當日期切換時文件名也會改變。我們可以用最新版本的RSYSLOG —— 版本8來解決它，但是這里我假設大多數用戶還沒有用上這個版本。我們創建了一個很小的腳本，它調用了老版本的RSYSLOG，該腳本在容器里運行了一個定時的任務，該任務會鏈接一個指定的名稱的文件名到一個固定的日志文件名上。然后SYSLOG只中那個固定日志文件中提取數據，即便該文件鏈接的目標文件改變了也沒有關系。這就像一個指針，它在一定的時間下總是指向正確的Collectl日志文件。

$ModLoad imfile
$InputFilePollInterval 10
$PrivDropToGroup adm
$WorkDirectory /var/spool/rsyslog
 
# Logengine access file:
$InputFileName /var/log/collectl/daily.log
$InputFileTag performance-tab:
$InputFileStateFile stat-performance
$InputFileSeverity info
$InputFilePersistStateInterval 20000
$InputRunFileMonitor
 
$template logzioPerformanceFormat,"[XXLOGZTOKENXX] <%pri%>%protocol-version% %timestamp:::date-rfc3339% XXHOSTNAMEXX %app-name% %procid% %msgid% [type=performance-tab instance=XXINSTANCTIDXX] XXOFSETXX %msg% XXUSERTAGXX
"
if $programname == "performance-tab" then @@XXLISTENERXX;logzioPerformanceFormat

— Collectl

RSYSLOG

鏈接Collectl輸出文件的腳本

腳本文件的配置

上面用到的Docker鏡像可以在DockerHub上拉取，鏈接： https://registry.hub.docker.com/u/logzio/logzio-perfagent/

在收集和裝箱發送后，我們需要做數據的解析。Collectl返回的是未結構化的日志數據，它基本是由一系列的數字組成， Logstash Grok表達式使用這些數據來獲取每個字段的名稱和指定的值。

Collectl的配置參數顯示設置了一個特定的輸出模式。RSYSLOG日志配置在發送的消息中的特定位置增加了時區的信息。如果你想同時使用了這兩個配置，那Grok模式配置如下：

%{GREEDYDATA:zone_time} %{NUMBER:cpu__user_percent:int} %{NUMBER:cpu__nice_percent:int}
%{NUMBER:cpu__sys_percent:int} %{NUMBER:cpu__wait_percent:int} %{NUMBER:cpu__irq_percent:int}
%{NUMBER:cpu__soft_percent:int} %{NUMBER:cpu__steal_percent:int}
%{NUMBER:cpu__idle_percent:int} %{NUMBER:cpu__totl_percent:int} 
%{NUMBER:cpu__guest_percent:int} %{NUMBER:cpu__guestN_percent:int} 
%{NUMBER:cpu__intrpt_sec:int} %{NUMBER:cpu__ctx_sec:int} %{NUMBER:cpu__proc_sec:int} 
%{NUMBER:cpu__proc__queue:int} %{NUMBER:cpu__proc__run:int} %{NUMBER:cpu__load__avg1:float} 
%{NUMBER:cpu__load__avg5:float} %{NUMBER:cpu__load__avg15:float} %{NUMBER:cpu__run_tot:int} 
%{NUMBER:cpu__blk_tot:int} %{NUMBER:mem__tot:int} %{NUMBER:mem__used:int} 
%{NUMBER:mem__free:int} %{NUMBER:mem__shared:int} %{NUMBER:mem__buf:int} 
%{NUMBER:mem__cached:int} %{NUMBER:mem__slab:int} %{NUMBER:mem__map:int} 
%{NUMBER:mem__anon:int} %{NUMBER:mem__commit:int} %{NUMBER:mem__locked:int} 
%{NUMBER:mem__swap__tot:int} %{NUMBER:mem__swap__used:int} %{NUMBER:mem__swap__free:int} 
%{NUMBER:mem__swap__in:int} %{NUMBER:mem__swap__out:int} %{NUMBER:mem__dirty:int} 
%{NUMBER:mem__clean:int} %{NUMBER:mem__laundry:int} %{NUMBER:mem__inactive:int} 
%{NUMBER:mem__page__in:int} %{NUMBER:mem__page__out:int} %{NUMBER:mem__page__faults:int} 
%{NUMBER:mem__page__maj_faults:int} %{NUMBER:mem__huge__total:int} 
%{NUMBER:mem__huge__free:int} %{NUMBER:mem__huge__reserved:int} 
%{NUMBER:mem__s_unreclaim:int} %{NUMBER:sock__used:int} %{NUMBER:sock__tcp:int} 
%{NUMBER:sock__orph:int} %{NUMBER:sock__tw:int} %{NUMBER:sock__alloc:int} 
%{NUMBER:sock__mem:int} %{NUMBER:sock__udp:int} %{NUMBER:sock__raw:int} 
%{NUMBER:sock__frag:int} %{NUMBER:sock__frag_mem:int} %{NUMBER:net__rx_pkt_tot:int} 
%{NUMBER:net__tx_pkt_tot:int} %{NUMBER:net__rx_kb_tot:int} %{NUMBER:net__tx_kb_tot:int} 
%{NUMBER:net__rx_cmp_tot:int} %{NUMBER:net__rx_mlt_tot:int} %{NUMBER:net__tx_cmp_tot:int} 
%{NUMBER:net__rx_errs_tot:int} %{NUMBER:net__tx_errs_tot:int} %{NUMBER:dsk__read__tot:int} 
%{NUMBER:dsk__write__tot:int} %{NUMBER:dsk__ops__tot:int} %{NUMBER:dsk__read__kb_tot:int} 
%{NUMBER:dsk__write__kb_tot:int} %{NUMBER:dsk__kb__tot:int} %{NUMBER:dsk__read__mrg_tot:int} %{NUMBER:dsk__write__mrg_tot:int} %{NUMBER:dsk__mrg__tot:int} %{NUMBER:inode__numDentry:int} %{NUMBER:inode__openfiles:int} %{NUMBER:inode__max_file_percent:int} 
%{NUMBER:inode__used:int} %{NUMBER:nfs__reads_s:int} %{NUMBER:nfs__writes_s:int} 
%{NUMBER:nfs__meta_s:int} %{NUMBER:nfs__commit_s:int} %{NUMBER:nfs__udp:int} 
%{NUMBER:nfs__tcp:int} %{NUMBER:nfs__tcp_conn:int} %{NUMBER:nfs__bad_auth:int} 
%{NUMBER:nfs__bad_client:int} %{NUMBER:nfs__reads_c:int} %{NUMBER:nfs__writes_c:int} 
%{NUMBER:nfs__meta_c:int} %{NUMBER:nfs__commit_c:int} %{NUMBER:nfs__retrans:int} 
%{NUMBER:nfs__authref:int} %{NUMBER:tcp__ip_err:int} %{NUMBER:tcp__tcp_err:int} 
%{NUMBER:tcp__udp_err:int} %{NUMBER:tcp__icmp_err:int} %{NUMBER:tcp__loss:int} 
%{NUMBER:tcp__f_trans:int} %{NUMBER:buddy__page_1:int} %{NUMBER:buddy__page_2:int} 
%{NUMBER:buddy__page_4:int} %{NUMBER:buddy__page_8:int} %{NUMBER:buddy__page_16:int} 
%{NUMBER:buddy__page_32:int} %{NUMBER:buddy__page_64:int} %{NUMBER:buddy__page_128:int} 
%{NUMBER:buddy__page_256:int} %{NUMBER:buddy__page_512:int} %{NUMBER:buddy__page_1024:int}?( 
%{GREEDYDATA:user_tag})

如果你運行了一個快速的ELK軟件棧，那你會幾乎同時得到這些數據的展示。顯然這依賴于你安裝的ELK的性能，不過你可以預期會在半分鐘之內得到結果 - 一個最新的數據流的信息。

在Logz.io，我們有一些預定義的報警和儀表板來展示性能指標，它們都是使用Collectl。如果你也使用Logz.io服務，請在聊天室里找到我們，我們將會分享這些有用的信息。

如果你想了解更多，請隨意在下面留言！

翻譯自這里