作者：沈斌、右京
業務場景與挑戰
友邦保險是香港聯合交易所上市的人壽保險集團，覆蓋 18 個市場。截至 2021 年 12 月 31 號，總資產 3400 億美元。
友邦保險於 1992 年在上海設立分公司，是改革開放後最早一批獲發個人人身保險業務營業執照的非本土保險機構之一，也是第一家將保險營銷員制度引進國內的保險公司。2020 年 6 月，友邦獲批將友邦保險有限公司上海分公司改建爲友邦人壽保險有限公司。2020 年 7 月，友邦人壽正式成爲中國內地首家外資獨資人壽保險公司。友邦友享 App 在 2021 年榮獲最佳保險科技平臺。
業務特點和架構
爲了踐行友邦健康長久好生活的 slogan ，上雲過程中我們對應用做了大量微服務化改造，以適應快速變化的業務要求和性能要求，並將此前在 AS400 裏的 core 包程序做了微服務化改造，提高了可用時間。此外，我們採用了容器化方案，使應用運行在 K8s 上以獲得彈性擴容能力和自愈能力。
上述改造導致了應用系統複雜度的提升，因此，觀測微服務和 K8s 的運行成爲了一大挑戰。
與此同時，部分外採應用沒有源碼，不適合做微服務化改造，但我們仍然對這部分應用進行了容器化改造，將它們部署進 K8s；還有一部分應用由於各種原因，不適合上雲改造，最終留在了 IDC 機房。因此，服務之間的調用會涉及雲上到雲下、雲下到雲上等複雜情況。
遷雲之後實實在在爲我們帶來了 SLA 的提升，但也導致了訪問鏈路和部署複雜度的提升，如何更好地觀測應用成爲了無法迴避的挑戰。
可觀測性建設痛點和挑戰
建設一個優秀的觀測系統，會面臨以下痛點：
-
觀測複雜度提升：雲原生微服務化雖然帶來了很高的 HA，但也提升了系統的複雜度，加大了可觀測的難度。覈保通過率、交單成功率、用戶的日活/月活散落在各個業務模塊裏，業務需要提供全局視角，以觀察整個保單生命週期裏重要業務節點的運行情況，並獲取研發態的具體情況。
-
技術選型困難：由於歷史原因，友邦內部應用技術選型不一，版本各異，導致可觀測技術和調用鏈追蹤面臨很大的困難。
-
統一觀測困難：友邦是一家金融公司，開發系統和應用運維完全分開，日誌也完全分開存儲和維護，因此無法將以上數據在同一個大盤裏呈現。
-
指標治理：IaaS層、PaaS 層和應用層有很多指標，單數據庫方面就可能有超過 200 多個指標。如果希望指標達到比較容易理解與追蹤的數量，則需要不斷地進行回顧、刪減。
-
快速故障定位：在 IDC 機房時代，沒有直觀的方式讓應用查看自己的資源是否足夠。雖然已經有商業 APM 工具，但其價格高昂，不屬於經濟有效的方式。問題發生時，因爲只有少量應用安裝了 APM ，所以調用鏈不完整，無法實現快速故障定位。
可觀測性建設流程和規劃
可觀測系統的建設主要分爲調研分析、方案設計、改造實施和上線驗證四個階段。
一個優秀的可觀測系統至少需要滿足五個要求：
-
服務資源追蹤：可以將服務運行節點上的 CPU 內存、網絡磁盤、 IO 應用指標進行聚合。問題發生時，能夠輕鬆觀察到異常指標。
-
提供服務 Top 視圖：按照服務的調用量、請求耗時、熱點排名，應用可以很方便獲知哪些是熱點 API、哪些 API 請求量較高等，可以更好地規劃自身的服務資源。
-
調用鏈追蹤：關聯服務上下游，並且最好是無侵入式，可以很方面地從 Trace關聯到日誌，獲取到鏈路問題所在。
-
調用時長分佈：觀察服務的上游與下游，觀察異步耗時，請求慢時可以很方便地判斷是服務資源耗時還是依賴服務資源耗時。
-
數據庫關聯操作：幫助應用觀察到 API 的關聯 SQL、慢 SQL、 Redis 的查詢存在慢 key 查詢 、Mongo 存在慢查詢等操作。
實踐與落地
可觀測性整體設計思路
友邦爲了滿足業務發展需求，在技術層面需要做雲原生技術架構的升級和改造。因此阿里雲與友邦在應用容器化和可觀測性上展開了深度合作。結合業務情況和監控痛點，通過幾十次的討論和推演，我們最終明確了兩個重要建設思路：
首先，根據業務價值自上而下設計可觀測體系。從業務監控、應用監控和資源監控一直向下推進。如果使用自下而上的設計方式，出現問題時團隊會浪費大量時間和精力排查從來不會導致客戶受影響的問題，或客戶先於監控系統發現了問題。因此，需要最先關注和設計與用戶體驗、核心交易相關的業務監控。
其次，需要結合業務設計服務的鏈路追蹤、應用性能監控。比如將某應用的 API 接口翻譯成業務可讀懂的語言，比如依靠保單生效的接口處理時間和處理數量以及接口還調用/依賴了其他哪些服務等來最終明確問題所在，最後結合應用診斷工具 Arthas、 JVM 的調優工具、應用日誌以及資源級別的監控來確認是代碼問題還是底層資源的使用問題。通過從確定事故發生再到定位引起事故的原因，進而確認問題本身來提升故障發現和問題定位能力。
確認了自上而下的可觀測體系後，接下來需要明確可觀測的指標範圍。
全生命週期監控指標設計
可觀測指標不僅是運行態，還需要包含研發態，形成應用全生命週期的監控指標體系。
系統經過雲原生改造後，友邦的 CICD 流水線通過 Jenkins 進行自動化。爲了提升軟件的研發效率，需要抽象出可衡量的指標，比如應用每天的構建次數、構建時長、構建成功率、部署頻率或部署成功率，以及形成這些指標的基礎元數據信息等。
運行態分爲系統層監控、應用層監控和業務層監控三層，監控重要性等級依次升高。資源監控層主要聚焦在 K8s 集羣的 node 節點、磁盤網絡、運行 Pod 監控、核心雲產品等監控指標；應用層主要聚焦於應用的健康度、狀態碼、性能監控、JVM、GC 等性能指標上；業務層主要監控業務的核心指標，如 PV、UV、投保人數、投保金額、簽單數等，它直接影響着監控系統設計的成敗，因爲這是最能夠體現業務價值的部分。
可觀測性架構大圖
上圖爲友邦人壽可觀測性體系的架構，總體設計思路分爲三層：
第一層爲採集層。因爲要符合友邦的技術架構和建設需求，我們選擇用 Java 編寫流水線的 CICD 數據採集器。研發人員在使用 Jenkins 進行應用的 build 或 deploy 時，該採集器能將應用構建的數據和部署的數據全部存到數據庫裏。另外，採集數據時加上了相關聯的 tag ，實現了元數據的共享。比如流水線構建的應用名稱必須與 K8s 的服務名稱一致，構建失敗時即可快速找到出錯的應用。
此外，針對應用的 APM 探針，社區一般使用字節碼增強的無侵入技術。但是由於友邦架構的複雜度，Skywalking 探針無法完全覆蓋友邦的場景。同時，友邦對於深度性能的診斷也有較高要求，希望能夠集成阿里開源的 Arthas、 Memory dump 等能力，APM 探針也會影響應用性能，因此我們最終選擇經過雙 11 大規模檢驗的 ARMS Agent。
各類雲產品中間件、集羣的監控指標採集主要通過 Prometheus；應用日誌主要使用 DaemonSet 的方式進行採集，相比於 Sidecar，其佔用資源更少，工程上也更爲簡單。
第二層爲存儲層。研發態的元數據和 pipeline 的構建數據因其數據量不大，而且是結構化形態，因此存儲在 MySQL 裏。Metrics 監控指標的數據存儲在阿里雲的 Prometheus 產品上，日誌和調用鏈 Tracing 數據存儲在阿里雲的 SLS 產品上。考慮到業務的增長，未來會產生大量的數據，這兩款產品能夠保證監控系統的穩定性、可擴展性和高可用性。同時，兩款產品都是 Serverless 化持續按量付費，不存在磁盤或空間浪費。
第三層爲統一展示層，通過 Grafana 進行匯聚和展示。當時阿里還未推出託管版的 Grafana，因此我們選擇自建，推薦使用 8.0 以上的版本。爲了保證運行的高可用，需要多實例部署，並將配置的數據統一傳到數據庫裏，然後根據此前設計的監控指標，選擇對應的數據源編寫查詢語句，最終結合 Grafana 豐富的圖表進行統一展示。
業務監控的實現是通過將採集到 SLS 裏的業務日誌和應用日誌做統計分析。SLS 的 SQL 查詢功能非常豐富，語句編寫也非常方便。再通過 SLS Grafana 插件集成到 Grafana 裏，最終業務統計數據即可在 Grafana 大盤進行展示。
統一監控平臺
上圖爲建設成果。通過大屏、中屏和小屏的方式形成指揮決策、研發儀表盤&應用性能展示以及告警推送、多維度的監控能力。
其中左側大屏展示核心指標，比如容器集羣的資源利用率、service Pod 健康度以及聯通性等通用指標，爲公司決策提供支持。
右上方中屏主要展示流水線的研發效率指標、應用性能的指標以及全局調用鏈，幫助研發人員提升效率和問題定位的速度。
右下方小屏通過歷史數據的對比，設置了報警閥值。出現異常時，通過釘釘或短信報警的方式推送到電腦、手機終端，幫助運維人員及時發現和處理問題。
關於可觀測性諮詢服務
點擊此處 ，瞭解更多產品詳情！