ELK、EFK、Prometheus、SkyWalking、K8s的排列組合

EFK + K8s

prometheus+ K8s

SkyWalking + K8s

這3個監控組合都非常不錯，那在實際生產過程中，對一家中等規模的微服務業務應用，該如何選型呢？

如果企業采用spring + k8s技術棧，EFK + prometheus + SkyWalking就是我推薦的監控三套件，這三個分別是日志、metrics和調用鏈監控的利器，社區生態好。

而CAT主要為物理機/虛擬機場景研發，容器環境應該也支持，但是文檔資料較少。總體CAT是一個不錯的產品，但是相對門檻較高，社區和文檔不足。相比而言，skywalking門檻較低，社區文檔好，對容器環境有明確的支持。

方法級監控可以用Promethues，但是需要對方法進行埋點，如果是Spring應用，你用MicroMeter對方法添加相應的注解即可。注意，最好在框架層統一埋點。

Skywalking也可以監控到方法級，前提是需要相應的plugin支持，如果現成的plugin監控不到你的方法，你可以擴展或者自己寫plugin。

elastic不適合用于數據存儲 那我們項目里用elastic 也相當于給skywalking做了數據庫，穩定性和效率怎么看？

elastic屬于一種高性能大容量的nosql數據存儲，底層基于反向索引數據結構，在大數據存儲、搜索和分析方面有廣泛用途。它可以做skywalking的存儲，也可以做普通日志存儲。關于性能穩定性和效率，elastic本身是分布式高性能設計，實際要看你的調優和運維能力，國內公司如攜程，有超過50臺機器做成的elastic集群，每天收集存儲超過TB級別數據量。

fluentd V.S logstash 有何優勢在k8s中

不能說有明顯的優勢，logstash歷史比較老一點，fluentd比較新一點，目前是云原生支持的項目之一。盡管存在一些差異，但Logstash和Fluentd之間的相似之處大于它們的區別。 Logstash或Fluentd的用戶在日志管理方面遙遙領先。

skywalking可和EFK共用ES嗎？ES集群個數和內存CPU如何分配？

因為需使用istio的熔斷流量控制，istio也有一些trace什么的zipkin,怎么選擇？

skywalking當然可和efk共用ElasticSearch，它們用不同的index，實際要不要這樣弄，具體要考慮業務場景/容量需求等因素。集群節點個數和內存CPU建議先粗略估算，然后監控起來(ES有很多監控手段)，運行一段時間后根據監控數據優化容量規劃。

zipkin的trace監控是應用層的，可以和應用/框架代碼緊密集成，開發定制靈活性更高。istio的trace是系統層的，對應用層無傾入，但是開發人員的控制和定制弱。具體框架和運維團隊要協商綜合考慮，哪種更適合，當然也可以兩個都用結合起來。

架構圖

參考

https://logz.io/blog/fluentd-logstash/

Docker

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。