摘要：是由淘寶網(wǎng)發(fā)起的服務(wù)器項(xiàng)目?；卦幢O(jiān)控是內(nèi)容分發(fā)網(wǎng)絡(luò)的簡(jiǎn)稱，其分發(fā)的內(nèi)容來(lái)自用戶源站，負(fù)責(zé)回源的模塊是最重要組成部分之一，使跨越單機(jī)的限制，完成網(wǎng)絡(luò)數(shù)據(jù)的接收處理和轉(zhuǎn)發(fā)。這部分主要介紹的一些調(diào)試技巧和回源資源監(jiān)控的內(nèi)容，以及相應(yīng)的實(shí)例分享。

摘要： Tengine是由淘寶網(wǎng)發(fā)起的Web服務(wù)器項(xiàng)目。它在Nginx的基礎(chǔ)上，針對(duì)大訪問(wèn)量網(wǎng)站的需求，提供更強(qiáng)大的流量負(fù)載均衡能力、全站HTTPS服務(wù)、安全防攻擊、鏈路追蹤等眾多高級(jí)特性。團(tuán)隊(duì)的核心成員來(lái)自于淘寶、搜狗等互聯(lián)網(wǎng)企業(yè)，從2011年12月開(kāi)始，Tengine成為一個(gè)開(kāi)源項(xiàng)目，團(tuán)隊(duì)在積極地開(kāi)發(fā)和維護(hù)著它，最終目標(biāo)是打造一個(gè)高效、穩(wěn)定、安全、易用的Web平臺(tái)。

Tengine是由淘寶網(wǎng)發(fā)起的Web服務(wù)器項(xiàng)目。它在Nginx的基礎(chǔ)上，針對(duì)大訪問(wèn)量網(wǎng)站的需求，提供更強(qiáng)大的流量負(fù)載均衡能力、全站HTTPS服務(wù)、安全防攻擊、鏈路追蹤等眾多高級(jí)特性。團(tuán)隊(duì)的核心成員來(lái)自于淘寶、搜狗等互聯(lián)網(wǎng)企業(yè)，從2011年12月開(kāi)始，Tengine成為一個(gè)開(kāi)源項(xiàng)目，團(tuán)隊(duì)在積極地開(kāi)發(fā)和維護(hù)著它，最終目標(biāo)是打造一個(gè)高效、穩(wěn)定、安全、易用的Web平臺(tái)。

阿里云CDN現(xiàn)在服務(wù)超過(guò)24萬(wàn)家客戶，Tengine作為接入層提供高性能Web Server服務(wù)，是CDN系統(tǒng)最核心的組件之一。無(wú)論是來(lái)自阿里集團(tuán)內(nèi)部還是外部客戶的流量服務(wù)，幾乎都是由Tengine承載?？梢院敛豢鋸埖卣f(shuō)，Tengine的服務(wù)質(zhì)量直接影響著國(guó)內(nèi)外無(wú)數(shù)大中小型Web站點(diǎn)的服務(wù)質(zhì)量和業(yè)務(wù)存活，所以，維護(hù)Tengine的穩(wěn)定性一直是我們團(tuán)隊(duì)的最高優(yōu)先級(jí)目標(biāo)之一。經(jīng)過(guò)了多年淘寶、天貓等大型網(wǎng)站雙十一活動(dòng)的洗禮，Tengine的性能和穩(wěn)定性已經(jīng)得到了很好的驗(yàn)證。

有一句俗語(yǔ)：“上帝說(shuō)要有光，于是便有了光?！鞍⒗镌聘呒?jí)開(kāi)發(fā)工程師墨飏說(shuō)，“Tengine在做工具化的時(shí)候，也基本沿襲了這樣的思路。在做開(kāi)發(fā)之前，我們會(huì)系統(tǒng)性地思考：我們需要面對(duì)什么樣的場(chǎng)景，會(huì)碰到什么樣的問(wèn)題，需要怎樣的調(diào)試技巧和工具，是否可以解決更多此類問(wèn)題，于是，我們的工具便會(huì)在這樣的思路下逐漸成型和完善。同時(shí)，在服務(wù)客戶的過(guò)程中，我們也會(huì)遇到各種新場(chǎng)景新問(wèn)題，為了定位和解決問(wèn)題，我們也會(huì)針對(duì)性地提出解決方案，沉淀出更多調(diào)試技巧和工具。作為一線開(kāi)發(fā)團(tuán)隊(duì)，我們一路走來(lái)積累了非常多調(diào)試技巧、工具化的經(jīng)驗(yàn)?！?/p>

