自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

系統(tǒng)、應(yīng)用監(jiān)控的縝密思路,堪稱性能瓶頸的克星

開(kāi)發(fā) 測(cè)試
要做好監(jiān)控,最核心的就是全面的、可量化的指標(biāo),這包括系統(tǒng)和應(yīng)用兩個(gè)方面。從系統(tǒng)來(lái)說(shuō),監(jiān)控系統(tǒng)要涵蓋系統(tǒng)的整體資源使用情況,而從應(yīng)用程序來(lái)說(shuō),監(jiān)控系統(tǒng)要涵蓋應(yīng)用程序內(nèi)部的運(yùn)行狀態(tài)。

一、起始

在實(shí)際的性能分析中,一個(gè)很常見(jiàn)的現(xiàn)象是,明明發(fā)生了性能瓶頸,但當(dāng)你登錄到服務(wù)器中想要排查的時(shí)候,卻發(fā)現(xiàn)瓶頸已經(jīng)消失了?;蛘哒f(shuō),性能問(wèn)題總是時(shí)不時(shí)地發(fā)生,但卻很難找出發(fā)生規(guī)律,也很難重現(xiàn)。

而要解決這個(gè)問(wèn)題,就要搭建監(jiān)控系統(tǒng),把系統(tǒng)和應(yīng)用程序的運(yùn)行狀況監(jiān)控起來(lái),并定義一系列的策略,在發(fā)生問(wèn)題時(shí)第一時(shí)間告警通知。一個(gè)好的監(jiān)控系統(tǒng),不僅可以實(shí)時(shí)暴露系統(tǒng)的各種問(wèn)題,更可以根據(jù)這些監(jiān)控到的狀態(tài),自動(dòng)分析和定位大致的瓶頸來(lái)源,從而更精確地把問(wèn)題匯報(bào)給相關(guān)團(tuán)隊(duì)處理。要做好監(jiān)控,最核心的就是全面的、可量化的指標(biāo),這包括系統(tǒng)和應(yīng)用兩個(gè)方面。

從系統(tǒng)來(lái)說(shuō),監(jiān)控系統(tǒng)要涵蓋系統(tǒng)的整體資源使用情況,比如我們前面講過(guò)的 CPU、內(nèi)存、磁盤(pán)和文件系統(tǒng)、網(wǎng)絡(luò)等各種系統(tǒng)資源。

而從應(yīng)用程序來(lái)說(shuō),監(jiān)控系統(tǒng)要涵蓋應(yīng)用程序內(nèi)部的運(yùn)行狀態(tài),這既包括進(jìn)程的 CPU、磁盤(pán) I/O 等整體運(yùn)行狀況,更需要包括諸如接口調(diào)用耗時(shí)、執(zhí)行過(guò)程中的錯(cuò)誤、內(nèi)部對(duì)象的內(nèi)存使用等應(yīng)用程序內(nèi)部的運(yùn)行狀況。

二、系統(tǒng)監(jiān)控

1、USE 法

在開(kāi)始監(jiān)控系統(tǒng)之前,你肯定最想知道,怎么才能用簡(jiǎn)潔的方法,來(lái)描述系統(tǒng)資源的使用情況。你當(dāng)然可以使用專欄中學(xué)到的各種性能工具,來(lái)分別收集各種資源的使用情況。不過(guò)不要忘記,每種資源的性能指標(biāo)可都有很多,使用過(guò)多指標(biāo)本身耗時(shí)耗力不說(shuō),也不容易為你建立起系統(tǒng)整體的運(yùn)行狀況。

在這里,我為你介紹一種專門(mén)用于性能監(jiān)控的 USE(Utilization Saturation and Errors)法。

USE 法把系統(tǒng)資源的性能指標(biāo),簡(jiǎn)化成了三個(gè)類別,即使用率、飽和度以及錯(cuò)誤數(shù)。

使用率,表示資源用于服務(wù)的時(shí)間或容量百分比。100% 的使用率,表示容量已經(jīng)用盡或者全部時(shí)間都用于服務(wù)。

飽和度,表示資源的繁忙程度,通常與等待隊(duì)列的長(zhǎng)度相關(guān)。100% 的飽和度,表示資源無(wú)法接受更多的請(qǐng)求。

錯(cuò)誤數(shù)表示發(fā)生錯(cuò)誤的事件個(gè)數(shù)。錯(cuò)誤數(shù)越多,表明系統(tǒng)的問(wèn)題越嚴(yán)重。

