當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

监控——《微服务设计》读书笔记

發布時間：2023/12/4 编程问答 41 豆豆

生活随笔收集整理的這篇文章主要介紹了监控——《微服务设计》读书笔记小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

? 在單塊應用的世界里，當我們遇到問題時，我們至少清楚從哪里開始調查。網站訪問速度？網站訪問異常？CPU占用過高？這些都是單塊應用程序的問題，單一的故障點會極大地簡化對問題的排查。

? ? ? 而現在我們面對了多個微服務，我們需要多個服務器、多個服務來完成我們的功能。那么如果現在生產服務延遲了，我們該從何查起呢？其實很簡單：監控單臺小的服務，然后聚合起來看整體。

監控模型

? ? ? 1.單一服務&單臺服務器

? ? ? 這種情況最簡單。

? ? ? 如果我們想監控主機本身如CPU、內存等這些物理指標，當它超出邊界時就會發生警告，我們可以使用Nagios、New Relic等這樣的服務來幫助我們。

? ? ? 如果我們想監控服務器記錄的日志，我們可以在單臺服務器使用命令行掃描日志，或者使用logrotate來管理日志就好了。

? ? ? 如果我們想監控服務器上的單個服務時，我們可以查看Web服務器或者應用程序的服務器就可以做到這一點。

? ? ? 2.單一服務&多臺服務器

? ? ? 這種情況稍微復雜了一點，如前所述，如果我們想監控CPU，當CPU占用率過高時，如果這個問題發生在所有的服務器上，有可能是微服務本身的問題，但如果只發生在一臺，則有可能是主機本身的問題。

? ? ? 我們需要關注每臺服務器的日志數據，我們既想把數據聚合起來，又想深入分析每臺主機，Nagios允許以這樣的方式組織我們的主機。

? ? ? 對于像時間這樣的監控，我們可以負載均衡器中進行追蹤，很容易就能拿到聚合后的數據，不過負載均衡器本身也需要監控，如果它的行為異常，也會導致問題。

? ? ? 3.多個服務&多臺服務器

? ? ? 這個情況就更復雜了，我們如何在多個主機上，成千上萬行的日志中定位錯誤的原因？如果確定是一個服務器異常，還是一個系統性的問題？如何在多個主機跟蹤一個錯誤的調用鏈，找出引起錯誤的原因？

? ? ? 答案是：從日志到應用程序指標，集中收集和聚合更可能多的數據。

收集多服務器的日志

? ? ? 我們需要將日志能夠集中到一起方便使用，logstash可以解析多種日志格式，將將它們發送給下游系統，比如發給Kibana，它是一個基于ElasticSearch查看日志的系統，你可以使用查詢語法、指定時間和日志范圍、正則表達式來搜索日志。它還可以把你的日志生成圖表。

收集多服務器的主機指標

? ? ? 我們有時還想了解各臺服務器的硬件指標信息，如CPU平均負載，單臺CPU的使用情況。我們可以使用Graphite來幫助我們，它允許你實時發送指標數據給它，它可以生成圖表或表格來呈現指標結果。Graphite允許你做跨樣本做聚合，或深入到某個部分，這樣就可以查看整個系統、一組服務或一個單獨實例的響應時間。

收集多服務器上應用程序的指標

? ? ??收集應用程序的指標不僅可以幫助我們改變程序，還可以幫助我們改變產品，我們可以知道哪些頁面被訪問，哪些是真正重要的功能。

語義監控

? ? ? 我們可以在生產環境運行一些測試用例，當這些案例如果沒有達到我們預期的值時，我們會認為生產環境的某個環境出問題了，甚至，我們可以在生產環境設置一組假用戶和一些已經的數據集。

關聯標識

? ? ? 請求的調用可以涉及到多個微服務，更為復雜的可能是一個請求鏈，并且以異步的方式觸發。我們如何才能重建請求流，以重現和解決這個問題呢？

? ? ? 使用關聯標識來解決，在觸發第一個調用時，生成一個唯一標識，然后把它傳遞給所有的后續調用。當然，使用這種方式，需要在團隊內部達成一致，或者形成一種標準，而現實是，我們可能是在碰到這樣的問題時才會想到這個辦法，或者即使有這個辦法，很難保證大家都會以正確的試調用。如果我們決定使用這樣一種特性，我們需要確定它不要太復雜且不依賴提供的任何特定服務，我們可以選擇在HTTP頭傳遞關聯標識即可。

? ? ? Zipkin和Dapper這樣的跟蹤系統值得我們去嘗試。

級聯

? ? ? 如果兩個服務單獨來看都是正常的，相互調用則不行，這又應該如何處理？因此，監控系統之間的集成點非常關鍵，每個服務的實例都應該追蹤和顯示其下游服務的健康狀態，從數據庫到其他合作服務。

標準化

? ? ? 監控這個領域的標準化是到頭重要的。

參考

? ? ? 《微服務設計》（Sam Newman 著 / 崔力強張駿譯）