大家好！我是來自虎牙直播技術保障部的張波。今天主要會從數據挖掘層面跟大家探討一下 Nginx 的價值。OpenResty 在虎牙的應用場景主要 WAF 和流控等方面，我今天主要分享的是“ Nginx 日志”，因為這在虎牙產生過巨大的價值，簡單來說，我們最終做到的效果就是每年節省數百上千萬的成本。
Nginx 是現在最流行的負載均衡和反向代理服務器之一，僅 Nginx 每天就會產生上百 M 甚至數十 G 的日志文件。但又有多少人關注過它背后的價值呢？
常見故障處理場景
舉個經典的 CDN 故障處理場景：
- 用戶報障頁面訪問不了
- 開發上系統運行一切正常
- 開發向運維要求提供系統原始日志幫忙定位問題
- 運維聯系 CDN 運營商排查問題
- 等待 CDN 廠商解決問題
這里舉個簡單的例子：通常一個 Web 的故障，用戶報障頁面訪問不了，那么開發會上系統去查看監控數據，得到的結論可能是“我負責的系統沒問題”。然后會要求運維去介入，比如通過原始日志幫他定位，但運維可能依然得出一個結論“我這邊還是沒有問題”，即服務端也沒有問題。但是用戶報障了，肯定存在問題，那這種問題怎么繼續排查下去呢？接下來，運維要去聯系 CDN 廠商，一起協助去定位問題，最后等待 CDN 廠商解決。
這個流程中，客服聯系到開發可能需要 30 分鍾，開發再聯系運維可能要 15 分鍾，這還不包含過程定位問題需要的時間。尤其是在最后一個環節，還要聯系 CDN 廠商，這可能已經跨公司溝通了，這樣處理下來最少需要 5 個小時，才能找到問題的真實原因，但是你的業務是否可以承擔 5 個小時的等待？
今天主要跟大家探討一下，這類問題是否有更好的解決方案，當然也不是在所有的場景下都適合，但是大部分場景通過這些解決方法是可以做到分鍾級定位根因的。
業務故障常用參數
△ Nginx 日志
這是一個普通的 Nginx 日志，有用戶 IP、來源 IP，后端 stream IP、請求時間、狀態碼等信息。
△ CDN 側日志信息
這是 CDN 側的日志信息，相比於 Nginx 日志格式，它會多幾個信息，例如邊緣節點IP、緩沖命中率，以及 CDN 廠商類型的一些字段，總體它跟 Nginx 字段是類似的。
△ 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 就是應用不良的一個指標。它的模型非常簡單，通常有三個樣本：失望、容忍和滿意。
△ 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）復算帶寬系數
以上是我們的獨立復算邏輯，實測的下載帶寬跟用戶記錄的帶寬，會覆蓋 90% 流量的場景。比如流量來自於哪些業務，我們會覆蓋 90% 以上的業務。業務的低峰時間段會去撥測，其實這個服務並不會占用我們的帶寬成本，比如在凌晨 3 點到下午 3 點持續對帶寬進行撥測，保證測試的樣本數是足夠的。通過 CDN 的復算總帶寬跟 CDN API 計費帶寬進行對比，最終算出它們的誤差，
三線路碼率偏差對比
虎牙用的主要使用的是 CDN 視頻流，我們對不同碼率和誤差也做了監控，曾今出現過一個 CDN 廠商，我們要求的是 2M，那單個用戶調度進來就應該是 2M，但是有廠商設到 2.25，即用戶調到他那邊去，憑空就多了 10%。后面我們及時修復了，當時我們也沒有去追責，但是挽回了公司在這個 CDN 廠商 10% 的成本。
最終我們去做結費，最終會得出幾個值，一是撥測的誤差，二是計費的總誤差，以及計費的具體誤差值，通過這些值計算來復查核算成本。
最后分享下開源工具，能更好的去做數據分析。
1.ELK
http://2.Druid.io，Kylin
3.Storm，Spark
分享PPT和演講視頻觀看：