這三個(gè)類別的指標(biāo),涵蓋了系統(tǒng)資源的常見(jiàn)性能瓶頸,所以常被用來(lái)快速定位系統(tǒng)資源的性能瓶頸。這樣,無(wú)論是對(duì) CPU、內(nèi)存、磁盤(pán)和文件系統(tǒng)、網(wǎng)絡(luò)等硬件資源,還是對(duì)文件描述符數(shù)、連接數(shù)、連接跟蹤數(shù)等軟件資源,USE 方法都可以幫你快速定位出,是哪一種系統(tǒng)資源出現(xiàn)了性能瓶頸。

2、性能指標(biāo)

那么,對(duì)于每一種系統(tǒng)資源,又有哪些常見(jiàn)的性能指標(biāo)呢?回憶一下我們講過(guò)的各種系統(tǒng)資源原理,并不難想到相關(guān)的性能指標(biāo)。這里,我把常見(jiàn)的性能指標(biāo)畫(huà)了一張表格,方便你在需要時(shí)查看。

不過(guò),需要注意的是,USE 方法只關(guān)注能體現(xiàn)系統(tǒng)資源性能瓶頸的核心指標(biāo),但這并不是說(shuō)其他指標(biāo)不重要。諸如系統(tǒng)日志、進(jìn)程資源使用量、緩存使用量等其他各類指標(biāo),也都需要我們監(jiān)控起來(lái)。只不過(guò),它們通常用作輔助性能分析,而 USE 方法的指標(biāo),則直接表明了系統(tǒng)的資源瓶頸。

3、監(jiān)控系統(tǒng)

掌握 USE 方法以及需要監(jiān)控的性能指標(biāo)后,接下來(lái)要做的,就是建立監(jiān)控系統(tǒng),把這些指標(biāo)保存下來(lái);然后,根據(jù)這些監(jiān)控到的狀態(tài),自動(dòng)分析和定位大致的瓶頸來(lái)源;最后,再通過(guò)告警系統(tǒng),把問(wèn)題及時(shí)匯報(bào)給相關(guān)團(tuán)隊(duì)處理。

可以看出,一個(gè)完整的監(jiān)控系統(tǒng)通常由數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)查詢和處理、告警以及可視化展示等多個(gè)模塊組成。所以,要從頭搭建一個(gè)監(jiān)控系統(tǒng),其實(shí)也是一個(gè)很大的系統(tǒng)工程。

不過(guò),幸運(yùn)的是,現(xiàn)在已經(jīng)有很多開(kāi)源的監(jiān)控工具可以直接使用,比如最常見(jiàn)的 Zabbix、Nagios、Prometheus 等等。

下面,我就以 Prometheus 為例,為你介紹這幾個(gè)組件的基本原理。如下圖所示,就是 Prometheus 的基本架構(gòu):

(圖片來(lái)自 prometheus.io)

先看數(shù)據(jù)采集模塊。最左邊的 Prometheus targets 就是數(shù)據(jù)采集的對(duì)象,而 Retrieval 則負(fù)責(zé)采集這些數(shù)據(jù)。從圖中你也可以看到,Prometheus 同時(shí)支持 Push 和 Pull 兩種數(shù)據(jù)采集模式。

Pull 模式,由服務(wù)器端的采集模塊來(lái)觸發(fā)采集。只要采集目標(biāo)提供了 HTTP 接口,就可以自由接入(這也是最常用的采集模式)。

Push 模式,則是由各個(gè)采集目標(biāo)主動(dòng)向 Push Gateway(用于防止數(shù)據(jù)丟失)推送指標(biāo),再由服務(wù)器端從 Gateway 中拉取過(guò)去(這是移動(dòng)應(yīng)用中最常用的采集模式)。

第二個(gè)是數(shù)據(jù)存儲(chǔ)模塊。為了保持監(jiān)控?cái)?shù)據(jù)的持久化,圖中的 TSDB(Time series database)模塊,負(fù)責(zé)將采集到的數(shù)據(jù)持久化到 SSD 等磁盤(pán)設(shè)備中。TSDB 是專門(mén)為時(shí)間序列數(shù)據(jù)設(shè)計(jì)的一種數(shù)據(jù)庫(kù),特點(diǎn)是以時(shí)間為索引、數(shù)據(jù)量大并且以追加的方式寫(xiě)入。

第三個(gè)是數(shù)據(jù)查詢和處理模塊。剛才提到的 TSDB,在存儲(chǔ)數(shù)據(jù)的同時(shí),其實(shí)還提供了數(shù)據(jù)查詢和基本的數(shù)據(jù)處理功能,而這也就是 PromQL 語(yǔ)言。PromQL 提供了簡(jiǎn)潔的查詢、過(guò)濾功能,并且支持基本的數(shù)據(jù)處理方法,是告警系統(tǒng)和可視化展示的基礎(chǔ)。

