久久国产乱子伦精品免费M,亚洲一区二区三区91,欧美国产在线视频,国产精品视频久久

這篇監控系統的建設思路,讓你徹底找出性能瓶頸

一、起始

在實際的性能分析中,一個很常見的現象是,明明發生了性能瓶頸,但當你登錄到服務器中想要排查的時候,卻發現瓶頸已經消失了。或者說,性能問題總是時不時地發生,但卻很難找出發生規律,也很難重現。
而要解決這個問題,就要搭建監控系統,把系統和應用程序的運行狀況監控起來,并定義一系列的策略,在發生問題時第一時間告警通知。一個好的監控系統,不僅可以實時暴露系統的各種問題,更可以根據這些監控到的狀態,自動分析和定位大致的瓶頸來源,從而更精確地把問題匯報給相關團隊處理。要做好監控,最核心的就是全面的、可量化的指標,這包括系統和應用兩個方面。
從系統來說,監控系統要涵蓋系統的整體資源使用情況,比如我們前面講過的 CPU、內存、磁盤和文件系統、網絡等各種系統資源。
而從應用程序來說,監控系統要涵蓋應用程序內部的運行狀態,這既包括進程的 CPU、磁盤 I/O 等整體運行狀況,更需要包括諸如接口調用耗時、執行過程中的錯誤、內部對象的內存使用等應用程序內部的運行狀況。

二、系統監控

1、USE 法

在開始監控系統之前,你肯定最想知道,怎么才能用簡潔的方法,來描述系統資源的使用情況。你當然可以使用專欄中學到的各種性能工具,來分別收集各種資源的使用情況。不過不要忘記,每種資源的性能指標可都有很多,使用過多指標本身耗時耗力不說,也不容易為你建立起系統整體的運行狀況。
在這里,我為你介紹一種專門用于性能監控的 USE(Utilization Saturation and Errors)法。
USE 法把系統資源的性能指標,簡化成了三個類別,即使用率、飽和度以及錯誤數。
  • 使用率,表示資源用于服務的時間或容量百分比。100% 的使用率,表示容量已經用盡或者全部時間都用于服務。
  • 飽和度,表示資源的繁忙程度,通常與等待隊列的長度相關。100% 的飽和度,表示資源無法接受更多的請求。
  • 錯誤數表示發生錯誤的事件個數。錯誤數越多,表明系統的問題越嚴重。
這三個類別的指標,涵蓋了系統資源的常見性能瓶頸,所以常被用來快速定位系統資源的性能瓶頸。這樣,無論是對 CPU、內存、磁盤和文件系統、網絡等硬件資源,還是對文件描述符數、連接數、連接跟蹤數等軟件資源,USE 方法都可以幫你快速定位出,是哪一種系統資源出現了性能瓶頸。

2、性能指標

那么,對于每一種系統資源,又有哪些常見的性能指標呢?回憶一下我們講過的各種系統資源原理,并不難想到相關的性能指標。這里,我把常見的性能指標畫了一張表格,方便你在需要時查看。
圖片
不過,需要注意的是,USE 方法只關注能體現系統資源性能瓶頸的核心指標,但這并不是說其他指標不重要。諸如系統日志、進程資源使用量、緩存使用量等其他各類指標,也都需要我們監控起來。只不過,它們通常用作輔助性能分析,而 USE 方法的指標,則直接表明了系統的資源瓶頸。

3、監控系統

