之前我們分享了可觀測體系整體規劃建設戰略與落地實踐，而進一步深入可觀測體系中，在數字化轉型和國產化大背景下，監控的對象種類繁多，新技術新對象層出不窮，企業內部監控體系的建設、監控工具支撐都面臨極大的挑戰：傳統的監控系統無法快速滿足國產化的要求，也無法快速擴展支撐快速變化的監控需求，各種監控指標混雜一起，難以管理和分析。

為了解決這些問題，支撐一體化的可觀測系統建設，實現統一采集、統一管理、統一告警、統一展示，降低運維成本，進行監控指標管理體系的建設和落地將變得不可或缺。本次我們邀請到了兩位嘉為藍鯨產品經理蘇文和孟世一，以自身在監控領域多年的耕耘經驗，分別為大家帶來《可觀測指標管理體系建設落地》與《插件功能設計及生態打造》兩個主題分享，與大家一同探討：

• 如何梳理、建設并落地適合企業自己的可觀測指標管理體系？
• 什么樣的插件功能和生態能夠成為指標管理體系的落地有力支撐？

主題一：可觀測指標管理體系建設落地

如今，傳統監控日益無法滿足企業快速發展的需求，越來越多企業開始進行可觀測體系的探索，在建設初期可能也會存在很多的問題：可觀測體系建設中為什么需要建設指標體系？指標體系究竟“長什么樣”？應該如何設計管理？接下來我們就一一解答這些問題。

1）可觀測指標體系設計

① 為什么需要建設指標體系？

在了解指標體系前，我們先來看看為什么需要進行指標體系的建設，結合過往的建設經驗，我們總結了六個方面的原因：

• 衡量業務健康情況：指標體系可以反映業務客觀事實，看清業務健康現狀，有效衡量業務質量，優化應用運行。
• 完善指標全生命周期管理體系：規范指標定義、指標建模、指標接入、指標消費的過程，指導圍繞指標全生命周期的管理體系的建設。
• 衡量企業監控落地效果：建立指標的規范和管理方法，更好衡量企業監控的能力完善程度和監測有效性。
• 支撐故障問題的快速定位：圍繞指標的全生命周期管理內容，建設指標數據體系，在故障出現時能夠快速定位問題所在。
• 明確指標管理規范：清晰定義指標管理流程、分級分層規范，命名規范等，建立指標的全生命周期管理。
• 為運維團隊提供數據支持：企業內統一指標體系建設，提供指標查詢、檢測、健康分析等消費能力，實現指標數據的價值挖掘。

② 指標體系設計邏輯

了解為什么要設計指標體系后，接下來我們再來看看可觀測指標體系應該如何設計。

可觀測指標體系的設計對整個可觀測性的落地起著至關重要的作用。其設計的核心理念是：以監控對象為骨架、以監控指標為經脈。

那么運維主要監控的對象都有哪些呢？我們以下圖的一種拆分方式為例，從應用視角來看，從下往上可以分為數據中心、硬件設備、系統、組件、應用服務、用戶體驗六個層面，每個層面相應的對象也有不同的指標設計。

• 數據中心層，一般會有動力、環境、安防等方面的指標，以確保數據中心能夠正常運轉，為上層奠定良好的基礎。
• 硬件設備層，通常關注服務器、網絡、存儲、安全四大類監控對象，以確保硬件層面的設備不出故障，保障應用的穩定運行。
• 操作系統層，主要承擔將硬件“轉化”為軟件所需資源的職責，在這一層中運維主要監控的對象包含虛擬化資源、操作系統、容器的相關指標。
• 組件服務層，主要包含應用運行所需要的一些組件如數據庫、中間件等，通常這些組件會以進程的方式存在，需要對這些組件進行監控管理。
• 應用服務層，也就是應用代碼級別的內容，在這一層主要關注的是應用之間的調用鏈關系，以及面向用戶的客戶端指標，除此之外一些撥測主動檢測指標，主要作用于衡量和反映應用的可用性。

上述五層更多關注在應用系統的本身以及其相關運行環境的指標設計，而在此之上到業務運營層面時，可能會超出運維的范疇，但依舊是屬于可觀測體系中的一部分，這部分主要是聚焦于業務，包括應用系統對外提供的服務時的相關數據指標，如交易系統的交易、訂單以及用戶數據等一些數據指標。用來衡量前端用戶的指標，建立業務數據層面的觀測能力。

以上的六層式的指標設計僅僅只是一個參考示例，不同的企業由于所提供的業務不同，對應用的觀測有不同的側重點，企業需要根據自身的實際情況，進行合理的調整或更加細致的劃分。