第四個(gè)是告警模塊。右上角的 AlertManager 提供了告警的功能,包括基于 PromQL 語(yǔ)言的觸發(fā)條件、告警規(guī)則的配置管理以及告警的發(fā)送等。不過(guò),雖然告警是必要的,但過(guò)于頻繁的告警顯然也不可取。所以,AlertManager 還支持通過(guò)分組、抑制或者靜默等多種方式來(lái)聚合同類告警,并減少告警數(shù)量。

最后一個(gè)是可視化展示模塊。Prometheus 的 web UI 提供了簡(jiǎn)單的可視化界面,用于執(zhí)行 PromQL 查詢語(yǔ)句,但結(jié)果的展示比較單調(diào)。不過(guò),一旦配合 Grafana,就可以構(gòu)建非常強(qiáng)大的圖形界面了。介紹完了這些組件,想必你對(duì)每個(gè)模塊都有了比較清晰的認(rèn)識(shí)。接下來(lái),我們?cè)賮?lái)繼續(xù)深入了解這些組件結(jié)合起來(lái)的整體功能。比如,以剛才提到的 USE 方法為例,我使用 Prometheus,可以收集 Linux 服務(wù)器的 CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)等各類資源的使用率、飽和度和錯(cuò)誤數(shù)指標(biāo)。然后,通過(guò) Grafana 以及 PromQL 查詢語(yǔ)句,就可以把它們以圖形界面的方式直觀展示出來(lái)。

4、最后總結(jié)

系統(tǒng)監(jiān)控的核心是資源的使用情況,這既包括 CPU、內(nèi)存、磁盤(pán)、文件系統(tǒng)、網(wǎng)絡(luò)等硬件資源,也包括文件描述符數(shù)、連接數(shù)、連接跟蹤數(shù)等軟件資源。而要描述這些資源瓶頸,最簡(jiǎn)單有效的方法就是 USE 法。

USE 法把系統(tǒng)資源的性能指標(biāo),簡(jiǎn)化為了三個(gè)類別:使用率、飽和度以及錯(cuò)誤數(shù)。當(dāng)這三者之中任一類別的指標(biāo)過(guò)高時(shí),都代表相對(duì)應(yīng)的系統(tǒng)資源可能存在性能瓶頸。

基于 USE 法建立性能指標(biāo)后,我們還需要通過(guò)一套完整的監(jiān)控系統(tǒng),把這些指標(biāo)從采集、存儲(chǔ)、查詢、處理,再到告警和可視化展示等貫穿起來(lái)。這樣,不僅可以將系統(tǒng)資源的瓶頸快速暴露出來(lái),還可以借助監(jiān)控的歷史數(shù)據(jù),來(lái)追蹤定位性能問(wèn)題的根源。

三、應(yīng)用監(jiān)控

1、應(yīng)用監(jiān)控指標(biāo)

跟系統(tǒng)監(jiān)控一樣,在構(gòu)建應(yīng)用程序的監(jiān)控系統(tǒng)之前,首先也需要確定,到底需要監(jiān)控哪些指標(biāo)。特別是要清楚,有哪些指標(biāo)可以用來(lái)快速確認(rèn)應(yīng)用程序的性能問(wèn)題。

應(yīng)用程序的核心指標(biāo),不再是資源的使用情況,而是請(qǐng)求數(shù)、錯(cuò)誤率和響應(yīng)時(shí)間。

這些指標(biāo)不僅直接關(guān)系到用戶的使用體驗(yàn),還反映應(yīng)用整體的可用性和可靠性。有了請(qǐng)求數(shù)、錯(cuò)誤率和響應(yīng)時(shí)間這三個(gè)黃金指標(biāo)之后,我們就可以快速知道,應(yīng)用是否發(fā)生了性能問(wèn)題。但是,只有這些指標(biāo)顯然還是不夠的,因?yàn)榘l(fā)生性能問(wèn)題后,我們還希望能夠快速定位“性能瓶頸區(qū)”。所以,在我看來(lái),下面幾種指標(biāo),也是監(jiān)控應(yīng)用程序時(shí)必不可少的。

第一個(gè),是應(yīng)用進(jìn)程的資源使用情況,比如進(jìn)程占用的 CPU、內(nèi)存、磁盤(pán) I/O、網(wǎng)絡(luò)等。使用過(guò)多的系統(tǒng)資源,導(dǎo)致應(yīng)用程序響應(yīng)緩慢或者錯(cuò)誤數(shù)升高,是一個(gè)最常見(jiàn)的性能問(wèn)題。

