1.IT 運維監控體系概述#
IT 運維包括了很多方面，比如安裝部署、配置管理、運維監控等。有句話說，“無監控，不運維”，可見運維監控在 IT 運維中的重要。本文就著重聊聊運維監控體系。IT 運維監控體系可以從三個對象維度去劃分：性能（Metrics）、鏈路（Traces）、日誌（Logs），參考圖 1、圖 2、圖 3、圖 4 所示：
圖 1：企業 IT 運維的三個維度
來源：愛數學院
圖 2：三個維度的表現形式
來源：愛數學院
圖 3：三個維度解決的不同問題
來源：愛數學院
圖 4：如何利用三個維度解決問題
（來源：愛數學院）
- Metrics 是最早期的運維關注點，其主要關注系統是否發生了問題，屬於紅海市場。
- Traces 是處於高速發展階段，其主要關注系統發生問題的鏈路及源頭，主要使用 APM（Application Performance Management，簡稱 APM）工具，通過對關鍵業務系統進行監測、告警與優化，不斷改善業務可靠性與穩定性，為客戶提供良好的服務，提升核心競爭力。
- Logs 相對而言，能夠獲得更多的安全、運維甚至運營信息，其主要關注的是系統發生問題的原因，所以門檻比較高，是目前相對的藍海市場。
2. Metrics#
說起 Metrics，不得不提到Zabbix，這是一款開源的運維工具，支持分佈式監控，為廣大互聯網企業所使用。Zabbix 的監控原理就是和監控對象建立通訊，進行數據採集。其通訊的方式包括 agent、SSH/telnet、SNMP（常用於網絡設備，比如交換機）、IPMI（常用於電源、風扇等）、JMX（常用於 JVM 虛擬機）。Zabbix 的缺點在於底層是採用了數據庫存儲，所以不是很適合大量頻繁地存儲或讀取日誌（側重點還是在 Metrics）。另外，Zabbix 對容器、微服務的監控能力較弱。
除了 Zabbix，目前常見的還有Nagios、Cacti、Prometheus等。隨著這幾年雲原生的興起，擅長雲原生監控的 Prometheus 受到了大家的歡迎。而阿里雲也適時地推出了ARMS Prometheus，全面對接開源 Prometheus 生態，支持類型豐富的組件監控，提供多種開箱即用的預置監控大盤，且提供全面托管的 Prometheus 服務。當然，Prometheus 仍然是 Metrics 層面的，告警功能並不算完美，更談不上分析功能了。
3. Traces#
隨著企業業務的發展，規模擴大，業務越來越多，所採用的組件也越來越多開始走向分佈式化，如微服務、消息收發、分佈式數據庫、分佈式對象存儲、分佈式緩存、跨域調用等，這些組件共同構成了繁雜的分佈式網絡，一個業務請求可能會涉及到幾個、幾十個服務的協同處理，這種情況下，我們需要使用能動態展示服務的鏈路，能分析服務鏈路的瓶頸並對其進行調優，能快速定位故障鏈路的運維工具。由此，APM 工具就應運而生了。APM 工具既可以監控前端的譬如移動端 APP、瀏覽器，也可以監控應用後端。
APM 的數據獲取一般通過探針埋點，又稱 Agent 方式來獲取。這種方式能夠提供非常完整與細粒度的監控數據採集，提供代碼級的問題定位。但此方式對應用有侵入性，如果埋點代碼異常，會對應用本身的性能和穩定性產生影響。該方式可以再細分為兩類：代碼侵入式和字節碼增強式。前者代表的產品有Zipkin、cat。後者代表的產品有 PinPoint，skywalking。產品的比較可以參考如下：
- 《調用鏈選型之 Zipkin，Pinpoint，SkyWalking，CAT》
- 《全鏈路追蹤技術選型：pinpoint vs skywalking》
- 《監控系統比較 Skywalking Pinpoint Cat zipkin》
近年來，國內以 SaaS 模式提供 Traces 監控的廠商也嶄露頭角，雖然也是通過探針埋點的方式獲取數據，但其商業模式已經發生了變化。目前國內比較知名的廠商有聽雲、雲智慧、OneAPM等。
另外，不通過探針埋點獲取數據的 APM 工具也逐漸興起，國內代表的產品有RStone。其獲取數據的方式主要採用旁路部署，不對網絡拓撲、系統等進行任何改變，也不用安裝任何軟件，只需要在關鍵節點上旁路部署設備，參考圖 5 所示：
圖 5：RStone 監控方式
(來源：RStone 官網）
4. Logs#
傳統運維監控主要還是 Metrics，近年來開始重視 Traces，但是上述兩種仍然存在以下一些問題：
- 監控斷層 ——IT 基礎設施的監控和應用層的監控不通，或由不同的團隊來監控
- 缺乏統一 —— 根據監控對象不同，監控工具各不相同
- 告警泛濫 —— 缺乏告警收斂、故障治愈等智能運維手段
通過 Logs，可以有效地解決上述問題。目前市面常見的工具有 Splunk、ELK、日誌易、AnyRobot。
Splunk，日誌監控產品的佼佼者，主要就是針對公司的日誌文件進行分析，通過它，可以快速的通過一個 Centralized Application 進行各種各樣的統計和查詢，同時也可以產生各種報告，方便大家對整個數據進行性能評估。不僅是數據量，而且還有查詢速度，查詢方便程度，統計報告等各種各樣你可能想到的功能。不僅是公司的日誌文件分析，它目前作為一家面向企業端客戶的 SaaS 企業，為客戶在搜索、監視、分析和解釋各種機器生成的大量數據提供軟件解決方案。不止 IT 公司，DevOps 解決方案，還有電信、能源、金融、政府等各個領域。Splunk 的優秀吸引了鼎鼎大名的 ARK 的木頭姐曾在一天豪掷 5500 萬美元，在 ARK 的四大 ETF 中同時加倉 Splunk。
但 Splunk 並不是強大到不可戰勝的。Splunk 產品使用涉及到多個組件及工具，每一個組件會涉及到收費，成本較高。成熟的商業開源正逐步蠶食 Splunk 的市場，其中最著名的就是 ELK。
ELK，ElasticSearch，Logstash，Kibana 的縮寫，分別提供搜索，數據接入和可視化功能，構成了 Elastic 的應用棧。雖然這三個都是單獨的開源項目，但它們實際上在 Elastic 的同一屋簷下為所有組件提供了極具凝聚力的路線圖，其檢索結果的評分機制更是優於 Splunk。由於是開源的，所以得到了許多開發力量的支持，相較於 Splunk，ELK 給開發者更好的參與感。
在國內市場上，同樣存在著兩款優秀的日誌監控產品 —— 日誌易和 AnyRobot，兩者都是基於日誌的大數據運維分析產品，其區別羅列一部分如下：
- 日誌易可謂是 Splunk 的忠實模仿者，一直在模仿，但從未超越。AnyRobot 基於 ELK 開發，充分發揮了 ELK 的優勢。
- 日誌易的產品形態包括軟件版和 SaaS 版，AnyRobot 不僅有軟件版和 SaaS 版，還有一體機版。
- 日誌易的計費模式是按照數據流量收費，AnyRot 的收費按照用戶實際需要分析的數據量所消耗的計算單元進行收費。
- 日誌易在數據流管理方面有單獨的產品 “數據工廠”，AnyRobot 這塊有空白。
- 日誌易在金融行業的案例較多，AnyRobot 在政府、教育、醫療行業的案例較多。
- 日誌易在涉密行業銷售有阻礙，AnyRobot 具有在涉密行業銷售的通行證。
- 日誌易對抗 Splunk 的方式是替換策略，研發和 Splunk 體驗感類似的產品來代替 Splunk，AnyRobot 的方式是納管策略，不替換但可以納管 Splunk。
5. 結尾#
- Metrics 監控仍然是目前大部分運維正在做的主要工作，Zabbix 等工具還將繼續沿用。
- 基於 Traces 乃至基於 Logs 的監控運維會越來越被重視和接受，傳統運維監控正在向智能運維，即 AIOps 轉變。
- 運維工具從軟件版向 SaaS 版轉變。
- 國內市場上，國產化在興起，優秀的廠商和產品也在不斷地湧現。