掌握 USE 方法以及需要監控的性能指標后,接下來要做的,就是建立監控系統,把這些指標保存下來;然后,根據這些監控到的狀態,自動分析和定位大致的瓶頸來源;最后,再通過告警系統,把問題及時匯報給相關團隊處理。
可以看出,一個完整的監控系統通常由數據采集、數據存儲、數據查詢和處理、告警以及可視化展示等多個模塊組成。所以,要從頭搭建一個監控系統,其實也是一個很大的系統工程。
不過,幸運的是,現在已經有很多開源的監控工具可以直接使用,比如最常見的 Zabbix、Nagios、Prometheus 等等。
下面,我就以 Prometheus 為例,為你介紹這幾個組件的基本原理。如下圖所示,就是 Prometheus 的基本架構:
圖片
先看數據采集模塊。最左邊的 Prometheus targets 就是數據采集的對象,而 Retrieval 則負責采集這些數據。從圖中你也可以看到,Prometheus 同時支持 Push 和 Pull 兩種數據采集模式。
Pull 模式,由服務器端的采集模塊來觸發采集。只要采集目標提供了 HTTP 接口,就可以自由接入(這也是最常用的采集模式)。
Push 模式,則是由各個采集目標主動向 Push Gateway(用于防止數據丟失)推送指標,再由服務器端從 Gateway 中拉取過去(這是移動應用中最常用的采集模式)。
第二個是數據存儲模塊。為了保持監控數據的持久化,圖中的 TSDB(Time series database)模塊,負責將采集到的數據持久化到 SSD 等磁盤設備中。TSDB 是專門為時間序列數據設計的一種數據庫,特點是以時間為索引、數據量大并且以追加的方式寫入。
第三個是數據查詢和處理模塊。剛才提到的 TSDB,在存儲數據的同時,其實還提供了數據查詢和基本的數據處理功能,而這也就是 PromQL 語言。PromQL 提供了簡潔的查詢、過濾功能,并且支持基本的數據處理方法,是告警系統和可視化展示的基礎。
第四個是告警模塊。右上角的 AlertManager 提供了告警的功能,包括基于 PromQL 語言的觸發條件、告警規則的配置管理以及告警的發送等。不過,雖然告警是必要的,但過于頻繁的告警顯然也不可取。所以,AlertManager 還支持通過分組、抑制或者靜默等多種方式來聚合同類告警,并減少告警數量。
最后一個是可視化展示模塊。Prometheus 的 web UI 提供了簡單的可視化界面,用于執行 PromQL 查詢語句,但結果的展示比較單調。不過,一旦配合 Grafana,就可以構建非常強大的圖形界面了。介紹完了這些組件,想必你對每個模塊都有了比較清晰的認識。接下來,我們再來繼續深入了解這些組件結合起來的整體功能。比如,以剛才提到的 USE 方法為例,我使用 Prometheus,可以收集 Linux 服務器的 CPU、內存、磁盤、網絡等各類資源的使用率、飽和度和錯誤數指標。然后,通過 Grafana 以及 PromQL 查詢語句,就可以把它們以圖形界面的方式直觀展示出來。
圖片

4、最后總結

系統監控的核心是資源的使用情況,這既包括 CPU、內存、磁盤、文件系統、網絡等硬件資源,也包括文件描述符數、連接數、連接跟蹤數等軟件資源。而要描述這些資源瓶頸,最簡單有效的方法就是 USE 法。
USE 法把系統資源的性能指標,簡化為了三個類別:使用率、飽和度以及錯誤數。當這三者之中任一類別的指標過高時,都代表相對應的系統資源可能存在性能瓶頸。
基于 USE 法建立性能指標后,我們還需要通過一套完整的監控系統,把這些指標從采集、存儲、查詢、處理,再到告警和可視化展示等貫穿起來。這樣,不僅可以將系統資源的瓶頸快速暴露出來,還可以借助監控的歷史數據,來追蹤定位性能問題的根源。

三、應用監控

1、應用監控指標

跟系統監控一樣,在構建應用程序的監控系統之前,首先也需要確定,到底需要監控哪些指標。特別是要清楚,有哪些指標可以用來快速確認應用程序的性能問題。
應用程序的核心指標,不再是資源的使用情況,而是請求數、錯誤率和響應時間。
這些指標不僅直接關系到用戶的使用體驗,還反映應用整體的可用性和可靠性。有了請求數、錯誤率和響應時間這三個黃金指標之后,我們就可以快速知道,應用是否發生了性能問題。但是,只有這些指標顯然還是不夠的,因為發生性能問題后,我們還希望能夠快速定位“性能瓶頸區”。所以,在我看來,下面幾種指標,也是監控應用程序時必不可少的。
第一個,是應用進程的資源使用情況,比如進程占用的 CPU、內存、磁盤 I/O、網絡等。使用過多的系統資源,導致應用程序響應緩慢或者錯誤數升高,是一個最常見的性能問題。
第二個,是應用程序之間調用情況,比如調用頻率、錯誤數、延時等。由于應用程序并不是孤立的,如果其依賴的其他應用出現了性能問題,應用自身性能也會受到影響。
第三個,是應用程序內部核心邏輯的運行情況,比如關鍵環節的耗時以及執行過程中的錯誤等。由于這是應用程序內部的狀態,從外部通常無法直接獲取到詳細的性能數據。所以,應用程序在設計和開發時,就應該把這些指標提供出來,以便監控系統可以了解其內部運行狀態。
有了應用進程的資源使用指標,你就可以把系統資源的瓶頸跟應用程序關聯起來,從而迅速定位因系統資源不足而導致的性能問題;
有了應用程序之間的調用指標,你可以迅速分析出一個請求處理的調用鏈中,到底哪個組件才是導致性能問題的罪魁禍首;
而有了應用程序內部核心邏輯的運行性能,你就可以更進一步,直接進入應用程序的內部,定位到底是哪個處理環節的函數導致了性能問題。
基于這些思路,我相信你就可以構建出,描述應用程序運行狀態的性能指標。再將這些指標納入我們上一期提到的監控系統(比如 Prometheus + Grafana)中,就可以跟系統監控一樣,一方面通過告警系統,把問題及時匯報給相關團隊處理;另一方面,通過直觀的圖形界面,動態展示應用程序的整體性能。