第二個(gè),是應(yīng)用程序之間調(diào)用情況,比如調(diào)用頻率、錯(cuò)誤數(shù)、延時(shí)等。由于應(yīng)用程序并不是孤立的,如果其依賴的其他應(yīng)用出現(xiàn)了性能問(wèn)題,應(yīng)用自身性能也會(huì)受到影響。

第三個(gè),是應(yīng)用程序內(nèi)部核心邏輯的運(yùn)行情況,比如關(guān)鍵環(huán)節(jié)的耗時(shí)以及執(zhí)行過(guò)程中的錯(cuò)誤等。由于這是應(yīng)用程序內(nèi)部的狀態(tài),從外部通常無(wú)法直接獲取到詳細(xì)的性能數(shù)據(jù)。所以,應(yīng)用程序在設(shè)計(jì)和開(kāi)發(fā)時(shí),就應(yīng)該把這些指標(biāo)提供出來(lái),以便監(jiān)控系統(tǒng)可以了解其內(nèi)部運(yùn)行狀態(tài)。

有了應(yīng)用進(jìn)程的資源使用指標(biāo),你就可以把系統(tǒng)資源的瓶頸跟應(yīng)用程序關(guān)聯(lián)起來(lái),從而迅速定位因系統(tǒng)資源不足而導(dǎo)致的性能問(wèn)題;

有了應(yīng)用程序之間的調(diào)用指標(biāo),你可以迅速分析出一個(gè)請(qǐng)求處理的調(diào)用鏈中,到底哪個(gè)組件才是導(dǎo)致性能問(wèn)題的罪魁禍?zhǔn)?

而有了應(yīng)用程序內(nèi)部核心邏輯的運(yùn)行性能,你就可以更進(jìn)一步,直接進(jìn)入應(yīng)用程序的內(nèi)部,定位到底是哪個(gè)處理環(huán)節(jié)的函數(shù)導(dǎo)致了性能問(wèn)題。

基于這些思路,我相信你就可以構(gòu)建出,描述應(yīng)用程序運(yùn)行狀態(tài)的性能指標(biāo)。再將這些指標(biāo)納入我們上一期提到的監(jiān)控系統(tǒng)(比如 Prometheus + Grafana)中,就可以跟系統(tǒng)監(jiān)控一樣,一方面通過(guò)告警系統(tǒng),把問(wèn)題及時(shí)匯報(bào)給相關(guān)團(tuán)隊(duì)處理;另一方面,通過(guò)直觀的圖形界面,動(dòng)態(tài)展示應(yīng)用程序的整體性能。

2、全鏈路監(jiān)控

業(yè)務(wù)系統(tǒng)通常會(huì)涉及到一連串的多個(gè)服務(wù),形成一個(gè)復(fù)雜的分布式調(diào)用鏈。為了迅速定位這類跨應(yīng)用的性能瓶頸,你還可以使用 Zipkin、Jaeger、Pinpoint 等各類開(kāi)源工具,來(lái)構(gòu)建全鏈路跟蹤系統(tǒng)。比如,下圖就是一個(gè) Jaeger 調(diào)用鏈跟蹤的示例。

(圖片來(lái)自 Jaeger 文檔)

全鏈路跟蹤可以幫你迅速定位出,在一個(gè)請(qǐng)求處理過(guò)程中,哪個(gè)環(huán)節(jié)才是問(wèn)題根源。比如,從上圖中,你就可以很容易看到,這是 Redis 超時(shí)導(dǎo)致的問(wèn)題。

全鏈路跟蹤除了可以幫你快速定位跨應(yīng)用的性能問(wèn)題外,還可以幫你生成線上系統(tǒng)的調(diào)用拓?fù)鋱D。這些直觀的拓?fù)鋱D,在分析復(fù)雜系統(tǒng)(比如微服務(wù))時(shí)尤其有效。

3、日志監(jiān)控

性能指標(biāo)的監(jiān)控,可以讓你迅速定位發(fā)生瓶頸的位置,不過(guò)只有指標(biāo)的話往往還不夠。比如,同樣的一個(gè)接口,當(dāng)請(qǐng)求傳入的參數(shù)不同時(shí),就可能會(huì)導(dǎo)致完全不同的性能問(wèn)題。所以,除了指標(biāo)外,我們還需要對(duì)這些指標(biāo)的上下文信息進(jìn)行監(jiān)控,而日志正是這些上下文的最佳來(lái)源。