本文由阿里云CDN團(tuán)隊(duì)的研發(fā)同學(xué)笑臣和墨飏帶來(lái)，從Tengine的內(nèi)存調(diào)試、核心結(jié)構(gòu)、upstream、coredump四個(gè)部分展開(kāi)，為大家整理和分享一些實(shí)踐經(jīng)驗(yàn)。

內(nèi)存調(diào)試——精準(zhǔn)定位問(wèn)題
Tengine作為C語(yǔ)言開(kāi)發(fā)的應(yīng)用，在內(nèi)存的使用中會(huì)碰到一些問(wèn)題，第一部分將重點(diǎn)介紹內(nèi)存調(diào)試方面的相關(guān)內(nèi)容。

從下圖可以清晰的看出，Tengine內(nèi)存分布可以從三個(gè)維度來(lái)理解：底層實(shí)現(xiàn)、抽象層、應(yīng)用層。

一、底層實(shí)現(xiàn)
Tengine底層實(shí)現(xiàn)依賴操作系統(tǒng)的內(nèi)存分配機(jī)制，常見(jiàn)的內(nèi)存分配器包括jemalloc(FreeBSD)、ptmalloc(glic)、tcmalloc(Google)，luajit則使用內(nèi)置的dlmalloc庫(kù)。Tengine在每個(gè)連接accept后會(huì)malloc一塊內(nèi)存，作為整個(gè)連接生命周期內(nèi)的內(nèi)存池， 當(dāng)HTTP請(qǐng)求到達(dá)的時(shí)候，又會(huì)malloc一塊當(dāng)前請(qǐng)求階段的內(nèi)存池, 因此對(duì)malloc的分配速度有一定的依賴關(guān)系。jemalloc的性能是ptmalloc的兩倍以上，我們?cè)谑褂肨engine的時(shí)候默認(rèn)采用jemalloc。jemalloc在追蹤實(shí)際內(nèi)存分配時(shí)可以使用“malloc_stats_print”來(lái)查看內(nèi)部細(xì)節(jié)，幫助定位內(nèi)存泄露等問(wèn)題。

二、nginx pool調(diào)試
在底層內(nèi)存分配工具無(wú)法定位問(wèn)題時(shí)，我們需要從抽象層分析出了什么問(wèn)題。
Tengine作為nginx 的fork，在使用nginx pool方面與官方nginx基本沒(méi)什么區(qū)別，它的內(nèi)存池管理機(jī)制在HTTP請(qǐng)求的任一階段都可能被調(diào)用來(lái)分配內(nèi)存，我們可以從內(nèi)存分配的真實(shí)函數(shù)調(diào)用來(lái)統(tǒng)計(jì)內(nèi)存分配的占用量、歷史數(shù)量、當(dāng)前數(shù)量、large alloc等。mod_debug_pool已經(jīng)在Tengine社區(qū)開(kāi)源，有興趣可以自行查閱文檔，它的原理是通過(guò)hook ngx_create_pool函數(shù)來(lái)記錄__func__/__LINE__，在需要排查問(wèn)題時(shí)可以展示歷史數(shù)據(jù)，從抽象層定位內(nèi)存泄露等問(wèn)題。

三、lua內(nèi)存統(tǒng)計(jì)
lua/luajit是另一個(gè)非常成熟的開(kāi)源項(xiàng)目，在nginx生態(tài)系統(tǒng)中，lua-nginx-module允許lua/luajit以虛擬機(jī)形式內(nèi)嵌到nginx提供強(qiáng)大的腳本能力，我們?cè)诎⒗镌艭DN海量業(yè)務(wù)開(kāi)發(fā)中大量使用到lua/luajit。在調(diào)試luajit內(nèi)存占用時(shí)，可以通過(guò)collectgarbage來(lái)展示總內(nèi)存占用量，通過(guò)掃描gc object，可以統(tǒng)計(jì)global_State中所有g(shù)c對(duì)象，OpenResty社區(qū)也提供了GDB工具來(lái)輸出gc對(duì)象的數(shù)量和內(nèi)存占用。

