建站
咨詢
售后
建站咨詢
新聞中心
1 為什么寫這篇文章
轉轉B2C技術部主要負責商詳、商列等BFF層核心頁面業(yè)務，單接口甚至需要開線程池并行調用二十多個依賴服務，因此依賴的服務以及執(zhí)行線程池的穩(wěn)定性也就成為了B2C關注的重點。
那么站在技術視角看調用鏈路，會發(fā)現幾個特點：
- CPU使用率高，線程池大量使用
- RPC調用多，穩(wěn)定性指望依賴的服務方
- 業(yè)務調用鏈路較長，無法精細化控制
本文就針對如何快速定位常見問題，以及后續(xù)日志的進一步治理計劃來進行講解。
2 現狀與問題
目前轉轉各個排查問題的工具是統(tǒng)一開放給公司的所有業(yè)務使用的，因此每次告警，都需借助統(tǒng)一的平臺如服務治理平臺、Grafana、Log日志平臺等工具進行排查，不完全貼合B2C常見問題排查場景，比如上游調用異常、超時等問題。
B2C技術部告警定位問題會遇到如下幾個問題：
- 線上常見告警問題無法快速識別
線上內置告警無法一眼定位出問題，需要根據業(yè)務新增新的Promtheus PromQL展示調用服務超時、異常榜單。
- 公司統(tǒng)一平臺無法快捷跳轉
發(fā)生緊急問題時，只能從收藏夾中選中公司各個公用平臺，然后手動輸入服務名稱、時間范圍、粘貼查詢語句等，效率較低。
- 戶外環(huán)境下無法定位常見問題
辦公設備不在身邊時，一旦發(fā)生告警，無法像在公司一樣方便的打開各個平臺進行問題定位。
3 解決方案
上面提出了幾個問題，那怎么進行監(jiān)控治理呢。比如，怎么快速識別出問題的類型？怎么快捷跳轉對應的平臺？以及在戶外如何進行問題定位呢？針對這些問題提出了如下解決方案。
總架構設計圖如下
如圖可拆分為四部分，執(zhí)行步驟為：規(guī)范梳理及調整 -> 日志收集 -> 日志告警及定位 -> 告警感知
3.1 規(guī)范梳理及調整
- 日志打印規(guī)范化：梳理項目不合理日志打印輸出。
- 日志打印級別優(yōu)化：如輸入密碼為空日志級別由error降為warn級別。
- 該打的日志沒打：領券、預約、秒殺成功等關鍵節(jié)點操作需要輸出日志。
- 不該的打日志別打：移除掉定位問題無關的大日志，如打印整個商詳返回值。
- 類型與閾值規(guī)范：規(guī)范異常拋出類型及調整業(yè)務系統(tǒng)告警閾值。
- 無效錯誤堆棧日志屏蔽：如timeoutException異常的堆棧日志打印無效，可直接省略。
- 告警閾值過于固定：根據各業(yè)務調整閾值，達到99.99%系統(tǒng)穩(wěn)定性告警閾值標準即可。
3.2 基于Apollo自定義日志Agent攔截(日志收集)
日志收集
- Apollo配置中心控制異常+日志打印維度配置。
- 根據配置屏蔽無用Exception，并上報到Promtheus，以Grafana報表展示。
- 通過JavaAgent根據配置的業(yè)務、類、方法級別攔截日志打印，偽代碼如下。
public MethodVisitor visitMethod(int access, String name, String descriptor, String signature, String[] exceptions) {
MethodVisitor methodVisitor = super.visitMethod(access, name, descriptor, signature, exceptions);
if (STR_V.equals(descriptor) && infoLevel.contains(name)) {
// 此處省略。。攔截日志處理邏輯----------
return new LogMethodInsnVisitor(methodVisitor, className, name);
} else {
return methodVisitor;
}
}3.3 自定義B2C業(yè)務告警服務(日志告警及定位)
日志告警及定位
- 通過在Promtheus編寫自定義PromQL，收集服務超時、異常錯誤。
- 公司的Promtheus收集告警日志，并回調B2C業(yè)務告警服務接口。
- 回調接口通過MQ上報告警消息，B2C告警服務消費處理，組裝成業(yè)務需要看的數據后，通過企業(yè)微信機器人進行通知。
- 點擊告警前往大盤，會跳轉到指定服務、時間范圍的監(jiān)控大盤，含：服務超時榜單、服務異常榜單、全局異常列表以及快捷跳轉的工具箱。
其中快捷跳轉工具箱設計原理如下
- 公司的Log日志平臺僅支持小時級別過濾，因此我們改在基于grep過濾，自定義正則表達式過濾出特定時間范圍日志。
- 舉例 16:44~17:14分 過濾正則例子: \(16:\(4[4-9]\|5[0-9]\):\)\|\(17:\(0[0-9]\|1[0-4]\):\)
- 針對常規(guī)連接則通過類似{serverName}、{startTimeStamp}、{endTimeStamp}、{ip}等占位符替換機制獲取快捷跳轉鏈接。
3.4 第一責任人機制(告警感知)
告警感知
- 為對應服務綁定第一負責人及其關聯的leader聯系手機號。
- 配置化形式針對指定類型告警如調用依賴服務異常，如果超過一定時間閾值無人跟進則給服務第一負責人IVR(電話語音呼叫)通知。
- 如果超時依舊無人處理則往對應leader進行IVR通知。
- 如果有人跟進，則下次同類型告警標記為處理人xxx跟進中。
4 應用與效果
4.1 基于自定義告警快速跳轉定位
企業(yè)微信機器人告警
4.2 快速定位超時、異常服務以及全局拋出異常列表
點擊告警后跳轉頁面
4.3 快捷跳轉指定服務、時間所在服務的公司問題定位平臺
5 總結
總的來說，這里是從怎么快速定位異常入手，通過自定義Promtheus的PromQL來聚焦當前業(yè)務需關注的異常，另外實現了H5監(jiān)控大盤頁面，提升了在非工作日戶外無辦公設備問題定位的能力。
當前文章：轉轉B2C一站式服務告警治理的背后
轉載注明：http://m.5511xx.com/article/ccdsdhp.html
