微服務（SOP）日誌管理

問題：

---

　　大型企業應用規模大，調試 / 解決問題因爲在生產環境中不會有開發環境的調試工具，若是須要模擬還原當時的環境，

目前的解決辦法是進行日誌記錄

　　日誌記錄的經常使用方式：

• 使用SpringAop進行切入，有針對性的對關鍵操做進行記錄【http://www.cnblogs.com/hackxiyu/p/8072314.html】
• 使用ELK工具進行集中式日誌管理

 

解決：

---

• 參考文章：基於微服務的日誌系統【http://www.fx361.com/page/2017/0315/1185754.shtml】　　

　　ELK Stack 是 Elasticsearch、Logstash、Kibana 三個開源軟件的組合。

　　和傳統的日誌處理方案相比，ELK Stack 具備以下幾個優勢：

• 　　處理方式靈活。Elasticsearch 是實時全文索引，不須要像 storm 那樣預先編程才能使用；
• 　　配置簡易上手。Elasticsearch 所有采用 JSON 接口，Logstash 是 Ruby DSL 設計，都是目前業界最通用的配置語法設計；
• 　　檢索性能高效。雖然每次查詢都是實時計算，可是優秀的設計和實現基本能夠達到全天數據查詢的秒級響應；
• 　　集羣線性擴展。不論是 Elasticsearch 集羣仍是 Logstash 集羣都是能夠線性擴展的；

---

 

• 參考文章：微服務的性能監控與日誌收集【https://baijia.baidu.com/s?old_id=478661】

　　傳統的日誌收集方案有Splunk、Logstash、Flume、Fluentd等，其中Splunk和Fluentd被列入了Docker官方文檔裏。Fluentd是一個出來時間不長，可是對傳統收集工具 Logstash挑戰比較大的收集方案，同時它也在去年被亞馬遜評爲最好的日誌收集工具。Splunk則是一套基於商業的解決方案，通常只有大型企業纔會使用，這種方案是目前最好的，但也是最昂貴的。

　　在其餘方案中，傳統的解決方案最多見的是Logstash，它的配合工具通常是Elasticsearch和Kibana。圖2是一張經典的ELK架構圖，首先在每個節點上部署一個Logstash數據端，稱爲shipper，而後搭一個redis的緩存，在redis緩存後面再用另外一個Logstash去作索引，稱爲indexer。之因此有這樣一個架構是由於Logstash自己運行效率率比較低，用的是JRuby語言，它使得索引不能在每個客戶端去作，由於會佔用很大的的內存。

　　Fluentd的方案與Logstash差很少，可是它能夠省掉Indexer這層，並且它的核心代碼是C++寫的，從效率上說會比Logstash高不少。除此以外，Fluentd是除了Splunk之外惟一一個在Docker官方日誌驅動裏面的工具。通常來講,日誌收集是經過收集文件的方式進行的，由於Docker會默認將容器的日誌放到一個指定的目錄裏。Logstash會去搜集目錄裏面的日誌，可是存在一個問題，就是Logstash在蒐集的時候是每隔必定的時間在目錄裏面作一次查詢，這樣極可能由於監測的服務出故障形成日誌丟失。Fluentd則不只支持Logstash那種文件的方式去搜集日誌，還能夠經過Docker的Fluentd driver直接定向蒐集，可是蒐集的日誌Docker log命令是看不到的。對用戶而言，能夠根據實際的應用產品，對這兩種方式進行選擇。