四、共享內(nèi)存調(diào)試
Tengine是多進(jìn)程服務(wù)模型，其進(jìn)程間的通信主要依賴操作系統(tǒng)共享內(nèi)存機(jī)制，隨著業(yè)務(wù)的發(fā)展共享內(nèi)存的使用頻率越來(lái)越高，如何去定位、調(diào)試共享內(nèi)存，是一個(gè)比較嚴(yán)峻的問(wèn)題，且業(yè)內(nèi)缺少相關(guān)工具。我們?cè)谡{(diào)試共享內(nèi)存問(wèn)題時(shí)，沉淀和開(kāi)源了mod_slab_stat工具，在Tengine社區(qū)可以查閱詳細(xì)的文檔，該工具統(tǒng)計(jì)和展示了每個(gè)zone的內(nèi)存分配細(xì)節(jié)，包括page、slab和alloc num等，突出業(yè)務(wù)通信內(nèi)容塊分布情況等。該工具適用于ngx shm，基于ngx slab的stub stats模塊是個(gè)例外。

以上，從底層實(shí)現(xiàn)、抽象層、應(yīng)用層三個(gè)維度，可以定位到絕大部分Tengine系統(tǒng)和業(yè)務(wù)的內(nèi)存問(wèn)題，包括一些內(nèi)存的調(diào)試技巧。

核心結(jié)構(gòu)——調(diào)試與解決故障
Tengine作為高性能服務(wù)器被廣泛應(yīng)用，它的核心框架和核心數(shù)據(jù)結(jié)構(gòu)決定了其承載服務(wù)的質(zhì)量。針對(duì)所遇到的CDN用戶上報(bào)故障的工單，比如請(qǐng)求異常、訪問(wèn)慢等，如何從Tengine核心結(jié)構(gòu)去調(diào)試、定位和解決問(wèn)題，是本部分要介紹的內(nèi)容。

Tengine主要的核心結(jié)構(gòu)包括連接、請(qǐng)求和計(jì)時(shí)器等。連接承載著請(qǐng)求，以連接池的形式提供前端、后端網(wǎng)絡(luò)服務(wù)，其異步事件驅(qū)動(dòng)的特性是Tengine高性能網(wǎng)絡(luò)服務(wù)的基石，而其事件模型又和計(jì)時(shí)器緊緊關(guān)聯(lián)，這些核心結(jié)構(gòu)組成了Tengine的核心框架。

要調(diào)試和定位Tengine網(wǎng)絡(luò)問(wèn)題，需要從連接、請(qǐng)求、計(jì)時(shí)器等多角度思考，從讀寫(xiě)請(qǐng)求狀態(tài)、解析請(qǐng)求階段、應(yīng)答輸出階段、建連等多維度采集，從而得到更詳細(xì)的全局監(jiān)控?cái)?shù)據(jù)。

Tengine在nginx stub status工具基礎(chǔ)上，開(kāi)發(fā)了tsar工具(已開(kāi)源)，來(lái)展示更細(xì)粒度的歷史資源監(jiān)控，包括應(yīng)用層QPS、HTTPS和網(wǎng)絡(luò)層的accept、讀寫(xiě)等待等?；趓eqstatus的域名級(jí)監(jiān)控，可以針對(duì)任意粒度域名級(jí)來(lái)統(tǒng)計(jì)請(qǐng)求數(shù)、連接數(shù)和5xx、4xx等狀態(tài)碼數(shù)量，還包括連接的復(fù)用情況等。

有了tsar和reqstatus工具，我們可以從全局來(lái)分析Tengine系統(tǒng)的服務(wù)和性能狀態(tài)，但是，這夠了么？CDN系統(tǒng)中，我們會(huì)遇到一些問(wèn)題，比如：為啥tengine/nginx訪問(wèn)慢？是因?yàn)榭蛻舳寺⒑蠖寺?、還是nginx本身hang??？如何去衡量“慢“？我們需要對(duì)請(qǐng)求時(shí)間進(jìn)一步細(xì)分。

