昨晚九時左右，我們的 EC2 集群的監控系統觸發了一條報警：
Alert: Instance xxx has high steal CPU usage (> 20%) for over 15 minutes
在云服務主機中，CPU steal time 并不少見。如果宿主機上其他的租戶正在貪婪地運行 CPU-intensive 的任務，可能會搶占一部分本來屬于你的虛擬機的時間，這些被搶占的時間就被報告為 steal time。
對于 AWS EC2 來說，情況有一點不同。AWS 使用 CPU Credit 來限制 EC2 實例的 CPU 使用，當實例過于頻繁地使用 CPU，以至于超過了自身的 CPU Credit 配額，這個時候 steal time 就出現了。
問題排查
第一步當然是查清楚故障實例是否正在瘋狂使用 CPU。登錄 CloudWatch，檢查該實例的 CPU 資源使用情況。發現這臺實例的 CPU 使用率并不高，其 CPU Credit 配額十分富余。
這就相當于，你在銀行還有一億元存款，銀行卻告訴你，你破產了！
與此同時，我們的 Prometheus 監控系統給出了一些詭異的數據。
實例的 CPU idle time 直接掉到了 0（應該接近 100）：
實例的 CPU steal time 升到了一個無法理解的巨大的數值（應該是 0）：
通過遠程 SSH 登錄該機器，檢查系統的狀況。逐項檢查了系統的各項資源的使用情況，并沒有發現資源使用率飽合的情況。系統中的服務也都運行正常。在終端多次運行命令 vmstat 1，輸出的結果似乎也沒有什么問題：
不過，等一等，上面的輸出中有兩個詭異的地方：
- 每次運行命令的第一行輸出中，CPU steal time (st) 的值總是接近 100（應該是 0 才對）；
- 第一行之后的輸出中，CPU idle time (id) 的值總是 0（應該接近 100 才對）。
Hmmm，完全沒有道理啊。
鑒于 vmstat 命令的 CPU 統計信息是從文件 /proc/stat 中讀取的，下一步自然是檢查這個文件。
這個文件的內容格式如下：
cpu 1085 316 940 770781 252 0 90 0 0 0
...
其中倒數第三項數字正是自系統啟動以來的 CPU steal time 的累加值。
好，打印十次文件內容，每次間隔 0.1 秒鐘：
注意看倒數第三列：應該是累加值才對啊，為什么數字在遞減呢。難倒時間正在倒流？
既然時間不能倒流，那就只能是 /proc/stat 中的數據破損了。這個文件是由內核維護的。也就是說，是不是內核中統計 CPU steal time 的代碼存在 bug？
搜尋一下 bug 數據庫，在這個代碼路徑中果然有 bug：https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871608。這篇文章 描述得很清楚。
簡單總結一下，如果宿主機遇到了硬件故障或者云服務商對虛擬機執行過 VM migrating 操作，就有可能觸發這個 bug，導致虛擬機中的 CPU 計數器失效。
重啟系統就能解除目前遇到的問題。不過，我想確認一下，這個問題到底是不是由宿主機引起的。
問題確認
向 AWS 提交工單，描述了我們遇到的問題。
幾個小時之后，收到了 AWS 客服的回復，下面是回復內容：
Problem Description:
You find a wrong idle and stolen metrics in monitoring report, you want to know the reason and solution.Diagnostic Analysis:
- Based on your description, I searched the instance details in our tool and the specific time (2018-02-06 13:25 UTC). I found there was a underlying hardware issue at the matched time and the issue has been fixed timely.
- Based on our back-end team's response, when the hardware issue happened, they had seen the abnormal stolen time happening on instances running kernel 4.9.XXX and above versions. I also checked instance xxx and found its kernel is 4.10.X.
- I am not sure whether the abnormal behavior is still exist in your instance. If the instance still meet the issue, please reboot the instance to recover. Since these are kernel counters after all, a reboot would reset everything and they will be back on track.
...
這就印證了我的猜測，確實是宿主機出現了問題。
問題解決
重啟系統，問題解決。
