程序通訊過程監(jiān)控研究

鄭海能，葉阿真（.福富軟件，福建福州，35005；.福建信息職業(yè)技術(shù)學(xué)院，福建福州，35005)

程序通訊過程監(jiān)控研究

鄭海能1，葉阿真2
（1.福富軟件，福建福州，350025；2.福建信息職業(yè)技術(shù)學(xué)院，福建福州，350025)

應(yīng)用程序的通訊過程，由于其處于數(shù)據(jù)交換的過程中，一旦故障或性能不足，影響范圍巨大，所有的應(yīng)用通訊就會(huì)出現(xiàn)問題。因此對(duì)程序的通訊過程的實(shí)時(shí)監(jiān)控就尤為重要。如何確定監(jiān)控指標(biāo)和指標(biāo)的高效展示也十分重要。本文簡單探討程序的通訊過程的監(jiān)控指標(biāo)。

通訊過程；實(shí)時(shí)監(jiān)控；吞吐量監(jiān)控；鏈路監(jiān)控

0 引言

大部分的應(yīng)用系統(tǒng)，都需要和其他的系統(tǒng)實(shí)現(xiàn)數(shù)據(jù)互相交換，接口互相調(diào)用的過程。或者提供數(shù)據(jù)，提供服務(wù)，或者使用對(duì)方的數(shù)據(jù)或服務(wù)。而最基礎(chǔ)的交互過程，就是應(yīng)用的通訊過程。過程的穩(wěn)定性和可靠性，是平臺(tái)穩(wěn)定可靠的基礎(chǔ)。

特別是大數(shù)據(jù)技術(shù)出現(xiàn)后，大量的數(shù)據(jù)同時(shí)涌向一個(gè)平臺(tái)，一個(gè)應(yīng)用程序是在正常不過的事情。因此，如何梳理和有效建立平臺(tái)或應(yīng)用程序的通訊指標(biāo)，尤為重要。

許多通訊程序需要對(duì)某些特定的指標(biāo)進(jìn)行監(jiān)控，根據(jù)這些指標(biāo)大致分析通訊程序或服務(wù)端性能效率問題或其他網(wǎng)絡(luò)，負(fù)載等問題。比如，每秒的業(yè)務(wù)交易請(qǐng)求數(shù)量。業(yè)務(wù)交易請(qǐng)求是一個(gè)平臺(tái)所有的終端用戶在平臺(tái)上所有動(dòng)作組成的活動(dòng)視圖，可以直觀的反應(yīng)用戶的活動(dòng)；服務(wù)器響應(yīng)錯(cuò)誤率 ，這個(gè)指標(biāo)是服務(wù)器已經(jīng)多長時(shí)間無法接收或者無法處理有效的用戶活動(dòng)請(qǐng)求；請(qǐng)求響應(yīng)總時(shí)長，該指標(biāo)是服務(wù)器或通訊程序處理用戶端的交易請(qǐng)求的時(shí)長總和。

對(duì)通訊過程指標(biāo)，可以分為以下幾大類。

業(yè)務(wù)規(guī)模指標(biāo)：這類指標(biāo)一般是靜態(tài)的業(yè)務(wù)加載情況，根據(jù)業(yè)務(wù)加載的配置數(shù)據(jù)，可以進(jìn)行有效的統(tǒng)計(jì)分析。

性能指標(biāo)：這類指標(biāo)指平臺(tái)所承載的業(yè)務(wù)的交易量tps數(shù)據(jù)，即每秒所可能發(fā)生的交易請(qǐng)求數(shù)。

基本活動(dòng)指標(biāo)：指整個(gè)交易過程中，從連接建立，到通訊，到交易數(shù)據(jù)處理的過程指標(biāo)，這類指標(biāo)一般是通過日志進(jìn)行后續(xù)的分析與匯總。

錯(cuò)誤指標(biāo)：錯(cuò)誤指標(biāo)指的是，業(yè)務(wù)交易過程中，連接失敗，通訊處理失敗，交易處理失敗的內(nèi)容。

我們將分析在每個(gè)類別中最重要的指標(biāo)，本文也介紹了如何使用直觀的方式來展示，查看監(jiān)控所描述的指標(biāo)。

圖1 基本活躍指標(biāo)

1 指標(biāo)研究

1.1 基本活躍指標(biāo)

上圖顯示了客戶發(fā)起請(qǐng)求是，客戶端想服務(wù)端發(fā)起連接，服務(wù)端處理連接請(qǐng)求以及數(shù)據(jù)接收處理的過程，下文說明如何在此過程中收集基本活動(dòng)指標(biāo)。