2、全鏈路監控

業務系統通常會涉及到一連串的多個服務,形成一個復雜的分布式調用鏈。為了迅速定位這類跨應用的性能瓶頸,你還可以使用 Zipkin、Jaeger、Pinpoint 等各類開源工具,來構建全鏈路跟蹤系統。比如,下圖就是一個 Jaeger 調用鏈跟蹤的示例。
圖片
全鏈路跟蹤可以幫你迅速定位出,在一個請求處理過程中,哪個環節才是問題根源。比如,從上圖中,你就可以很容易看到,這是 Redis 超時導致的問題。
全鏈路跟蹤除了可以幫你快速定位跨應用的性能問題外,還可以幫你生成線上系統的調用拓撲圖。這些直觀的拓撲圖,在分析復雜系統(比如微服務)時尤其有效。

3、日志監控

性能指標的監控,可以讓你迅速定位發生瓶頸的位置,不過只有指標的話往往還不夠。比如,同樣的一個接口,當請求傳入的參數不同時,就可能會導致完全不同的性能問題。所以,除了指標外,我們還需要對這些指標的上下文信息進行監控,而日志正是這些上下文的最佳來源。
對比來看,指標是特定時間段的數值型測量數據,通常以時間序列的方式處理,適合于實時監控。
而日志則完全不同,日志都是某個時間點的字符串消息,通常需要對搜索引擎進行索引后,才能進行查詢和匯總分析。
對日志監控來說,最經典的方法,就是使用 ELK 技術棧,即使用 Elasticsearch、Logstash 和 Kibana 這三個組件的組合。
如下圖所示,就是一個經典的 ELK 架構圖:
圖片
Logstash 負責對從各個日志源采集日志,然后進行預處理,最后再把初步處理過的日志,發送給 Elasticsearch 進行索引。
Elasticsearch 負責對日志進行索引,并提供了一個完整的全文搜索引擎,這樣就可以方便你從日志中檢索需要的數據。
Kibana 則負責對日志進行可視化分析,包括日志搜索、處理以及絢麗的儀表板展示等。
下面這張圖,就是一個 Kibana 儀表板的示例,它直觀展示了 Apache 的訪問概況。
圖片
值得注意的是,ELK 技術棧中的 Logstash 資源消耗比較大。所以,在資源緊張的環境中,我們往往使用資源消耗更低的 Fluentd,來替代 Logstash(也就是所謂的 EFK 技術棧)。

四、最后總結

應用程序的監控,可以分為指標監控和日志監控兩大部分:
指標監控主要是對一定時間段內性能指標進行測量,然后再通過時間序列的方式,進行處理、存儲和告警。
日志監控則可以提供更詳細的上下文信息,通常通過 ELK 技術棧來進行收集、索引和圖形化展示。
在跨多個不同應用的復雜業務場景中,你還可以構建全鏈路跟蹤系統。這樣可以動態跟蹤調用鏈中各個組件的性能,生成整個流程的調用拓撲圖,從而加快定位復雜應用的性能問題。

作者:-零

鏈接:https://www.cnblogs.com/-wenli/p/14017850.html

相關新聞

歷經多年發展,已成為國內好評如潮的Linux云計算運維、SRE、Devops、網絡安全、云原生、Go、Python開發專業人才培訓機構!

    1. 主站蜘蛛池模板: 和龙市| 拉孜县| 集贤县| 西畴县| 新平| 昌黎县| 克山县| 纳雍县| 本溪| 丰城市| 东乌珠穆沁旗| 平阴县| 乐业县| 合山市| 温泉县| 铁岭县| 石嘴山市| 红桥区| 永平县| 漯河市| 壶关县| 得荣县| 凌源市| 德庆县| 塔城市| 永泰县| 四川省| 张北县| 利川市| 安塞县| 靖边县| 黄龙县| 临泽县| 乡宁县| 闵行区| 花莲市| 北海市| 邵阳县| 丰县| 湖南省| 黔东|