知識星球來自：人在江湖`飄
連結：http://www.cnblogs.com/hunternet/p/9607850.html
前言
公司的程式日誌之前都是採用log4net記錄檔案日誌的方式，但是隨著後來我們團隊越來越大，專案也越來越大，我們的使用者量也越來越多。
慢慢系統就暴露了很多問題，這個時候我們的日誌系統已經不能滿足我們的要求。
其主要有下麵幾個問題：
-
隨著我們訪問量的增加，我們的日誌檔案急劇增加
-
多且亂的檔案日誌，難以讓我們對程式進行排錯
-
檔案日誌的記錄耗用我們應用伺服器的資源，導致我們的應用伺服器的處理使用者請求的能力下降
-
我們的日誌分佈在多臺應用伺服器上，當程式遇到問題時，我們的程式員都需要找運維人員要日誌，隨著團隊越來越大，問題越來越多，於是導致了程式員們排隊找運維要日誌，解決問題的速度急劇下降！
起初，使用者量不大的時候，上面的問題還能容忍。但任何一種小問題都會在使用者量訪問量變大的時候急劇的放大。
終於在幾波推廣活動的時候，很悲劇的我們又不得不每天深夜加班來為我們之前對這些問題的不重視來買單。
於是，在推廣活動結束之後，在我們的程式員得到一絲喘息的機會時，我決定來搭建一個我們自己的日誌系統，改善我們的日誌記錄方式。
根據以上問題分析我們的日誌系統需要有以下幾點要求：
-
日誌的寫入效率要高不能對應用伺服器造成太大的影響
-
要將日誌集中在一臺伺服器上(或一組)
-
提供一個方便檢索分析的視覺化頁面(這個最重要，再也受不了每天找運維要日誌，拿到一堆檔案來分析的日子了！)
一開始想要藉助log4net AdoAppender把我們的日誌寫到資料庫裡，然後我們開發一個相應的功能，來對我們的日誌來進行查詢和分析。
但考慮到寫入關係資料庫的效能問題，就放棄了，但有一個替代方案，就是寫入到Mongo中，這樣就解決了提高了一定的效能。
但也需要我們開發一個功能來查詢分析。這個時候從網上找了許多方案:
//方案1:這是我們現有的方案，優點:簡單 缺點:效率低，不易查詢分析，難以排錯…
service–>log4net–>檔案
//方案2:優點:簡單、效率高、有一定的查詢分析功能 缺點:增加mongodb，增加一定複雜性，查詢分析功能弱，需要投入開發精力和時間
service–>log4net–>Mongo–>開發一個功能查詢分析
//方案3:優點:效能很高，查詢分析及其方便,不需要開發投入 缺點：提高了系統複雜度，需要進行大量的測試以保證其穩定性，運維需要對這些元件進行維護監控…
service–>log4net–>kafka–>logstash–>elasticsearch–>kibana搜尋展示
//其它方案
service–>log4net–>檔案–>filebeat–>logstash–>elstaicsearch–>kibana
service–>log4net–>檔案–>filebeat–>elstaicsearch–>kibana
service–>log4net–>檔案–>logstash–>elstaicsearch–>kibana
最終和團隊交流後決定採用方案2和方案3的結合，我增加了一個log4net for mongo的appender(這個appender,nuget上也有)，另外我們的團隊開發一個能支援簡單查詢搜尋的功能。
我同步來搭建方案3。關於方案2就不多介紹了，很簡單。主要提一提方案3。
一、ELKB簡介
Elastic Search: 從名稱可以看出，Elastic Search 是用來進行搜尋的，提供資料以及相應的配置資訊（什麼欄位是什麼資料型別，哪些欄位可以檢索等），然後你就可以自由地使用API搜尋你的資料。
Logstash：日誌檔案基本上都是每行一條，每一條裡面有各種資訊，這個軟體的功能是將每條日誌解析為各個欄位。
Kibana：提供一套Web介面用來和 Elastic Search 進行互動，這樣我們不用使用API來檢索資料了，可以直接在 Kibana 中輸入關鍵字，Kibana 會將傳回的資料呈現給我們，當然，有很多漂亮的資料視覺化圖表可供選擇。
Beats：安裝在每臺需要收集日誌的伺服器上，將日誌傳送給Logstash進行處理，所以Beats是一個“搬運工”，將你的日誌搬運到日誌收集伺服器上。
Beats分為很多種，每一種收集特定的資訊。常用的是Filebeat，監聽檔案變化，傳送檔案內容。一般日誌系統使用Filebeat就夠了。
二、kafka簡介
2.1 簡介
kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。這種動作（網頁瀏覽，搜尋和其他使用者的行動）是在現代網路上的許多社會功能的一個關鍵因素。這些資料通常是由於吞吐量的要求而透過處理日誌和日誌聚合來解決。
2.2 適用場景
-
Messaging
對於一些常規的訊息系統,kafka是個不錯的選擇;partitons/replication和容錯,可以使kafka具有良好的擴充套件性和效能優勢.不過到目前為止,我們應該很清楚認識到,kafka並沒有提供JMS中的”事務性””訊息傳輸擔保(訊息確認機制)””訊息分組”等企業級特性;kafka只能使用作為”常規”的訊息系統,在一定程度上,尚未確保訊息的傳送與接收絕對可靠(比如,訊息重發,訊息傳送丟失等)
-
Websit activity tracking
kafka可以作為”網站活性跟蹤”的最佳工具;可以將網頁/使用者操作等資訊傳送到kafka中.並實時監控,或者離線統計分析等
-
Log Aggregation
kafka的特性決定它非常適合作為”日誌收集中心”;application可以將操作日誌”批次””非同步”的傳送到kafka叢集中,而不是儲存在本地或者DB中;kafka可以批次提交訊息/壓縮訊息等,這對producer端而言,幾乎感覺不到效能的開支.此時consumer端可以使hadoop等其他系統化的儲存和分析系統.
三、log4net+ELK+Kafka日誌系統
3.1.簡介
從上我們可以瞭解到，我們可以增加一個log4net kafkaappender 日誌生產者透過這個appender將日誌寫入kafka，由於kafka批次提交、壓縮的特性，因此對我們的應用伺服器效能的開支很小。
日誌消費者端使用logstash訂閱kafka中的訊息，傳送到elasticsearch中，透過kibana展示給我們。
同時我們也可以透過kibana對我們的日誌進行統計分析等。剛好可以解決我們上面的一些問題。整個流程大致如下圖:
關於log4net for kafka appender，我自己寫了一個，nuget上也有現成的包，大家需要可以去nuget上找一找。
3.2.搭建
簡單介紹一下搭建，搭建過程中採用Docker。
3.2.1 docker 安裝kafka
//下載
//下載zookeeper
docker pull wurstmeister/zookeeper
//下載kafka
docker pull wurstmeister/kafka:2.11-0.11.0.3
//啟動
//啟動zookeeper
docker run -d –name zookeeper –publish 2181:2181 –volume /etc/localtime:/etc/localtime wurstmeister/zookeeper
//啟動kafka
docker run -d –name kafka –publish 9092:9092
–link zookeeper
–env KAFKA_ZOOKEEPER_CONNECT=192.168.121.205:2181
–env KAFKA_ADVERTISED_HOST_NAME=192.168.121.205
–env KAFKA_ADVERTISED_PORT=9092
–volume /etc/localtime:/etc/localtime
wurstmeister/kafka:2.11-0.11.0.3
//測試
//建立topic
bin/kafka-topics.sh –create –zookeeper 192.168.121.205:2181 –replication-factor 1 –partitions 1 –topic mykafka
//檢視topic
bin/kafka-topics.sh –list –zookeeper 192.168.121.205:2181
//建立生產者
bin/kafka-console-producer.sh –broker-list 192.168.121.205:9092 –topic mykafka
//建立消費者
bin/kafka-console-consumer.sh –zookeeper 192.168.121.205:2181 –topic mykafka –from-beginning
3.2.2 Docker安裝ELK
//1.下載elk
docker pull sebp/elk
//2.啟動elk
//Elasticsearch至少需要單獨2G的記憶體
//增加了一個volume系結，以免重啟container以後ES的資料丟失
docker run -d -p 5044:5044 -p 127.0.0.1:5601:5601 -p 127.0.0.1:9200:9200 -p 127.0.0.1:9300:9300 -v /var/data/elk:/var/lib/elasticsearch –name=elk sebp/elk
//若啟動過程出錯一般是因為elasticsearch使用者擁有的記憶體許可權太小，至少需要262144
切換到root使用者
執行命令：
sysctl -w vm.max_map_count=262144
檢視結果：
sysctl -a|grep vm.max_map_count
顯示：
vm.max_map_count = 262144
上述方法修改之後，如果重啟虛擬機器將失效，所以：
解決辦法：
在 /etc/sysctl.conf檔案最後新增一行
vm.max_map_count=262144
即可永久修改
啟動成功之後訪問：http://:5601 看到kibana頁面則說明安裝成功
配置使用
//進入容器
docker exec -it
/bin/bash
//執行命令
/opt/logstash/bin/logstash -e ‘input { stdin { } } output { elasticsearch { hosts => [“localhost”] } }’
/*
註意：如果看到這樣的報錯資訊 Logstash could not be started because there is already another instance using the configured data directory. If you wish to run multiple instances, you must change the “path.data” setting. 請執行命令：service logstash stop 然後在執行就可以了。
*/
測試
當命令成功被執行後，看到：Successfully started Logstash API endpoint {:port=>9600} 資訊後，輸入：this is a dummy entry 然後回車，模擬一條日誌進行測試。
開啟瀏覽器，輸入：http://:9200/_search?pretty 如圖，就會看到我們剛剛輸入的日誌內容。
3.2.3 logstash-kafka配置實體
這是我測試用的一個配置檔案。
input {
kafka{
//此處註意:logstash5.x版本以前kafka外掛配置的是zookeeper地址，5.x以後配置的是kafka實體地址
bootstrap_servers =>[“192.168.121.205:9092”]
client_id => “test” group_id => “test”
consumer_threads => 5
decorate_events => true
topics => “logstash”
}
}
filter{
json{
source => “message”
}
}
output {
elasticsearch {
hosts => [“192.168.121.205”]
index=> “hslog_2”
codec => “json”
}
}
配置檔案啟動logstash方式
/opt/logstash/bin/logstash -f “配置檔案地址”
結束語
如上，我們的日誌系統基本搭建完畢，當然還有很多關於kafka,logstash,elstaicsearch,kibana的使用，以及我們使用的一些問題，大家自己嘗試著搭建一下。
當然，沒有最好的方案，建議大家結合自己公司和系統的現實情況，尋找和選擇解決方案。
能用簡單的方案解決問題，就不要使用複雜的方案。因為複雜的方案在解決問題的同時，也會給我們帶來其他的問題。
就像我們這個方案，雖然解決了我們當時的問題，但是也增加了我們系統的複雜度，例如:這其中的每一個元件出了問題，都將導致我們的日誌系統不可用……,此外，工欲善其事必先利其器，我們雖然解決了器的問題，但是要想”善我們的事”還有很長的路要走，因為究其根本，日誌記不記錄，在什麼地方記錄，記錄什麼等級的日誌，還是由我們選擇去記錄。
日誌記錄無規範、亂記、瞎記，如何規範日誌的記錄才是是我們接下來要解決的大問題！歡迎大家留言，探討這些問題！
●編號155，輸入編號直達本文
●輸入m獲取文章目錄
Web開發
更多推薦《18個技術類公眾微信》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