Accepts接受連接、Handled連接已處理(如建立通道，拒絕連接等)、Requests交易請(qǐng)求數(shù)這些是作為計(jì)數(shù)器存在的，當(dāng)連接，處理，交易接收等觸發(fā)時(shí)，計(jì)數(shù)器進(jìn)行累加。Active活躍狀態(tài)、Waiting等待狀態(tài)、Reading讀狀態(tài)、Writing寫狀態(tài)，是狀態(tài)類型的變量，這些變量會(huì)隨著請(qǐng)求量的變化而增減。

當(dāng)通訊程序的服務(wù)端進(jìn)程接收到某個(gè)客戶端的連接請(qǐng)求時(shí)，Accepts接受連接計(jì)數(shù)器加1，Accepts值表明了當(dāng)前通訊程序接收到的連接請(qǐng)求數(shù)量；而Handled是當(dāng)前通訊程序服務(wù)端實(shí)際接收到請(qǐng)求，得到服務(wù)端響應(yīng)的數(shù)量，該變量只有在連接真正建立成功時(shí)，才進(jìn)行加1。在服務(wù)端資源充足，處理正常的時(shí)候這兩個(gè)變量的值是相等的。如果由于服務(wù)器或進(jìn)程資源的限制，比如已經(jīng)達(dá)到服務(wù)端最大的連接數(shù)限制，此時(shí)handled<=Accepts。當(dāng)Accepts–handled的差異越大，表明服務(wù)端越無法滿足用戶的請(qǐng)求了。

一旦服務(wù)端程序處理某個(gè)連接成功時(shí)，狀態(tài)機(jī)會(huì)轉(zhuǎn)義到活躍Active狀態(tài)，之后，通訊程序分配其他的進(jìn)程來處理客戶端的請(qǐng)求。活躍狀態(tài)的內(nèi)部，又可以分為等待，讀數(shù)據(jù)，寫數(shù)據(jù)等若干狀態(tài)。

當(dāng)請(qǐng)求處理完成后狀態(tài)機(jī)完成寫數(shù)據(jù)的狀態(tài)后，Accepts接受連接計(jì)數(shù)器，Handled連接已處理計(jì)數(shù)器各減1，回到上一次的狀態(tài)。

1.2 失敗連接數(shù)指標(biāo)

失敗的連接數(shù)等于接受和處理之間的差異。當(dāng)Accepts-Handled=0時(shí)，表明服務(wù)端運(yùn)行正常。如果單位時(shí)間內(nèi)，失敗連接速率開始增加并且持續(xù)上升，則表明，服務(wù)端無法完全響應(yīng)客戶端處理請(qǐng)求了，應(yīng)該檢查資源是否飽和。

1.3 每秒的請(qǐng)求數(shù)指標(biāo)

以定期間隔抽樣請(qǐng)求數(shù)據(jù)可提供每單位時(shí)間（通常是分鐘或秒）接收的請(qǐng)求數(shù)量的數(shù)據(jù)。監(jiān)視此指標(biāo)以查看服務(wù)端的流量峰值（無論是合法還是惡意），還是突然下降（通常表明存在問題）。每秒請(qǐng)求數(shù)量的急劇變化可以告警環(huán)境中的問題，即使它不能準(zhǔn)確地告訴您問題出在哪里。

1.4 請(qǐng)求處理時(shí)間指標(biāo)

請(qǐng)求處理時(shí)間指標(biāo)記錄了網(wǎng)關(guān)平臺(tái)處理每個(gè)請(qǐng)求的時(shí)間，從讀到客戶端的第一個(gè)請(qǐng)求字節(jié)到完成請(qǐng)求。

平臺(tái)需要記錄的四個(gè)時(shí)間點(diǎn)。

a)收到請(qǐng)求的時(shí)間

b)發(fā)送請(qǐng)求的時(shí)間

c)收到應(yīng)答的時(shí)間

d)發(fā)送應(yīng)答的時(shí)間

其中平臺(tái)的處理時(shí)長=（收到請(qǐng)求的時(shí)間-發(fā)送請(qǐng)求的時(shí)間）+(收到應(yīng)答的時(shí)間-發(fā)送應(yīng)答的時(shí)間 )

1.5 鏈路健康指標(biāo)

展示服務(wù)端協(xié)議的鏈路業(yè)務(wù)運(yùn)行情況(類似消息隊(duì)列)，展示當(dāng)前鏈路總共多少連接（線程）、多少連接（線程）在用、剩余多少連接（線程）待用；每個(gè)連接（線程）多少隊(duì)列，用了多少，剩余多少待用。

