微服務（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命令是看不到的。對用戶而言，可以根據實際的應用產品，對這兩種方式進行選擇。