當然，可觀測指標體系的建立不僅僅只是確定這些指標的內容，同時還需要對指標的定義、建模、接入、消費全生命周期過程持續做好管理，除此之外，指標設計也并不是“拍腦袋”就能決定的，需要建立相應的指標管理規范，包括設計原則，指標分級、分層、命名等，以支撐整個指標生命周期的正常運作。

接下來，將對指標的設計原則、分級規范以及指標生命周期管理過程進行重點介紹。

2）指標設計規范和生命周期

① 指標設計原則

指標的設計過程中需要遵循一定的設計原則，我們選取了在行業中比較通用的六個原則進行介紹。

• 指標設計要遵循可度量、可采集、可理解、可消費的原則。我們需要選取更加有意義、受到認可、可衡量的指標作為關鍵性的指標，例如時間戳Timestamp指標，通常情況下并不具備一定的實際意義，并不能作為一個很好的指標。這也是指標設計的最核心的原則，在遵循這個原則的基礎上，我們增加以下5個原則進行補充。
• 指標設計要有明確監控目標和消費場景。在進行指標選取時，需要明確監控目標和消費場景，避免指標冗余、混亂、隔離、不一致以及謬誤等。
• 指標設計具有可以賦予數學運算的屬性。比如可排序（全序、偏序），可運算（加減乘除與或非），或者可進行數學統計運算。
• 指標最好是具有時序性的。部分指標需要能夠隨著時間進行積累，衡量整個時間過程，而不是單一的時間點。比如某個服務是否啟動，這個布爾值指標，就沒有太大的意義；換一個角度，將服務的運行狀態作為一個指標，那么這個指標就可以周期性采集探測，具備時序特征，可以反應不同時間的服務狀態。
• 指標定義時首選是代表服務可用性的關鍵指標。可以參考Google SRE定義的黃金指標。比如請求量，耗時，緩存命中率，消息隊列 Ingress & Egress 的數量，消費速率，積壓請求數量等，這些都可以成為自定義指標的首選。
• 對于部分跟業務相關的指標，也可以作為該業務鏈路的指標。例如在文件下載場景中，請求的耗時跟請求的文件大小是有正相關性的，將每次下載文件的大小作為指標，在該場景中是較好的一個選擇。

② 指標分級規范

指標分級規范也是指標管理規范中的關鍵環節，通常會分為三級指標：

• 核心指標：一般指監控對象的死生指標，1-2個即可。主要用來反映服務的可用性。
• 關鍵指標：一般可用于告警的指標，可參考監控度量的四大黃金指標(飽和度、錯誤、流量、延遲)來定義。與死生指標不同，主要是從側面反映服務的狀態，以便于提前發現問題，提前預警。
• 常規指標：根據企業的業務場景可能需要關注的性能指標，一般用于告警問題分析的數據支撐，即分析指標。

③ 指標生命周期

一般指標生命周期主要經歷四個階段：指標定義→指標建模→指標接入→指標消費。

指標定義：主要明確指標所屬的層級、指標名稱描述，維度如何設置，以及指標屬于何種級別。

指標建模：指標是依賴于對象的，如果沒有對象，那么指標也就沒有實際意義，建模的過程可以聯動CMDB模型對象，然后通過插件關聯等方式導入指標，再通過原生指標間的運算獲得較為復雜的計算指標，最后完成權重和等級的配置，便于后續分析。

指標接入：完成指標的定義和建模后，要把指標真正應用起來還需要通過指標接入采集到明細的數據，一般有第三方上報、插件采集、協議采集等方式，通過采集任務統一進行管理。

指標消費：有了采集的數據之后，就要發揮數據的價值，支撐消費場景。可觀測的核心消費場景主要是進行指標檢測，對異常狀態進行監控告警；除此之外還能進行健康分析，數據運營等工作，同時也能通過指標接口，為其他第三方系統提供消費。

3）指標體系建設工具設計

了解了可觀測指標體系的內容建設和管理規范之后，在實際落地建設時，企業應該如何建設相應的工具體系來承載指標體系呢？

① 指標體系建設的核心承載工具——監控

在監控中，也可以按照指標的生命周期來進行相應的能力建設。

指標定義&建模階段：支持對指標的定義、層級、屬性的管理。以及對象和指標模型的統一管理。

指標接入階段：支持采集插件管理，采集、接入任務管理。

運營消費階段：支持指標數據消費和運營過程中的的檢測告警以及可視化管理等。

② 指標體系建設的配套工具

正如上文所提到的，指標的管理不僅僅是指標內容的建立，還包括指標的管理規范和治理。不僅僅需要監控工具，還需要相應的建設配套的工具，如CMDB的建設主要提供數據治理，對象管理等能力，ITSM主要保障指標管理過程中的流程規范，保障順利完成整個落地過程。

