為什么要做業務監控？

通常情況下，大部分企業都會做基礎設施監控，覺得做好基礎設施監控就可以解決大部分問題。至于業務方面監控，等有人來說了再處理就行。殊不知這種想法會有諸多隱患：

1、運維比業務部門經常晚發現業務有問題。

因為業務有問題會最先爆出來，等到基礎設施出問題往往已經過了幾分鐘了。此時業務可能已經焦頭爛額了。

2、由于發現業務問題較晚，這個時候有相互調用關系的業務可能也出現了問題。

導致業務故障定位較困難。如果做了業務監控，且做到妙極監控，那么當大量業務出現問題時，我們就能根據最先告警的來判斷是哪個業務故障引起的。

3、危害公司利益和自身前途。

第三點也是最要命的，由于上述兩個問題導致運維在業務部門乃至整個公司留下不良的影響，長此以往不僅會給公司帶來經濟損失，對自己的前途也是非常不利的。

因此做好業務監控，可以說是每個運維人員必須要完成的一個任務。

業務監控要做哪些？

1、Web站點監控

對公網服務的Web站點，無論是SAAS的還是在我們自己部署的站點都需要進行站點URL監控。公網站點監控建議使用商業服務進行監控，因為這些服務通常可以從多個地域來檢測你當前站點的訪問情況，通常是站點狀態碼和響應速度的監控。

對內網服務的Web站點也需要監控，因為內網是無法從公網訪問的，所以內網建議使用自建Prometheus去監控站點的狀態和響應速度。

2、健康檢查接口

此處做服務健康檢查接口監控，提供一個或多個監控API，監控應用自身狀態、監控應用和數據庫連接狀態，監控應用和中間件連接狀態。

健康檢查接口建議統一使用/health路徑的接口,如果是三個接口那么/app_health代表服務、/db_name_health代表數據庫連接狀態、/middleware_name_health代表中間件連接狀態。

單獨接口返回APP_OK,db_name_OK,middleware_name_OK，多個接口返回OK表示服務和數據庫和中間件正常。

有些JAVA的Sprint框架是自帶健康檢查接口的，這些直接使用即可。

3、日志監控

首先，所有業務日志要接入日志中心。哪些關鍵字需要做告警？需要項目經理和開發負責人討論給出。確保有必要的關鍵字做告警，避免告警的泛濫。

4、鏈路追蹤

鏈路追蹤可以有選擇性的接入，如果業務比較簡單平時運行著也沒有什么問題可以不用接入。一般業務如果上下游調用鏈較多，且業務邏輯比較復雜，同時會有大并發需求，對響應速度要求也比較高的可以接入。

主要給用戶解決找出響應時間較長的API，并查看是否函數中存在問題。有些商業的鏈路追蹤工具還可以看到SQL語句的問題。這些都可以幫助開發人員更好更快的解決業務代碼中的問題。

5、大屏監控

針對業務大屏，首先我們要考慮哪些業務數據要放到大屏中？這里建議放業務負責人或管理層關心的數據。比如：

· 用戶在線人數。

· 用戶訂單實時量數據。

這些數據能讓業務負責人或管理層直觀的看到當前的業務狀況.還可以針對一些預估的異常值進行告警配置。

如何做好業務監控

做好業務監控并不容易，所以這也是很多企業沒有做或做的不夠完善的原因。要做好業務監控得一步步來。首先，你要有業務監控其次我們需要對業務監控進行梳理，確保所有的監控項都是有意義的。最后，我們要有業務監控巡檢和告警處理的流程和機制，確保所有業務監控被發現和及時處理。

另外，業務監控并非僅限于上面所描述的5類，如果一個企業有和業務相關的需要被監控，且并不再上面描述的類型中，都可以通過一些工具或自定義的手段來完成定制化的業務監控需求。

做好業務監控，我們才能讓運維的價值得到充分的體現。