Tengine新增了responsefirstbytetime、upstream_response_time、writewaittime、upstream_read_wait_time等變量來(lái)記錄從請(qǐng)求進(jìn)入到響應(yīng)結(jié)束整個(gè)請(qǐng)求流程中的包括不限于應(yīng)答首字節(jié)、后端應(yīng)答首字節(jié)、socket讀寫(xiě)等待時(shí)間總和等關(guān)鍵指標(biāo)。

Tengine在衡量和監(jiān)控請(qǐng)求卡頓時(shí)，將events cycle內(nèi)event平均處理時(shí)間和events cycle內(nèi)timer平均處理時(shí)間綜合來(lái)定位單cycle平均耗時(shí)長(zhǎng)的異常，常見(jiàn)的問(wèn)題如同步IO(磁盤(pán)負(fù)載高時(shí)寫(xiě)log卡頓)、CPU密集型執(zhí)行流(lua實(shí)現(xiàn)的CPU密集型邏輯)。

有些時(shí)候，我們無(wú)法從全局資源監(jiān)控角度定位問(wèn)題，這時(shí)候可以從ngx_cycles->connections[]來(lái)查詢當(dāng)前執(zhí)行的請(qǐng)求或連接結(jié)構(gòu)信息，通過(guò)gdb腳本來(lái)掃描worker內(nèi)當(dāng)前連接信息，查看和調(diào)試是否有請(qǐng)求堆積或連接泄露等問(wèn)題。mod_debug_conn(待開(kāi)源)工具是上述調(diào)試技巧的沉淀，它還可以幫助我們查看請(qǐng)求/連接的內(nèi)存占用、分析連接和請(qǐng)求上的各類信息。

同時(shí)，Tengine的計(jì)時(shí)器（timer）在異步業(yè)務(wù)場(chǎng)景中有重要作用，通過(guò)掃描計(jì)時(shí)器紅黑樹(shù)，分析每個(gè)event timer，我們可以調(diào)試和定位異步操作中的問(wèn)題。有時(shí)候我們?cè)谄交?jí)tengine服務(wù)時(shí)，worker一直處于shutting down狀態(tài)無(wú)法退出，其實(shí)便是因?yàn)橐恢贝嬖趖imer導(dǎo)致的。也可以通過(guò)hook ngx.timer.at函數(shù)來(lái)統(tǒng)計(jì)lua-nginx-module中的timer caller次數(shù)，解決timer超限的報(bào)錯(cuò)等。

回源監(jiān)控
CDN是內(nèi)容分發(fā)網(wǎng)絡(luò)的簡(jiǎn)稱，其分發(fā)的內(nèi)容來(lái)自用戶源站，負(fù)責(zé)回源的upstream模塊是Tengine最重要組成部分之一，使Tengine跨越單機(jī)的限制，完成網(wǎng)絡(luò)數(shù)據(jù)的接收、處理和轉(zhuǎn)發(fā)。這部分主要介紹upsteam的一些調(diào)試技巧和回源資源監(jiān)控的內(nèi)容，以及相應(yīng)的實(shí)例分享。

在上面的章節(jié)中，我們已經(jīng)分析過(guò)如何依靠Tengine提供的關(guān)鍵指標(biāo)來(lái)衡量和監(jiān)控請(qǐng)求卡頓，那么，我們同樣可以提出問(wèn)題：如何去分析請(qǐng)求代理或回源失??？是因?yàn)榭蛻舳酥鲃?dòng)斷連、后端異常還是請(qǐng)求超時(shí)？如何去分析真實(shí)的原因，從而實(shí)時(shí)監(jiān)控回源失敗，這也是經(jīng)常困擾CDN用戶和開(kāi)發(fā)人員的難題。

