作者｜涯海
稽核&校對：白璵
編輯&排版：雯燕
在陪伴眾多企業共同經歷業務上雲與雲上原生之後，我們可以看到每個企業的運維監控體系搭建過程都十分艱辛。這是由於企業業務發展迅速，對 IT 的要求也愈發嚴苛且複雜。這不僅僅體現在運維團隊架構與工作流程上，也體現在工具選型與平臺搭建上。儘管不同階段不同規模的企業需要面對各種各樣現實問題，但仍然有些最佳實踐有跡可循，今天我們好好聊一下工具選型與平臺搭建思路與實踐關鍵點。
工具選型與平臺搭建必然趨勢
要特別說明的是，監控平臺不是隨便下載一個開源監控工具就可以，它需要根據監控的業務特點進行整合與二次開發，以達到與實際業務情況相吻合。經過大量實踐後，我們發現企業普遍存在的監控體系需求與發展方向：
- 自動識別與採集
雲原生帶來了跨技術棧與高動態的技術架構。因此面向複雜多變的被監控環境，採集器儘可能做到對環境的自動識別，對指標的自主採整合為一切的開始。資料都無法採集，如何監控？
- 資料管理能力不斷強化
雲、容器和微服務的出現使被監控的物件數量增加了幾個數量級。當業務飛速發展，面對幾億甚至十億級別時序資料，我們該如何管理？
- 資料看板體系成為剛需
隨著資料量爆發式增長，傳統的線圖、直方圖、散點圖等資料展示方法很難讓運維人員找到資料背後的異常或隱藏瓶頸。如何針對不同業務或者不同監控物件，找到更合適的資料看板以及展現形式，成為了每個運維人員的必修課。
- 中臺樞紐作用
隨著技術飛速發展，監控系統在整體運維繫統的中臺樞紐作用越來越明顯，運維監控從傳統的流程驅動轉變為資料驅動。如何更便捷的與其它眾多運維子系統對接整合，也是運維團隊在監控體系搭建之初需要考慮的問題。
企業監控體系演進歷程
結合上述特點，我們講企業監控體系的演進歷程歸納為以下階段。
推廣期：伺服器數量 50～100 臺之間
這個階段由於伺服器數量較少、業務規模較小，因此，運維團隊對監控的需求也相對簡單。能夠實現基本的通知問題、快速定位與解決問題即可。此時的平臺搭建主要是讓研發、運維等同學能夠逐漸熟悉產品使用，並通過體驗和反饋，確認是否滿足企業 IT 運維以及業務特徵需求，這其中幾個關鍵特點包括：
（1）部署簡單，有成熟的文件與服務體系，上手易用；
（2）穩定執行，SLA 保障；
（3）告警體系的通知形式不用太豐富，但確保相對及時、可用；
（4）低成本費用或免費。
基於以上需求，很多初創企業可能會選擇 Nagios，Cacti，Zabbix，Ganglia 等開源工具。熱門的開源監控產品文件相對完整，可快速上手且有大量企業實踐可供參考。但這裡存在問題就在於開源產品的效能、使用場景無法滿足隨著業務場景的發展以及業務量增長，進而出現各種各樣的問題。與此同時，高可用成為致命問題，畢竟開源社群不會時刻有志願者幫我們排查故障。
爆發期：伺服器數量 200～1000 臺之間
這個階段由於伺服器數量變多、技術架構發生了變化、元件越發豐富，監控需求也開始變得複雜。但面對眾多服務模組或運維繫統，我們需要分批次有序接入，在保證穩定性的前提下，快速上量、統一技術棧。監控系統主要用於告警通知，發現問題並避免同樣問題再次發生。這其中具備幾個關鍵特點：
（1）監控內容彙總與分類
由於監控物件以及資訊隨著技術架構與業務規模擴大而增多，需要針對軟硬體、業務等不同維度的資料實現全覆蓋式監控。並針對不同監控用途，需要對監控進行分類彙總，比如系統基礎監控資料、網路監控資料和業務監控資料。儘可能多的監控覆蓋，儘快發現重要問題，確保業務穩定執行。
（2）多種告警方式，及時無漏報
根據監控物件的重要程度、緊急程度進行分類，並通過郵件、微信、簡訊、電話等不同級別不同方式進行告警通知，每個監控對應到不同責任人，確保每個告警都有人及時跟進處理。
（3）告警策略優化與資訊收斂
由於需要監控的服務越來越多，告警資訊數量激增，每天都可能收到上千封報警郵件。過多的告警資訊就失去了精準告知的意義。如何對告警策略進行配置和優化，儘量減少不必要的告警郵件，成為策略設定的核心。
成熟期：伺服器數量 1000 臺以上
由於業務持續增長，對伺服器的需求越來越大，當伺服器超過 1000 臺以後，意味著核心系統需要全部接入，並構建新的穩定性保障體系，包括監控大盤、告警通知、應急值班等。才能確保整個業務與技術大盤的穩定。這其中，需要關注：
（1）監控延時與告警滯後
當業務規模越老越大，由於元件或服務的耦合關係，很可能由於區域性的細小故障導致整個業務系統的癱瘓。因此，及時發現問題成為了一切的大前提。但假如還在選擇時開源產品，這時可能就有不小的麻煩。以 Zabbix 舉例，當規模達到一定量後，有時候會出現監控資料不能及時顯示，告警延時等問題。我們確實可以通過各種優化方式進行調整。但業務出現問題而造成的損失並不能挽回。
（2）監控系統自身的 SLA
當收集運維資料飛速增長，監控系統自身的高可用也成為了重要關注點。畢竟，失去了監控系統意味著對整個技術與業務的執行狀態失去了控制。
更具價效比的解決方案：應用實時監控服務 ARMS
面對上述不同階段的痛點，ARMS 成為了最佳的解決方案。與此同時，阿里雲推出 ARMS 3.0 普惠計劃旨在通過更靈活的計費方案，幫助不同型別的使用者在不同使用階段，以更合理的成本獲取更高價效比的可觀測體驗。在 2021 年 10 月即將推出的應用監控基礎版（按量計費）模式支援 0 元用：指標免費儲存 3 天，呼叫鏈基礎取樣免費儲存 1 天，功能與原有基礎版保持一致，可按量付費延長儲存週期或提高鏈路取樣。詳情可參考應用監控基礎版功能列表或產品計費說明。
根據上述階段的使用者訴求，ARMS 3.0 應用監控推出了配套的靈活計費策略：
（1）試用期：ARMS 提供新使用者 15 天免費使用，全面評估 ARMS 產品與業務契合程度。
（2）推廣期：ARMS 提供基礎版免費額度，應用監控指標免費儲存 3 天，呼叫鏈基礎取樣免費儲存 1 天。零門檻無限期使用，不用擔心推廣期間的費用問題。
（3）爆發期：ARMS 基礎版支援按流量計費，可以按需調整指定應用的呼叫鏈取樣率，或延長儲存週期。
（4）成熟期：根據業務流量型別自由選擇按流量計費或按節點計費。
按流量計費，用多少算多少
隨著微服務和 Kubernetes 的普及，微服務拆分越來越細，單個 Pod 流量越來越小。按節點計費模式就顯得不夠靈活，在業務流量不變的情況下，成本隨節點規模快速增長顯然不夠合理。
為了解決小流量和彈性流量使用者的可觀測成本問題，ARMS 3.0 推出了應用監控基礎版（按量計費）模式：呼叫鏈基礎取樣免費儲存 1 天，付費取樣鏈路按照 0.2 元/(百萬條Trace*天) 進行計費，單條 Trace 最多可包含 10 條 Span 呼叫，超出部分按比例折算。指標資料 3 天內免費，可按需付費延長儲存週期，如下表所示。
以 ARMS 某基礎版使用者為例，該使用者建立了約 300 個 Pod，原始呼叫總量約為 54 億次/天，呼叫鏈取樣率為 10%，實際儲存量約 5400 萬 Trace/天。按照原基礎版鏈路儲存1天，指標儲存 3 天計算，升級為按流量計費後費用可節省 90% 以上。
超大流量，按節點計費更划算
一些 ToC 型別的業務流量非常大，並且對問題可追溯的時間跨度要求高，需要長週期儲存。此時，可以選擇 ARMS 專家版按節點計費模式，鏈路儲存 30 天，指標儲存 90天，一價全包，費用封頂，更適合大流量核心應用接入。專家版還可享受 容器服務 ACK 或 EDAS 使用者半價優惠，購買預付費流量包最低可至 1.308 元/(探針*天)，詳見 ARMS 產品價格說明。
常見問題
Q：新老使用者如何升級至應用監控新基礎版（按量計費）模式？
A：2021 年 10 月以後，新使用者試用期結束後，選擇開通基礎版，預設進入按量計費模式；存量基礎版使用者可以在應用監控 -> 應用列表頁面上方點選升級至新計費模式。新基礎版鏈路免費取樣依賴 Agent 升級至 2.7.1.3 版本，可以在應用監控 -> Agent 列表 -> java版本說明頁面選擇對應區域進行下載，https://arms.console.aliyun.com/#/tracing/agentList/cn-hangzhou 。
Q：新基礎版（按量計費）預設是免費的嗎？免費多久？
A：開通新基礎版（按量計費）後，預設是完全免費的，如果不調整儲存週期或呼叫鏈取樣率可以無限期免費使用，非常適合小流量或測試應用接入。
Q：基礎版包含哪些功能？與開源和專家版有什麼區別？
A：基礎版支援呼叫鏈、服務監控、JVM/主機監控、告警等基礎 APM 功能，與開源能力基本持平。專家版在記憶體/執行緒/異常等診斷方面會有大幅增強，按節點計費，呼叫鏈儲存 30 天，指標儲存 90 天，更適合大流量或核心生產應用。
Q：除應用監控外，ARMS 前端監控、雲撥測和 Prometheus 監控是否支援按量計費？
A：ARMS 前端監控、雲撥測和 Prometheus 監控均支援按量計費，並且可以通過預付費獲得優惠折扣，詳情請參考 ARMS 產品價格說明。
相關連結：
1）應用監控基礎版功能列表：
https://help.aliyun.com/document_detail/65682.html
2）產品計費說明：
https://www.aliyun.com/ntms/price/detail/arms_detail
3） ARMS 產品價格說明：
https://www.aliyun.com/ntms/price/detail/arms_detail
點選下方連結，瞭解更多雙十一優惠！
https://www.aliyun.com/activity/1111/cloudnative?spm=5176.20960838.0.0.7603305eAKBvI9