大家好！我是來自虎牙直播技術(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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。