故障發(fā)生時間：7月份大概
故障描述：
某證券公司使用我司的智能運(yùn)維平臺，在接入了2-3w的網(wǎng)絡(luò)流量指標(biāo)后，異常檢測算法的spark在線處理任務(wù)在早上8:40-9:20，下午15:13-15:30，出現(xiàn)處理時間超過10min以上。但是在9:20-15:00之間，異常檢測算法任務(wù)在相同的指標(biāo)數(shù)據(jù)量的條件下處理時間為2s以下。
故障排查思路:
1.spark版本有關(guān)，CDH反饋目前l(fā)ivy對接的是開源的apache-spark2.2.3，建議替換為CDH的spark2.3.0

2.anomaly在線處理任務(wù)在交易時間9-15點(diǎn)之間并無大的延遲，延遲主要集中在8-9,15:10-15:30;所以懷疑是anomaly算法在交易時間跟非交易時間之間做功能切換的時候?qū)е碌难舆t。

故障排查詳細(xì)：
從7月份故障發(fā)生開始，一直以為是hadoop集群性能瓶頸的問題，所以采取了調(diào)大spark任務(wù)的cpu和內(nèi)存資源，延遲問題未解決；拆分在線處理任務(wù)為多個，每個任務(wù)處理的指標(biāo)量為2000-3000，延遲有緩解，但是依然存在；在早上9點(diǎn)開市前重啟在線處理任務(wù)，發(fā)現(xiàn)重啟任務(wù)后任務(wù)的處理速度加快，但是第二天再次重啟在線處理任務(wù)，任務(wù)的處理速度沒有明顯的加快；檢查了hadoop集群在早上和下午故障期間的資源使用情況，在故障前cpu資源由原來的700c上升到1k以上，項(xiàng)目經(jīng)理認(rèn)為可能是CDH的CPU資源分配機(jī)制導(dǎo)致的新分配的cpu資源使得集群整體的性能降低，但是CDH廠商反饋aiops平臺使用的開源的spark提交的任務(wù)不予排障支持（我在測試環(huán)境替換成CDH的spark，任務(wù)沒有延遲）。
到了8月底，我與算法工程師溝通后，算法提出了異常檢測算法任務(wù)出現(xiàn)處理延遲大于1min以上的時候可能出現(xiàn)問題的原因：
1.算法任務(wù)每隔1小時從mongodb中重新拉取模型信息
2.當(dāng)redis中指標(biāo)的數(shù)據(jù)點(diǎn)達(dá)到300個，算法任務(wù)會從influxdb中重新拉取模型信息，每個指標(biāo)會被拉取4次。
3.算法任務(wù)的cpu 內(nèi)存資源不夠
按照算法提供的排查方向，因?yàn)樘幚沓瑫r不是每小時發(fā)生一次，排除了原因-；檢查inflxudb的日志，我發(fā)現(xiàn)在故障時候，也就是8:40,15:13時候，任務(wù)每分鐘從單個influxdb節(jié)點(diǎn)查詢的次數(shù)為8-9w。

故障解決方案：
【算法與influxdb交互優(yōu)化】 在券商定制版中，anomaly算法在早上8-9，下午15-15:30之間會定時從influxdb中拉取模型信息，anomaly算法包替換之前單個influxdb節(jié)點(diǎn)的select請求量1分9w左右，替換為新的算法包后請求量為高峰期1分鐘2-3w。延遲由原來的10min以上，降低為高峰期7s以內(nèi)

經(jīng)驗(yàn)教訓(xùn)：
1.故障排查先經(jīng)驗(yàn)后技術(shù)原理，從項(xiàng)目經(jīng)驗(yàn)來看，問題的原因首先會被聚焦在hadoop性能上。
2.如果要快速排查故障，還是要從底層原理觸發(fā)，任何以經(jīng)驗(yàn)出發(fā)提出的假設(shè)都會被證明是與問題無關(guān)的。在數(shù)據(jù)量不變，cpu內(nèi)存資源不變得條件下，spark任務(wù)只在非交易時間處理時間超長，交易時段處理時間為0.1-5s，說明很有可能是異常檢測算法的邏輯可能存在問題。