隨著云原生概念的深入普及和應用落地，企業應用架構由單體架構演進為微服務架構，應用將狀態剝離到中間件層，通過無狀態化實現更靈活的容器化部署和水平伸縮。然而，引入微服務框架、Kubernetes、分布式中間件等組件，使得系統變得復雜且“黑盒化”；被監控對象多樣化程度倍增，監控對象數量也呈指數級增長；同時業務在線化使得企業更加關注系統可觀測性，故障預警和恢復實時性訴求逐步提升，監控的實時性要求已從分鐘級提高至秒級。
對于一個企業級的監控平臺，要服務于不同的商業客戶，客戶的系統規模有不同的級別。一個典型的運營商BOSS系統項目，項目的規模一般會有500+左右的虛機，2500+左右的容器實例，每個業務產品大概會有3-5個核心業務指標。對于主機和容器，一般會要求30秒左右的采集頻度；對于核心業務指標，需要實現秒級監控。
從上面的數據計算分析可以看出，要滿足常規業務生產運維支撐時的持續可觀測訴求，首先需要具備百萬級指標處理能力。具體包括如下三個方面：
- 具備海量指標實時采集的能力
- 具備指標秒級計算的能力
實時計算框架首先應具備海量指標的秒級處理能力，隨著業務規模的擴大，系統需要能夠快速而準確地處理大量的實時數據。為了應對用戶告警場景中的多樣化需求，包括同比昨天、同比上周或同比上個月等計算規則，實時計算框架必須具備批式處理的能力，以有效規避內存占用可能出現的問題。
復雜的實時計算規則通常伴隨著較高的使用成本，因此實時計算框架在規則配置方面需要提供更低的接入門檻，以降低用戶的配置和維護成本，使其更易于自定義處理規則。
構建存算分離的架構亦是關鍵，尤其在極端情況下，即使指標存儲系統出現異常，也不能對指標的實時計算造成影響。這種存算分離的設計能夠保障實時計算的穩定性和可靠性。
- 具備毫秒級延遲的指標讀寫能力
實現指標存儲的高實時性是首要任務，確保能夠達到毫秒級的延遲，以滿足對實時性要求極高的業務場景。存儲效能的高效性同樣至關重要，尤其在處理海量指標數據的情境下，指標存儲服務需要具備出色的性能，以確?？焖俣煽康卮鎯Υ罅繑祿?。
為了應對用戶對指標數據的實時查詢需求，指標存儲服務必須能夠提供秒級響應，確保用戶能夠及時獲取最新的數據并進行分析。在滿足企業級容災管理需求方面，指標存儲架構應具備多副本的能力，以確保數據備份和容災，從而提高整體系統的穩定性和可用性。
目前業界完備的單一開源監控平臺端到端解決方案，比較流行的有Zabbix和Prometheus監控解決方案，它們提供了一體化的監控告警能力，具備采集、計算、存儲和告警能力。
對于Zabbix，是一個比較傳統的監控管理平臺，在設備監控方面具備比較成熟和完備的對接流程，但在面向大規模的指標流量需求上有一些不足：對于指標存儲，zabbix標準版本指標存儲默認還存儲在關系型數據庫mysql中。同時在采集領域，當前的云原生組件優先默認支持prometheus，zabbix的開源插件存在一定的滯后以及定制化成本。
原生的 Prometheus 并不支持高可用，也不能做橫向擴縮容，當集群規模較大時，單一 Prometheus 會出現性能瓶頸。同時Prometheus 告警規則是基于文件的管理模式，用戶使用門檻較高。當前雖然Thanos已經具備了prometheus集群管理的方案，但依然無法解決prometheus單一性能和運維難度高等問題。
綜上所述，不管是面對海量指標處理，還是在運維管理復雜度，二者都無法滿足企業級的商用監控訴求。
當前業界監控平臺建設的主流思路是基于開源產品的能力，結合自身面對的場景進行改進和優化，以構建更貼近自身業務場景的技術解決方案。這類平臺方案通常使用時序數據庫（如InfluxDB、OpenTSDB、VictoriaMetrics、Prometheus）與流式計算框架（如Flink、Spark、Kapacitor、Prometheus）相結合，以滿足對超大規模項目的監控處理需求。
浩鯨科技監控平臺解決方案也是這種建設思路，監控平臺功能架構如下：
百萬級指標采集、處理平臺的改進和優化，重點要在指標采集、指標存儲和指標計算三個方面。
遵從OpenMetrics標準協議自建分布式采集服務
在OpenMetrics協議下，業界普遍采用 Prometheus 作為采集服務的事實標準，在業界絕大多數的可觀測平臺中，Prometheus 是充當了生態適配和采集組件服務端的角色。但作為采集組件服務端，原生 Prometheus 存在以下劣勢：
Prometheus 作為采集服務，原生的 prometheus-remote 模塊，具備數據遠端寫的能力，但資源消耗較大。
目標的管理載體是本地文件或者依賴于 consul 服務發現組件，要么不易與第三方系統集成，要么要引入新的組件，增大復雜度。
缺乏足夠的中間計算的能力，OpenMetrics 協議下，指標數據類型包括counter，guage等多種。如cpu使用率指標為 count 類型的時間累計值，原始值對用戶不可讀；同時一個指標組中只有一個指標，還是以 cpu 指標舉例，對于 cpu 指標，就有 system、idle、wait、user 等指標；用戶想要了解主機 cpu 性能狀態，要查詢每個指標組。
為解決這些問題，分布式采集服務（nms-prometheus-scraper）應運而生：
首要構建原則是支持 OpenMetrics 協議，可以復用業界大量的*_exporter組件，降低開發對接的成本。
nms-prometheus-scraper 是專門為采集服務而開發的，解決了prometheus 在只作為采集服務時內存占用超大的問題；nms-prometheus-scraper 采集服務，采集指標后不落盤，直接寫后端存儲，效率極大提升。
為了應對大規模的采集需求，nms-prometheus-scraper+mysql 構建了分布式集群管理能力；采集目標和分組在mysql中管理，nms-prometheus-scraper 基于目標分組來做采集負載均衡，這種不依賴于復雜度第三方組件的設計模式，極大地降低的運維復雜度。
為了提高指標的可讀性，我們通過內置通用的指標計算服務，方便用戶對指標做進一步的加工，如常見的縱表轉橫表，counter 類型的數據轉換為比率，一些數據差值計算等。
通過上述優化改進，使用 nms-prometheus-scraper 可達到更高的采集處理性能，降低損耗的設計初衷。
浩鯨科技指標采集服務平臺功能架構：
nms-prometheus-scraper 分布式采集服務，對比原生 prometheus 具備如下優勢：
原生的分布式能力支持，可彈性伸縮。
支持 Prometheus 原生服務發現能力、文件、consul、k8s等。
業界絕大多數的 cmdb 后端存儲在 mysql 數據庫中，分布式采集服務增加針對mysql的目標服務發現能力，方便資源的一鍵接入服務發現。
數據不落盤，采集后直寫分布式時序數據集群。
絕大部分的指標原始數據不具備可讀性，需要進行函數運算才能更好的表達業務語義。分布式采集服務提供了數據運算，縱轉橫等能力，使得數據更具可讀性和符合用戶使用習慣。
高性能，低損耗。3000+主機、采集頻度30s、6.7萬points/s、nms-prometheus-scraper，內存占用是Prometheus的1/8, cpu使用率是Prometheus的1/7。
InfluxDB 作為時序數據庫領域的領導者，被廣泛運用。在一些中小型的項目中，InfluxDB 以單點的高性能、易用性以及自運維等優勢是時序數據庫的首選。但原生的 InfluxDB 開源版本，不支持分布式集群的方案，無法在超大規模，超高可用性要求的項目下落地。為了解決這個問題，可采用分布式時序存儲方案，基于中間件代理模式構建分布式的 influxdb 分布式存儲集群。
分布式集群首先要能夠支持 InfluxDB 的標準 http 協議，支持查詢和寫入。能夠面向上層透明，方便無縫切換。
可以基于多種的分片算法來分片路由管理時序數據，達到水平擴展的能力。
分布式集群要支持多副本的能力，支持副本個數可配置，解決企業級的高可用需求。
構建完的分布式指標存儲服務具備如下的優勢：
分布式集群，數據支持多副本容災滿足企業級數據安全的規范和高性能的要求，可支持百萬級指標實時寫入。
支持 influxdb 標準協議，面向上層透明，無縫對接，grafana，influxdb web console，InfluxDB SDK。
可視化的分片管理，管理運維復雜度低。
分布式集群版本支持 InfluxDB 標準函數。
分布式集群支持 InfluxDB 常用命令，如數據庫管理，measurement管理，存儲策略管理，連續查詢管理等。
分布式服務代理，支持數據預加工與補齊。
InfluxDB 支持的存儲策略，連續查詢能力，可實現自動清理和歸檔，降低現場運維投入。
Kapacitor 與 InfluxDB 都源于 influxData 技術棧下，基于 golang 開發，高性能，輕量化原生的 Kapacitor 存在如下三個劣勢：
默認情況下，Kapacitor 可自動訂閱InfluxDB數據源，數據在寫入到 Influxdb 時，InfluxDB 會主動推送數據到訂閱者。這種模式下，如果指標存儲 InfluxDB 異常，將影響 Kapacitor 的指標計算
Kapacitor 是單點的模式，無法支持海量指標的計算處理需求。
基本上所有的流式計算框架，計算任務的配置和管理都存在一定的門檻；而計算閾值的調整，計算任務管理是現場運維的高頻操作；降低任務配置門檻成為了分布式計算框架的核心關注點。
浩鯨科技流批一體計算平臺功能架構：
基于 Kapacitor 的劣勢制約了其在大規模實時計算領域的落地效果，浩鯨科技的流批一體計算平臺，從下面幾個的架構提升點來解決這些問題：
最終，浩鯨科技通過自建基于 OpenMetrics 規范的分布式采集服務，優化InfluxDB存儲為分布式架構，并結合Kapacitor打造流批一體計算平臺，實現了高效、可擴展且易于管理的百萬級指標采集、處理與計算解決方案。