主題二：插件功能設計及生態打造

以上我們已經對可觀測體系指標建設的一些相關內容做了分享，那么在實踐落地方面應該如何著手呢？接下來我們將以嘉為鯨眼可觀測產品為例，從數據采集模式設計理念，插件功能模式設計，以及插件生態運營積累三方面介紹實踐經驗。

1）Agent+Agentless結合

早期監控的采集模式通常是以Agent-less方式進行，主要通過一些采集協議訪問目標設備，再使用一系列的查詢命令將數據進行上報，進一步進行后續的分析操作。

早期IT的安全要求并不高，但隨著企業IT要求逐漸嚴格，操作系統安全性的逐漸提高，這種模式在當前場景下已經不再適用，同時Agent-less模式本身過于龐大的鏈路開銷和采集的深度無法滿足等問題也被運維人員所詬病。

除此之外，由于Agentless采集通常都是基于已有的采集協議去進行，不具備更多拓展的空間，甚至有一些操作系統和應用程序已經不再提供訪問接口，在這種情況下我們需要采集更多的指標就只能通過Agent-based，也就是基于Agent采集的模式來進行監控工作。

但實際上，在一些IT頭部企業開始嘗試使用Agent模式進行采集的探索過程中，發現Agent-less仍然具備這一些不可替代性，其中包括在一些網絡、存儲、硬件服務器等設備不支持Agent模式，以及一些高級網絡平臺無法安裝Agent，虛擬化平臺、公有云平臺無法直接訪問基礎設施等問題，依然只能依賴于Agent-less監控方法。

在這種環境下，鯨眼監控中心采取二者相結合的模式，通過在節點管理建立OneAgent統一管理模式，Agent支持按需擴展功能以及按需下發指定的功能模塊，Agent既可以支撐Agent-based的數據收集模式，又可以作為Agent-less的集中監控設備，圍繞藍鯨Agent使得監控中心具備對各類不同設備的采集能力，并解決了多云區域下跨網遠程收集的問題。

2）插件功能模式設計

在了解完插件能力的設計之后，如何將這些插件利用起來，打造監控插件在各類場景下的各種能力呢？接下來我們就一一深入介紹。

① 主機監控插件：主機監控幾乎是所有企業都繞不開的監控場景，對于這類典型的場景，我們通過內置監控插件來幫助采集，在部署藍鯨Agent時會自動部署BaseReport插件，自動采集CPU、內存、IO等數據并上報至監控中心，實現內置開箱即用的監控場景。

主機監控是較為典型的場景，但除此之外企業常常也會有打造屬于自己的監控插件的訴求，針對這些非典型的場景，監控中心也能夠提供強大的在線插件制作能力，根據接入模式的不同區分，提供各類場景下的插件功能的結合。

提供Exporter/DataDog插件，無縫兼容主流Prometheus/DataDog，同時也能進行插件進行自定義調整以滿足自身需求。

② 腳本插件：一些企業中運維人員會存在通過指標的查詢命令進行手動查詢的場景，插件制作中心也會能夠提供腳本設計能力，運維人員可以將腳本寫入后自動化執行采集工作。

③ 自定義插件：除了上述采集場景外，還有一些設備需要不同的協議（SNMP、JMX等）進行采集，我們也能夠支持進行自定義插件的制作。

同時，基于低代碼和低門檻思路的插件功能設計，運維人員也能夠自主構建一些運維插件以輔助更好的進行運維工作，對于運維人員自身從傳統運維向運維插件開發，甚至向運維工具開發進階也有著良好的推動作用。

3）插件生態積累&運營

嘉為鯨眼監控中心目前已集成了80余款組件服務插件及120余款網絡、硬件設備插件。覆蓋適配了硬件層、系統層、軟件層、應用層乃至云計算層的絕大部分主流設備、系統及組件服務。同時，當前信創建設如火如荼，嘉為藍鯨也實現了信創各類設備廠商的兼容適配并持續不斷支持信創發展。

除此之外，我們也致力于幫助企業建立標準化的插件積累，打造成熟的插件生態能力。完整的標準化插件包含指引手冊與指標清單兩部分。當企業具備了成熟的標準化插件以后，能夠自主根據業務的發展進行相應的插件生態打造，從而實現可持續優化的插件體系。

指引手冊包含各類說明、使用指引等，讓小白運維也能夠快速上手。

指標清單是從分類、采集、閾值等多個角度針對各類型插件指標梳理的完整清單，這部分并不是簡單指標列表，需要具備科學的指標分類、合理的維度設置、完整的指標信息以及核心指標閾值推薦。