虎牙直播张波:掘金Nginx日志
大家好!我是來自虎牙直播技術(shù)保障部的張波。今天主要會從數(shù)據(jù)挖掘?qū)用娓蠹姨接懸幌?Nginx 的價值。OpenResty 在虎牙的應用場景主要 WAF 和流控等方面,我今天主要分享的是“ Nginx 日志”,因為這在虎牙產(chǎn)生過巨大的價值,簡單來說,我們最終做到的效果就是每年節(jié)省數(shù)百上千萬的成本。
Nginx 是現(xiàn)在最流行的負載均衡和反向代理服務(wù)器之一,僅 Nginx 每天就會產(chǎn)生上百 M 甚至數(shù)十 G 的日志文件。但又有多少人關(guān)注過它背后的價值呢?
?
常見故障處理場景
舉個經(jīng)典的 CDN 故障處理場景:
- 用戶報障頁面訪問不了
- 開發(fā)上系統(tǒng)運行一切正常
- 開發(fā)向運維要求提供系統(tǒng)原始日志幫忙定位問題
- 運維聯(lián)系 CDN 運營商排查問題
- 等待 CDN 廠商解決問題
這里舉個簡單的例子:通常一個 Web 的故障,用戶報障頁面訪問不了,那么開發(fā)會上系統(tǒng)去查看監(jiān)控數(shù)據(jù),得到的結(jié)論可能是“我負責的系統(tǒng)沒問題”。然后會要求運維去介入,比如通過原始日志幫他定位,但運維可能依然得出一個結(jié)論“我這邊還是沒有問題”,即服務(wù)端也沒有問題。但是用戶報障了,肯定存在問題,那這種問題怎么繼續(xù)排查下去呢?接下來,運維要去聯(lián)系 CDN 廠商,一起協(xié)助去定位問題,最后等待 CDN 廠商解決。
這個流程中,客服聯(lián)系到開發(fā)可能需要 30 分鐘,開發(fā)再聯(lián)系運維可能要 15 分鐘,這還不包含過程定位問題需要的時間。尤其是在最后一個環(huán)節(jié),還要聯(lián)系 CDN 廠商,這可能已經(jīng)跨公司溝通了,這樣處理下來最少需要 5 個小時,才能找到問題的真實原因,但是你的業(yè)務(wù)是否可以承擔 5 個小時的等待?
今天主要跟大家探討一下,這類問題是否有更好的解決方案,當然也不是在所有的場景下都適合,但是大部分場景通過這些解決方法是可以做到分鐘級定位根因的。
?
業(yè)務(wù)故障常用參數(shù)
△ Nginx 日志
這是一個普通的 Nginx 日志,有用戶 IP、來源 IP,后端 stream IP、請求時間、狀態(tài)碼等信息。
△ CDN 側(cè)日志信息
這是 CDN 側(cè)的日志信息,相比于 Nginx 日志格式,它會多幾個信息,例如邊緣節(jié)點IP、緩沖命中率,以及 CDN 廠商類型的一些字段,總體它跟 Nginx 字段是類似的。
△ Nginx 日志-性能數(shù)據(jù)指標覆蓋
每一層關(guān)心的指標有細微差異,但基本上差不多。通過這些指數(shù),做成一個故障定位頁面,可以在各層實現(xiàn)快速定位。你可以定位到故障是發(fā)生在 IDC 層、CDN 層或者應用層。如果用一個頁面把收集的數(shù)據(jù)統(tǒng)一展示,即便是客服也可以快速定位到故障原因以及產(chǎn)生在哪里。
這就是剛才說的 5 個小時,實際上可能可以縮減到分鐘級別。比如已經(jīng)定位到是某個 CDN 廠商有問題,運維可以直接把這個 CDN 的廠商的流量切走,就可以使業(yè)務(wù)恢復了。
remote_addr
通過 remote_addr 字段可以分析出來 UV 計算、ISP 分布和地域分布這幾個指標,比如 UV 計算,UV 當然不能只是通過 IP,我們通常還會結(jié)合一些 UA 信息,支持更多的信息去計算 UV,但最重要的是 IP。通過 IP 可以分析出一些 ISP 分布和地域分布。因為故障有可能是在同一個 ISP 出現(xiàn)的,而其他 ISP 沒有問題。比如某個省份有問題,當你要做流量牽引的時候,其實這些數(shù)據(jù)是非常重要的,可以幫你去決策:你這一次問題是不是要去做,做怎么樣的牽引。
upstream_addr
△ 請求狀態(tài)統(tǒng)計
通過 upstream_addr 結(jié)合 send db 信息,可以知道服務(wù)分布在哪些機房,以及機房的哪些 IP 有問題,就可以結(jié)合自建機房或公有云機房去定位問題:這是不是在某個機房出現(xiàn)的問題,或者在某個機房轉(zhuǎn)發(fā)給另外一個機房出現(xiàn)的問題,都可以在這一側(cè)去定位。
body_bytes_sent
body_bytes_sent 是一個用戶接收的字節(jié),通過這你可以判斷到幾個點:一是機房的帶寬,二是用戶的平均下載速率。
通常來說,帶寬不是我們最關(guān)心的,但如果業(yè)務(wù)出現(xiàn)異常,異常流量特別大。比如域名被攻擊,或者服務(wù)出現(xiàn)異常,用戶端重復請求,導致機房流量接近崩潰,此時必須要去定位到突發(fā)流量來自于哪個域名,才能真正做到出問題迅速解決。
http_referer
http_referer 這個字段可以分析出流量來源、轉(zhuǎn)化率和 SEO 優(yōu)化。比如請求來源于百度、谷歌或其它導流的網(wǎng)站,那么用戶來自于哪里都可以通過這個分析出來。
http_user_agent
在 UA 這一層,可以分析出用戶的瀏覽器、操作系統(tǒng)分布以及對爬蟲的識別。
比如,比較良好的爬蟲他通常會帶上自己的 UA,你可以把這些 UA 的用戶指定到生產(chǎn)環(huán)境的備用集群,而不是讓爬蟲在生長環(huán)境的主服務(wù)器任意爬取。
request_time(upstream_response_time)
請求時間通??梢苑治龀鰜硌訒r分布和平均延時這兩個指標。基于此,后續(xù)可以深化另外一個指標,因為平均延時實際上作用并不大,可能有一些少量的錯誤請求把延時拉高,導致很容易誤報,誤報的情況下就會導致監(jiān)控是失效的。
request
request 通常會有返回碼的信息,比如你可以監(jiān)控到 URI 的分布,服務(wù)是全部請求用戶還是某個 URI 異常,通過這是可以分析并定位到具體原因。
?
業(yè)務(wù)故障快速定位
Apdex 量化應用性能
通過請求時間其實并不能很好地反饋應用的真實情況,Apdex 就是應用不良的一個指標。它的模型非常簡單,通常有三個樣本:失望、容忍和滿意。
△ Apdex 工作原理
通過上圖公式可以計算出來 0-1 的值,比如服務(wù)的平均延時是 50ms,用戶達到滿意 500ms 已經(jīng)夠了,那滿意樣本平均延時可以設(shè)在 500ms 以下;用戶如果等待 1s 已經(jīng)不能接受了,那么容忍樣本可以設(shè)在 1s 以下;1s 以上,你的用戶是不能接受的,可以定義成失望樣本。
這個指標可以反饋用戶的真實體驗,而平均延時并不能解決這個問題。這個指標只要出現(xiàn)問題,服務(wù)一定是有問題的。比如可用性要求到 99.99%,萬分之一的用戶受到影響,就應該處理了。
剛才定義的只是一個指標,比如請求延時,實際上還可以升華其它的指標跟它綁定,比如返回碼,返回延時、鏈接延時等一系列指標,只需要定義出業(yè)務(wù)真實受影響的一個值,以及它的條件,就可以定義出來三個樣本。通過這三個樣本,可以算出一個 0-1 的值,然后告警規(guī)則就可以在 0-1 去設(shè)置,比如 99%、98% 之類的就應該告警。這個可以真實反饋服務(wù)指標,相比于按延時或返回碼單純?nèi)ジ婢瘯蚀_很多。
同時還有另一個應用場景,就是系統(tǒng)化定位。如果反饋指標很多,我們既要參考返回碼,又要參考請求延時,還要參考鏈接延時等一系列指標,將所有指標都深化成 0-1 的值,就很容易去做定位。我們可以把所有設(shè)計的端都做染色,染色后就很容易把異常的顏色挑出來,這時再去定位根因,通過顏色就可以直接判斷哪一層出問題。
前面說的是每一層涉及的指標,分完層以后,可以按每一層的需要、指標去進行染色。服務(wù)在哪些機房,在哪些 CDN,通過故障定位的頁面就能看到所有指標,顏色也做了標記,任何一個人都可以定位到根因。雖然能夠定位到根因,也不一定能解決,但可以做到一個客服直接反饋給用戶是什么原因?qū)е碌?#xff0c;這樣用戶體驗會好很多,可以給客戶點小建議,讓他去嘗試一下切換網(wǎng)絡(luò)或者其他的一些操作等。
服務(wù)拓撲健康染色
△ 基于健康拓撲的染色情況
上圖是基于健康拓撲的染色情況,其實這是一個充值業(yè)務(wù),充值業(yè)務(wù)通常會由多個域名組成,每個域名、機房以及機器是否有問題,可以在這上面直接看到每一層的問題。
這個場景相對簡單,有些更復雜的可能幾十個域名在上面。網(wǎng)絡(luò)可能沒有問題,可能依賴的服務(wù)出現(xiàn)了問題,但是只要在這個地方,就可以全部找到。
?
業(yè)務(wù)數(shù)據(jù)跟蹤
賬單計算手段
我們通過日志挖掘了更大的價值,每年節(jié)省了數(shù)百上千萬的成本。我們做了跟 CDN 廠商的對賬,這個前提是虎牙大量使用了 CDN,這個 CDN 的成本可能占我們 IT 運營成本 50% 以上。
起初,我們對賬的方式是帶寬與業(yè)務(wù)指標的關(guān)聯(lián),對賬精度通常是 3%-8% 之間。因為 UA 不是真實的帶寬,即使指標出現(xiàn)異常,也沒辦法跟 CDN 廠商說“你這個帶寬數(shù)據(jù)有問題”,而在我們做監(jiān)控時經(jīng)常會發(fā)現(xiàn)超過 8% 的數(shù)據(jù)。
后來,我們做了另一個方案,可以看到不同的廠商計費手段不同,某些廠商可能不是基于日志的,而是基于交換機端口的流量。于是我們讓所有服務(wù)的 CDN 廠商統(tǒng)一切換到基于日志的計費方式,把所有日志傳回我們的服務(wù)器,進行數(shù)據(jù)的復算。
數(shù)據(jù)的確定方式還有另一個手段就是撥測。我們會模擬用戶的請求,通過對請求的跟蹤,最終算出來真實下載跟 CDN 統(tǒng)計值的誤差,撥測誤差小于 1%,基于 CDN 計算出來的總誤差小于 1%,我認為是可以接受的。實際我們做到的撥測誤差平均在 0.6% 左右,總帶寬誤差通常在 0.25% 左右。
獨立復算邏輯
1. 撥測實際下載帶寬 VS CDN 日志記錄帶寬
(1)覆蓋 90%+ 流量
(2)撥測時間段凌晨 3 點到下午 3 點
(3)撥測帶寬保證一定的量
2. CDN 日志復算總帶寬 VS CDN API 計費帶寬
(1)次日 6 點以后下載全部日志后計算
(2)API 獲取全部域名帶寬數(shù)據(jù)統(tǒng)計
3. 網(wǎng)卡流量 VS CDN 日志計算帶寬
(1)復算帶寬系數(shù)
以上是我們的獨立復算邏輯,實測的下載帶寬跟用戶記錄的帶寬,會覆蓋 90% 流量的場景。比如流量來自于哪些業(yè)務(wù),我們會覆蓋 90% 以上的業(yè)務(wù)。業(yè)務(wù)的低峰時間段會去撥測,其實這個服務(wù)并不會占用我們的帶寬成本,比如在凌晨 3 點到下午 3 點持續(xù)對帶寬進行撥測,保證測試的樣本數(shù)是足夠的。通過 CDN 的復算總帶寬跟 CDN API 計費帶寬進行對比,最終算出它們的誤差,
三線路碼率偏差對比
虎牙用的主要使用的是 CDN 視頻流,我們對不同碼率和誤差也做了監(jiān)控,曾今出現(xiàn)過一個 CDN 廠商,我們要求的是 2M,那單個用戶調(diào)度進來就應該是 2M,但是有廠商設(shè)到 2.25,即用戶調(diào)到他那邊去,憑空就多了 10%。后面我們及時修復了,當時我們也沒有去追責,但是挽回了公司在這個 CDN 廠商 10% 的成本。
最終我們?nèi)プ鼋Y(jié)費,最終會得出幾個值,一是撥測的誤差,二是計費的總誤差,以及計費的具體誤差值,通過這些值計算來復查核算成本。
?
最后分享下開源工具,能更好的去做數(shù)據(jù)分析。
1.ELK
http://2.Druid.io,Kylin
3.Storm,Spark
?
分享PPT和演講視頻觀看:
掘金 Nginx 日志
?
轉(zhuǎn)載于:https://www.cnblogs.com/upyun/p/10318450.html
總結(jié)
以上是生活随笔為你收集整理的虎牙直播张波:掘金Nginx日志的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: [VsCode] 开发所使用的VsCod
- 下一篇: 多域名下Mvc的Http缓存冲突的问题