從Tengine的請(qǐng)求處理流程分析，客戶端在完成TCP三次握手后，比較常見(jiàn)的錯(cuò)誤是：1、客戶端異常斷開(kāi)連接；2、客戶端主動(dòng)斷開(kāi)連接；3、等待讀寫(xiě)客戶端超時(shí)。在Tengine讀取請(qǐng)求內(nèi)容后，解析客戶端請(qǐng)求失敗如請(qǐng)求行/請(qǐng)求頭等協(xié)議出錯(cuò)，在upstream模塊回源時(shí)，也可能發(fā)生連接后端失敗、后端異常斷開(kāi)連接、后端主動(dòng)斷開(kāi)連接、等待讀寫(xiě)后端超時(shí)、解析后端應(yīng)答頭失敗等錯(cuò)誤，我們可以從Tengine的錯(cuò)誤日志查看對(duì)應(yīng)的報(bào)錯(cuò)信息，在此基礎(chǔ)上，我們從ngx_http_upstream_connect、ngx_http_upstream_send_request、ngx_http_upstream_process_header、ngx_http_upstream_process_body_in_memory等回源關(guān)鍵函數(shù)切入，提供error flag來(lái)監(jiān)控真實(shí)的客戶端/回源失敗原因，將錯(cuò)誤統(tǒng)計(jì)輸出至訪問(wèn)日志、reqstatus工具等，關(guān)聯(lián)和分析域名/請(qǐng)求級(jí)別的回源失敗問(wèn)題，保障CDN服務(wù)的穩(wěn)定性。

現(xiàn)在，我們有了回源的關(guān)鍵指標(biāo)變量和error flag，可以依靠一些調(diào)試技巧來(lái)分享一個(gè)upstream問(wèn)題實(shí)例。如圖所示，當(dāng)客戶端請(qǐng)求通過(guò)Tengine upstream回源時(shí)，我們可能碰到這樣的問(wèn)題：

讀源站，讀滿buffer
發(fā)送buffer size數(shù)據(jù)給客戶端，全發(fā)完了
循環(huán)上述兩步驟…
繼續(xù)讀源站，讀出若干數(shù)據(jù)，且源站已讀完
發(fā)送部分給客戶端，未發(fā)完（客戶端卡或者其他原因）
再次讀upstream，讀出again（顯然，因?yàn)橹霸凑緮?shù)據(jù)讀完了)
繼續(xù)發(fā)送數(shù)據(jù)給客戶端，未發(fā)完（客戶端卡或者其他原因）
upstream回源先超時(shí)了，這個(gè)時(shí)候$error_flag表明等待讀源站超時(shí)，但是事實(shí)是這樣嗎?
我們提供了完整的復(fù)現(xiàn)方法，如圖所示：

站在上帝視角，很明顯可以看到其實(shí)是客戶端問(wèn)題，但是回源采集的關(guān)鍵指標(biāo)：errorflag、upstream_read_wait_time、$write_wait_time，卻告訴我們是源站出錯(cuò)導(dǎo)致的問(wèn)題，數(shù)據(jù)不會(huì)欺騙我們，那么問(wèn)題到底在哪里？

上述調(diào)試的一些技巧和回源監(jiān)控，幫助我們理解upstream模塊的原理：
1、upstream有2個(gè)計(jì)時(shí)器，前端的和后端的；
2、Tengine/Nginx即使寫(xiě)客戶端寫(xiě)不進(jìn)去，只要proxy buf沒(méi)滿也會(huì)嘗試讀后端，如果后端數(shù)據(jù)讀完了，會(huì)讀出EAGAIN；
3、后端計(jì)時(shí)器較短先超時(shí)了，關(guān)閉請(qǐng)求，此時(shí)往往認(rèn)為后端出錯(cuò)，真實(shí)情況是客戶端出錯(cuò)；

這個(gè)特殊實(shí)例，在某些場(chǎng)景下，甚至在很多的生成環(huán)境中，都是比較常見(jiàn)但卻往往被忽視的問(wèn)題，在幫助提升用戶體驗(yàn)和服務(wù)質(zhì)量的目標(biāo)下，即使是nginx核心代碼不易發(fā)現(xiàn)的bug，在完善的調(diào)試工具和回源監(jiān)控下，一樣無(wú)所遁形。有興趣的同學(xué)可以搜索nginx郵件列表來(lái)詳細(xì)了解問(wèn)題背景，雖然nginx 官方因?yàn)橐恍┰驔](méi)有合入該patch，我們?cè)赥engine中也做了多帶帶的優(yōu)化策略。

