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