2 指標(biāo)展示

2.1 展示活躍指標(biāo)

服務(wù)端需要直觀的展示各個(gè)活躍度指標(biāo)。可以通過web頁面或者其他方式展示，以用于分析、可視化、或提醒。這些指標(biāo)至少需要指標(biāo)名稱，指標(biāo)狀態(tài)，與上個(gè)周期的變化百分比，正異常差異絕對(duì)值等。

2.2 錯(cuò)誤指標(biāo)

錯(cuò)誤指標(biāo)告訴你服務(wù)器是否經(jīng)常返回錯(cuò)誤而不是正常工作。客戶端錯(cuò)誤返回4XX狀態(tài)碼，服務(wù)端錯(cuò)誤返回5XX狀態(tài)碼。

名稱描述指標(biāo)類型可用于4xx 代碼客戶端錯(cuò)誤計(jì)數(shù)工作：錯(cuò)誤日志5xx 代碼服務(wù)器端錯(cuò)誤計(jì)數(shù)工作：錯(cuò)誤日志

2.3 服務(wù)端錯(cuò)誤率指標(biāo)

服務(wù)端數(shù)據(jù)處理的錯(cuò)誤率，極大的影響了用戶的使用感受，因此需要特別關(guān)注。服務(wù)端錯(cuò)誤率等于單位時(shí)間內(nèi)某個(gè)類型的錯(cuò)誤碼總數(shù)除以狀態(tài)碼的總數(shù)的百分比。如上表4xx錯(cuò)誤率= count(4xx錯(cuò)誤)/count(4xx錯(cuò)誤)+count(5xx錯(cuò)誤)。

當(dāng)錯(cuò)誤率指標(biāo)持續(xù)攀升時(shí)，需要立即檢查服務(wù)端的應(yīng)用。因?yàn)榇藭r(shí)，用戶已經(jīng)無法完成正常的業(yè)務(wù)處理了。

2.4 性能指標(biāo)

名稱描述指標(biāo)類型可用于request time（請(qǐng)求處理時(shí)間）處理每個(gè)請(qǐng)求的時(shí)間，單位為毫秒工作：性能日志

3 總結(jié)

在這篇文章中，我們分析了整個(gè)客戶端和服務(wù)端通訊的過程，談到了一些活動(dòng)指標(biāo)，錯(cuò)誤指標(biāo)，性能指標(biāo)的收集方式，展示方式。你可以使用這些指標(biāo)來監(jiān)控你的應(yīng)用。使用這些全部指標(biāo)，可以讓你很好的了解你的服務(wù)設(shè)施的健康和活躍程度。

a) 已丟棄的連接

b) 每秒請(qǐng)求數(shù)

c) 服務(wù)器錯(cuò)誤率

d) 請(qǐng)求處理數(shù)據(jù)

當(dāng)然，監(jiān)控哪一項(xiàng)指標(biāo)將取決于你想關(guān)注的點(diǎn)，和你集成的監(jiān)控界面。

[1] K Young.如何監(jiān)控 NGINX（第一篇） https://linux.cn/ article-5970-1.html 2015-8-17.

[2]王永銘. 過程監(jiān)控信息集成中的若干關(guān)鍵新技術(shù)研究[D].浙江大學(xué),2003.

[3]毛戰(zhàn)華. 嵌入式網(wǎng)絡(luò)攝像機(jī)的網(wǎng)絡(luò)通訊研究與實(shí)現(xiàn)[D].天津大學(xué),2005.

[4]CUI Jingsong,LIAO Kun,TIAN Changyou,PENG Rong,WU Xun. A Less Resource-Consumed Security Architecture on Cloud Platform[J]. Wuhan University Journal of Natural Sciences,2016,(05):407-414.

Research on Program Communication ProcedureMonitoring

Zheng Haineng1，Ye Azhen2
(1.Fu Fu software, Fuzhou Fujian, 350025;2.Fujian Polytechnic of Information Technology, Fujian Fuzhou, 350025)

the application of the communication process, because it is in the data exchange procedure, once the failure or lack of performance, the scope of the impact of a wide range of applications will be a problem. Therefore, the real-time monitoring of the communication process is particularly important. It is also important to determine the efficient display of monitoring indicators and indicators This paper simply discusses the monitoring index of the communication process

communication process; real-time monitoring; throughput monitoring; link monitoring