對(duì)比來(lái)看,指標(biāo)是特定時(shí)間段的數(shù)值型測(cè)量數(shù)據(jù),通常以時(shí)間序列的方式處理,適合于實(shí)時(shí)監(jiān)控。

而日志則完全不同,日志都是某個(gè)時(shí)間點(diǎn)的字符串消息,通常需要對(duì)搜索引擎進(jìn)行索引后,才能進(jìn)行查詢和匯總分析。

對(duì)日志監(jiān)控來(lái)說(shuō),最經(jīng)典的方法,就是使用 ELK 技術(shù)棧,即使用 Elasticsearch、Logstash 和 Kibana 這三個(gè)組件的組合。

如下圖所示,就是一個(gè)經(jīng)典的 ELK 架構(gòu)圖:

(圖片來(lái)自elastic.co)

Logstash 負(fù)責(zé)對(duì)從各個(gè)日志源采集日志,然后進(jìn)行預(yù)處理,最后再把初步處理過(guò)的日志,發(fā)送給 Elasticsearch 進(jìn)行索引。

Elasticsearch 負(fù)責(zé)對(duì)日志進(jìn)行索引,并提供了一個(gè)完整的全文搜索引擎,這樣就可以方便你從日志中檢索需要的數(shù)據(jù)。

Kibana 則負(fù)責(zé)對(duì)日志進(jìn)行可視化分析,包括日志搜索、處理以及絢麗的儀表板展示等。

下面這張圖,就是一個(gè) Kibana 儀表板的示例,它直觀展示了 Apache 的訪問(wèn)概況。

(圖片來(lái)自elastic.co)

值得注意的是,ELK 技術(shù)棧中的 Logstash 資源消耗比較大。所以,在資源緊張的環(huán)境中,我們往往使用資源消耗更低的 Fluentd,來(lái)替代 Logstash(也就是所謂的 EFK 技術(shù)棧)。

4、最后總結(jié)

應(yīng)用程序的監(jiān)控,可以分為指標(biāo)監(jiān)控和日志監(jiān)控兩大部分:

指標(biāo)監(jiān)控主要是對(duì)一定時(shí)間段內(nèi)性能指標(biāo)進(jìn)行測(cè)量,然后再通過(guò)時(shí)間序列的方式,進(jìn)行處理、存儲(chǔ)和告警。

日志監(jiān)控則可以提供更詳細(xì)的上下文信息,通常通過(guò) ELK 技術(shù)棧來(lái)進(jìn)行收集、索引和圖形化展示。

在跨多個(gè)不同應(yīng)用的復(fù)雜業(yè)務(wù)場(chǎng)景中,你還可以構(gòu)建全鏈路跟蹤系統(tǒng)。這樣可以動(dòng)態(tài)跟蹤調(diào)用鏈中各個(gè)組件的性能,生成整個(gè)流程的調(diào)用拓?fù)鋱D,從而加快定位復(fù)雜應(yīng)用的性能問(wèn)題。

責(zé)任編輯:未麗燕 來(lái)源: cnblog.com
相關(guān)推薦

2022-03-03 11:04:37

監(jiān)控系統(tǒng)思路

2009-06-22 08:38:33

Windows 7微軟操作系統(tǒng)

2023-12-18 14:55:00

Oracle數(shù)據(jù)庫(kù)監(jiān)控

2021-04-30 15:45:42

存儲(chǔ)人工智能數(shù)據(jù)

2011-04-28 11:05:27

Windows 7

2020-11-11 10:00:13

NAT性能內(nèi)核

2018-02-05 09:30:23

高性能高并發(fā)服務(wù)

2021-11-23 09:45:26

架構(gòu)系統(tǒng)技術(shù)

2020-04-22 11:11:48

Decoder性能應(yīng)用

2019-02-20 12:37:39

NVMe存儲(chǔ)文件系統(tǒng)

2020-08-25 18:56:19

前端開(kāi)發(fā)技術(shù)

2009-05-15 09:31:31

網(wǎng)站性能延時(shí)Javascript

2017-08-11 19:13:01

LinuxNmon系統(tǒng)監(jiān)控工具

2015-05-12 15:02:23

API應(yīng)用性能監(jiān)控云智慧

2021-06-07 14:57:46

開(kāi)源開(kāi)源工具Linux

2011-11-03 10:45:09

京東性能瓶頸

2024-03-04 08:00:00

Java開(kāi)發(fā)

2022-08-16 09:23:54

分布式系統(tǒng)

2013-07-04 10:55:20

2019-09-11 10:23:58

Redis性能存儲(chǔ)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)