大家好！我是來自虎牙直播技術保障部的張波。今天主要會從資料探勘層面跟大家探討一下 Nginx 的價值。OpenResty 在虎牙的應用場景主要 WAF 和流控等方面，我今天主要分享的是“ Nginx 日誌”，因為這在虎牙產生過巨大的價值，簡單來說，我們最終做到的效果就是每年節省數百上千萬的成本。
Nginx 是現在最流行的負載均衡和反向代理伺服器之一，僅 Nginx 每天就會產生上百 M 甚至數十 G 的日誌檔案。但又有多少人關注過它背後的價值呢？
常見故障處理場景
舉個經典的 CDN 故障處理場景：
- 使用者報障頁面訪問不了
- 開發上系統執行一切正常
- 開發向運維要求提供系統原始日誌幫忙定位問題
- 運維聯絡 CDN 運營商排查問題
- 等待 CDN 廠商解決問題
這裡舉個簡單的例子：通常一個 Web 的故障，使用者報障頁面訪問不了，那麼開發會上系統去檢視監控資料，得到的結論可能是“我負責的系統沒問題”。然後會要求運維去介入，比如通過原始日誌幫他定位，但運維可能依然得出一個結論“我這邊還是沒有問題”，即服務端也沒有問題。但是使用者報障了，肯定存在問題，那這種問題怎麼繼續排查下去呢？接下來，運維要去聯絡 CDN 廠商，一起協助去定位問題，最後等待 CDN 廠商解決。
這個流程中，客服聯絡到開發可能需要 30 分鐘，開發再聯絡運維可能要 15 分鐘，這還不包含過程定位問題需要的時間。尤其是在最後一個環節，還要聯絡 CDN 廠商，這可能已經跨公司溝通了，這樣處理下來最少需要 5 個小時，才能找到問題的真實原因，但是你的業務是否可以承擔 5 個小時的等待？
今天主要跟大家探討一下，這類問題是否有更好的解決方案，當然也不是在所有的場景下都適合，但是大部分場景通過這些解決方法是可以做到分鐘級定位根因的。
業務故障常用引數
這是一個普通的 Nginx 日誌，有使用者 IP、來源 IP，後端 stream IP、請求時間、狀態碼等資訊。
這是 CDN 側的日誌資訊，相比於 Nginx 日誌格式，它會多幾個資訊，例如邊緣節點IP、緩衝命中率，以及 CDN 廠商型別的一些欄位，總體它跟 Nginx 欄位是類似的。
每一層關心的指標有細微差異，但基本上差不多。通過這些指數，做成一個故障定位頁面，可以在各層實現快速定位。你可以定位到故障是發生在 IDC 層、CDN 層或者應用層。如果用一個頁面把收集的資料統一展示，即便是客服也可以快速定位到故障原因以及產生在哪裡。
這就是剛才說的 5 個小時，實際上可能可以縮減到分鐘級別。比如已經定位到是某個 CDN 廠商有問題，運維可以直接把這個 CDN 的廠商的流量切走，就可以使業務恢復了。
remote_addr
通過 remote_addr 欄位可以分析出來 UV 計算、ISP 分佈和地域分佈這幾個指標，比如 UV 計算，UV 當然不能只是通過 IP，我們通常還會結合一些 UA 資訊，支援更多的資訊去計算 UV，但最重要的是 IP。通過 IP 可以分析出一些 ISP 分佈和地域分佈。因為故障有可能是在同一個 ISP 出現的，而其他 ISP 沒有問題。比如某個省份有問題，當你要做流量牽引的時候，其實這些資料是非常重要的，可以幫你去決策：你這一次問題是不是要去做，做怎麼樣的牽引。
upstream_addr
通過 upstream_addr 結合 send db 資訊，可以知道服務分佈在哪些機房，以及機房的哪些 IP 有問題，就可以結合自建機房或公有云機房去定位問題：這是不是在某個機房出現的問題，或者在某個機房轉發給另外一個機房出現的問題，都可以在這一側去定位。
body_bytes_sent
body_bytes_sent 是一個使用者接收的位元組，通過這你可以判斷到幾個點：一是機房的頻寬，二是使用者的平均下載速率。
通常來說，頻寬不是我們最關心的，但如果業務出現異常，異常流量特別大。比如域名被攻擊，或者服務出現異常，使用者端重複請求，導致機房流量接近崩潰，此時必須要去定位到突發流量來自於哪個域名，才能真正做到出問題迅速解決。
http_referer
http_referer 這個欄位可以分析出流量來源、轉化率和 SEO 優化。比如請求來源於百度、谷歌或其它導流的網站，那麼使用者來自於哪裡都可以通過這個分析出來。
http_user_agent
在 UA 這一層，可以分析出使用者的瀏覽器、作業系統分佈以及對爬蟲的識別。
比如，比較良好的爬蟲他通常會帶上自己的 UA，你可以把這些 UA 的使用者指定到生產環境的備用叢集，而不是讓爬蟲在生長環境的主伺服器任意爬取。
request_time（upstream_response_time）
請求時間通常可以分析出來延時分佈和平均延時這兩個指標。基於此，後續可以深化另外一個指標，因為平均延時實際上作用並不大，可能有一些少量的錯誤請求把延時拉高，導致很容易誤報，誤報的情況下就會導致監控是失效的。
request
request 通常會有返回碼的資訊，比如你可以監控到 URI 的分佈，服務是全部請求使用者還是某個 URI 異常，通過這是可以分析並定位到具體原因。
業務故障快速定位
Apdex 量化應用效能
通過請求時間其實並不能很好地反饋應用的真實情況，Apdex 就是應用不良的一個指標。它的模型非常簡單，通常有三個樣本：失望、容忍和滿意。
通過上圖公式可以計算出來 0-1 的值，比如服務的平均延時是 50ms，使用者達到滿意 500ms 已經夠了，那滿意樣本平均延時可以設在 500ms 以下；使用者如果等待 1s 已經不能接受了，那麼容忍樣本可以設在 1s 以下；1s 以上，你的使用者是不能接受的，可以定義成失望樣本。
這個指標可以反饋使用者的真實體驗，而平均延時並不能解決這個問題。這個指標只要出現問題，服務一定是有問題的。比如可用性要求到 99.99%，萬分之一的使用者受到影響，就應該處理了。
剛才定義的只是一個指標，比如請求延時，實際上還可以昇華其它的指標跟它繫結，比如返回碼，返回延時、連結延時等一系列指標，只需要定義出業務真實受影響的一個值，以及它的條件，就可以定義出來三個樣本。通過這三個樣本，可以算出一個 0-1 的值，然後告警規則就可以在 0-1 去設定，比如 99%、98% 之類的就應該告警。這個可以真實反饋服務指標，相比於按延時或返回碼單純去告警會準確很多。
同時還有另一個應用場景，就是系統化定位。如果反饋指標很多，我們既要參考返回碼，又要參考請求延時，還要參考連結延時等一系列指標，將所有指標都深化成 0-1 的值，就很容易去做定位。我們可以把所有設計的端都做染色，染色後就很容易把異常的顏色挑出來，這時再去定位根因，通過顏色就可以直接判斷哪一層出問題。
前面說的是每一層涉及的指標，分完層以後，可以按每一層的需要、指標去進行染色。服務在哪些機房，在哪些 CDN，通過故障定位的頁面就能看到所有指標，顏色也做了標記，任何一個人都可以定位到根因。雖然能夠定位到根因，也不一定能解決，但可以做到一個客服直接反饋給使用者是什麼原因導致的，這樣使用者體驗會好很多，可以給客戶點小建議，讓他去嘗試一下切換網路或者其他的一些操作等。
服務拓撲健康染色
上圖是基於健康拓撲的染色情況，其實這是一個充值業務，充值業務通常會由多個域名組成，每個域名、機房以及機器是否有問題，可以在這上面直接看到每一層的問題。
這個場景相對簡單，有些更復雜的可能幾十個域名在上面。網路可能沒有問題，可能依賴的服務出現了問題，但是隻要在這個地方，就可以全部找到。
業務資料跟蹤
賬單計算手段
我們通過日誌挖掘了更大的價值，每年節省了數百上千萬的成本。我們做了跟 CDN 廠商的對賬，這個前提是虎牙大量使用了 CDN，這個 CDN 的成本可能佔我們 IT 運營成本 50% 以上。
起初，我們對賬的方式是頻寬與業務指標的關聯，對賬精度通常是 3%-8% 之間。因為 UA 不是真實的頻寬，即使指標出現異常，也沒辦法跟 CDN 廠商說“你這個頻寬資料有問題”，而在我們做監控時經常會發現超過 8% 的資料。
後來，我們做了另一個方案，可以看到不同的廠商計費手段不同，某些廠商可能不是基於日誌的，而是基於交換機埠的流量。於是我們讓所有服務的 CDN 廠商統一切換到基於日誌的計費方式，把所有日誌傳回我們的伺服器，進行資料的復算。
資料的確定方式還有另一個手段就是撥測。我們會模擬使用者的請求，通過對請求的跟蹤，最終算出來真實下載跟 CDN 統計值的誤差，撥測誤差小於 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 獲取全部域名頻寬資料統計
3. 網路卡流量 VS CDN 日誌計算頻寬
（1）復算頻寬係數（通常是1.1）
以上是我們的獨立復算邏輯，實測的下載頻寬跟使用者記錄的頻寬，會覆蓋 90% 流量的場景。比如流量來自於哪些業務，我們會覆蓋 90% 以上的業務。業務的低峰時間段會去撥測，其實這個服務並不會佔用我們的頻寬成本，比如在凌晨 3 點到下午 3 點持續對頻寬進行撥測，保證測試的樣本數是足夠的。通過 CDN 的復算總頻寬跟 CDN API 計費頻寬進行對比，最終算出它們的誤差，
三線路位元速率偏差對比
虎牙用的主要使用的是 CDN 視訊流，我們對不同位元速率和誤差也做了監控，曾今出現過一個 CDN 廠商，我們要求的是 2M，那單個使用者排程進來就應該是 2M，但是有廠商設到 2.25，即使用者調到他那邊去，憑空就多了 10%。後面我們及時修復了，當時我們也沒有去追責，但是挽回了公司在這個 CDN 廠商 10% 的成本。
最終我們去做結費，最終會得出幾個值，一是撥測的誤差，二是計費的總誤差，以及計費的具體誤差值，通過這些值計算來複查核算成本。
最後分享下開源工具，能更好的去做資料分析。
1.ELK
2.Druid.io，Kylin
3.Storm，Spark
分享PPT和演講視訊觀看：