1.問題出現：

怕什麼來什麼，燦哥前腳剛走就來故障了。客服同事告知有臺裝置宕機了，重啟之後ats無法啟動。看了眼是/目錄滿了，清理了之後啟動ats正常，本以為就完事了，後來客服同事再次告知我，裝置流量異常，幾乎沒有命中。

這個是當時的流量圖（紅線框），可以看出回源幾乎100%了。上裝置看了眼，日誌請求的統計資訊中幾乎也是沒有HIT的內容，全都是各種MISS。

2.排查源站：

由於我們的業務特點，基本的回源率基本也保持在40%左右，其實也看源站了，如果做的源站都不讓存，那80、90%的回源率之前也有的，不過這些站點我們一般都發現了強制快取了。

從日誌中找了一個MISS的連結去直接在本機裝置抓取看下源站資訊：

發現源站是沒問題的，存在明確的快取控制頭資訊，沒道理存不下來的，很可能是裝置本身的問題了。

3.排查裝置配置：

前面已經判定了裝置服務的站點本身是沒問題的，那問題的焦點就集中在了裝置自身配置的問題了。

在裝置上代理本機的請求看下究竟是什麼情況：

發現多次抓取都是MISS掉了。

第一反應就是這裝置的records.config被修改了吧，估計是快取功能沒開啟，檢視相關配置：

http.cache.http 是開啟的，1表示開啟快取功能，其他的相關引數也沒有問題。看來不是這個的問題，那是不是磁碟的相關引數配置錯誤呢：

發現配置了使用的相關磁碟，也沒有大問題。

4.檢查cache空間

無奈找燦哥幫助，同時在群裡找大神幫忙，感謝北國、紙鳶兩位大神耐心幫我排查，最後helaku大神提醒我看下cache空間是不是為0了，echo “show:cache-stats” | traffic_shell看下：

發現cache空間果然為0，難怪無法快取。

5.確定問題：

現在問題很明確了就是無可用的儲存導致的，那麼肯定是磁碟故障了或者無許可權導致的。檢視啟動日誌：

從日誌中可以看出是相關的磁碟無讀寫許可權導致的。

檢視磁碟屬性：

的確是許可權不足。

同時燦哥也回覆了，讓我檢查啟動日誌、看下磁碟許可權是不是不對。感謝燦哥，大神就是大神，果然牛掰。

6.修復：

確定了許可權的問題就好辦了，直接修改許可權就ok 了：

重啟traffic server、檢視相應的cache空間：

現在正常了，同時檢視啟動日誌，也沒有再抱怨許可權不足的告警。檢視相應的日誌統計，請求命中也上去了，回源慢慢的掉下來了：

7.總結：

導致traffic server回源異常的可能原因有以下幾個：

1.http.cache.http 引數異常，為0表示不開啟快取功能，這個時候肯定是全MISS的

2.storage.config中未配置相應的磁碟、目錄，會導致無可用cache空間，從而也會全MISS

3.相應的磁碟、目錄許可權不足，也會導致無可用空間，同樣還是全MISS掉

4.源站的問題，traffic server預設為遵循源站，如果源站不讓快取也會導致MISS過高，但一般不會全MISS

以上都是可能的幾個原因， 其實這裡我不應該首先檢查源站，全MISS的情況下一般都不可能是源站導致的，更應首先排查自己配置的問題。