我有一套服務。每項服務都包含一些組件。如何監控（微）服務？
其中有些是無狀態的，其中有些是有狀態的，有些是同步的，有些是異步的。
我用不同的方法來監測和警報。
基於日誌的警報和指標收集。 New Relic爲基礎。自行車。
基本上，ATM我正在尋找一種方式，如何推廣，並在一個地方的所有服務聚合的重要指標。其中一件事，我想要的是我們監視更多的產品，而不是單獨的服務。
作爲一個最終的結果我認爲這是與小部件的少量單一的儀表板，但看着那些小部件我能肯定地說，如果服務是可用於終端客戶。
也許有人可以給我推薦一些方法/方法。或者參考一些最佳實踐。
我喜歡你想要達到的目標！ 除非全面監控，否則服務不是生產就緒。
我相信您需要的資料描述進入的健康檢查和指標的主題。
......我可以肯定地說，如果服務可用於最終用戶。
然而，這將需要兩者的一小部分;-)爲確保您目前正在實現SLA，您必須確保您的服務都是a）正在運行並且b）按要求執行。有兩個問題，我建議看看StatsD工具鏈。最初由Etsy開發，它已成爲收集指標的事實標準。
爲了確保所有服務都在運行，我們中繼Kubernetes。它需要我們的描述來運行，可以從外部訪問等，並託管在我們的基礎設施上。它也確保，如果事情死亡 - 他們將被重新啓動。它有助於自動縮放等等。真棒工具和榮譽谷歌！ 它確保與健康檢查的方式。有多種方法可以確保您的服務節點由Kubernetes啓動並運行（即HTTP調用和CLI腳本，但如果您需要其他任何東西，則這應該是模塊化的）！如果Kubernetes檢測到不健康的節點，它將立即逐步停止並改爲啓動另一個節點。
現在，確保您的所有服務均按預期執行，您需要收集一些指標。對於我們所有的服務（和所有的個人終端）的，我們通過StatsD收集一些指標，如：
我們收集了很多指標，但這是關於底線。由於StatsD已經變得更多的是「協議規範」而不是具體的產品，因此有無數的收集器，前端和後端可供選擇。它們可以幫助您可視化您的系統狀態，並且其中許多功能會提醒某些事情或某些指標組合超出其閾值。
讓我知道，如果這是有益的！
你的方法是什麼？ – Marco