Coredump
coredump是Tengine這類C開(kāi)發(fā)的應(yīng)用程序比較常見(jiàn)的問(wèn)題，隨著業(yè)務(wù)的迅猛發(fā)展，coredump往往會(huì)變得越來(lái)越大，甚至越來(lái)越頻繁，我們從空間、數(shù)量、自動(dòng)分析等角度層層遞進(jìn)來(lái)優(yōu)化Tengine的coredump。

“cat /proc/PID/coredump_filter”這行指令幫助我們了解Linux操作系統(tǒng)coredump機(jī)制所支持的內(nèi)存形態(tài)，包括私有內(nèi)存、共享內(nèi)存等。我們?cè)谑褂肨engine時(shí)可以去除共享內(nèi)存，降低coredump文件大小。同時(shí)，也可以限制一定時(shí)間內(nèi)crash寫(xiě)coredump文件的次數(shù)，防止磁盤(pán)IO過(guò)高或磁盤(pán)空間被占滿，Tengine提供了“worker_core_limit”指令(待開(kāi)源)來(lái)限制至分鐘/小時(shí)/天級(jí)別。

現(xiàn)在我們已經(jīng)從空間和數(shù)量角度優(yōu)化了coredump，方便了調(diào)試。那么是否可以自動(dòng)化完成分析，提升定位問(wèn)題的速度？答案是肯定的。

我們通過(guò)gdb python腳本來(lái)自動(dòng)分析coredump文件，從中提取得到觸發(fā)問(wèn)題的請(qǐng)求的host、URL、headers等，有了這些信息，就可以不斷復(fù)現(xiàn)來(lái)快速調(diào)試和定位問(wèn)題。但是有時(shí)候，coredump棧并不能告訴我們完整的現(xiàn)場(chǎng)，而在crash時(shí)，Tengine丟失了日志中的請(qǐng)求信息，我們將這些信息記錄在環(huán)形內(nèi)存中，通過(guò)coredump文件將環(huán)形緩沖數(shù)據(jù)輸出到文件，環(huán)環(huán)相扣，完整的現(xiàn)場(chǎng)，真相只有一個(gè)。

原理：http://nginx.org/en/docs/ngx_...

事后諸葛只能查漏補(bǔ)缺，我們需要提前發(fā)現(xiàn)問(wèn)題，實(shí)時(shí)流量拷貝工具應(yīng)運(yùn)而生。http_copy是Tengine的擴(kuò)展模塊，可以實(shí)時(shí)放大轉(zhuǎn)發(fā)本機(jī)的流量(HTTP請(qǐng)求)，可以配置放大流量到指定地址和端口，也可設(shè)置放大的倍數(shù)和并發(fā)量等，更可以通過(guò)源站健康檢查來(lái)自動(dòng)關(guān)停流量，避免過(guò)大流量對(duì)Tengine和源站的正常服務(wù)造成影響。

在流量壓測(cè)／流量拷貝時(shí)，不需要真實(shí)返回響應(yīng)的內(nèi)容，減少帶寬消耗，drop_traffic工具添加body filter直接丟棄數(shù)據(jù)，或者截獲c->send_chain/c->send函數(shù)直接丟棄數(shù)據(jù)，在調(diào)試時(shí)發(fā)現(xiàn)問(wèn)題而不產(chǎn)生問(wèn)題。

以上就是阿里云CDN團(tuán)隊(duì)對(duì)于Tengine的內(nèi)存調(diào)試與資源監(jiān)控方面的一些實(shí)踐經(jīng)驗(yàn)，希望對(duì)于正在使用開(kāi)源Tengine的同學(xué)有一些幫助。

Tengine官網(wǎng)：http://tengine.taobao.org
Tengine Github：https://github.com/alibaba/te...
阿里云CDN：https://www.aliyun.com/produc...
最后，阿里云CDN團(tuán)隊(duì)正在招聘志同道合的伙伴，歡迎加入~

原文鏈接