這將是一個(gè)系列，講解 夜鶯監(jiān)控 的設(shè)計(jì)思考，可以理解為原理+最佳實(shí)踐+產(chǎn)品設(shè)計(jì)時(shí)的折中取舍。

本系列其他文章：

• 夜鶯監(jiān)控設(shè)計(jì)思考（一）項(xiàng)目定位、組件思考、單進(jìn)程多進(jìn)程選擇、高可用設(shè)計(jì)
• 夜鶯監(jiān)控設(shè)計(jì)思考（二）邊緣架構(gòu)的緣起和設(shè)計(jì)

本篇主要回答：

• 夜鶯和時(shí)序庫(kù)對(duì)接的設(shè)計(jì)邏輯
• 夜鶯和 agent 對(duì)接的設(shè)計(jì)邏輯

夜鶯和時(shí)序庫(kù)對(duì)接的設(shè)計(jì)邏輯

如果是夜鶯老用戶(hù)，應(yīng)該知道在 V4 以及之前的版本，夜鶯是有自研時(shí)序庫(kù)的。而 V5 開(kāi)始放棄了自研時(shí)序庫(kù)，轉(zhuǎn)而做各類(lèi)數(shù)據(jù)源的對(duì)接，這其中是怎么一個(gè)考慮？

V4 之前的版本，其實(shí)是沿襲了很多 Open-Falcon 的設(shè)計(jì)邏輯，甚至想做一款運(yùn)維平臺(tái)。后來(lái)發(fā)現(xiàn)有如下問(wèn)題：

• 運(yùn)維平臺(tái)是一個(gè)很大的東西，需要投入很多人力，靠開(kāi)源社區(qū)比較難
• 運(yùn)維平臺(tái)是一個(gè)沒(méi)有共識(shí)的產(chǎn)品，各家或多或少會(huì)有自己的額外需求，什么需求都想往里塞
• 觀察國(guó)內(nèi)外各個(gè)知名的開(kāi)源項(xiàng)目，都是有清晰專(zhuān)注的定位，通常來(lái)講，定位越精準(zhǔn)細(xì)分，越容易做透
• 社區(qū)用戶(hù)來(lái)用夜鶯，大都是奔著其監(jiān)控功能來(lái)的而非其他功能

本質(zhì)就是項(xiàng)目定位的考慮。縱觀整個(gè)監(jiān)控領(lǐng)域，時(shí)序庫(kù)、采集器、可視化工具，都有對(duì)應(yīng)的知名開(kāi)源項(xiàng)目了，唯獨(dú)告警引擎，是缺失的，所以，夜鶯從 V5 開(kāi)始，就重點(diǎn)做告警引擎。

作為一款告警引擎，需要有自己的時(shí)序庫(kù)么？顯然是不需要的，去對(duì)接各類(lèi)現(xiàn)成的時(shí)序庫(kù)就可以了。所以從 V5 開(kāi)始，夜鶯不做自己的時(shí)序庫(kù)了，整個(gè)架構(gòu)示意圖如下：

但是

這個(gè)架構(gòu)是需要用戶(hù)自己搞定采集器+存儲(chǔ)的，拿場(chǎng)景最大的指標(biāo)場(chǎng)景舉例，需要用戶(hù)自行搞定 Prometheus（或 VictoriaMetrics）+ 各類(lèi) Exporter。當(dāng)然，除了 Exporter，社區(qū)里還有別的采集器。

我們希望讓社區(qū)用戶(hù)輕松一些，所以往前走了一步，雖然夜鶯不做時(shí)序庫(kù)，但可以接時(shí)序數(shù)據(jù)，然后轉(zhuǎn)存到時(shí)序庫(kù)。夜鶯同時(shí)支持多種采集器，比如 Datadog-agent、Grafana-agent、Alloy、Telegraf 等，以及后來(lái)的 Categraf。

不同的采集器有不同的協(xié)議，夜鶯支持多種指標(biāo)寫(xiě)入?yún)f(xié)議，最終把數(shù)據(jù)轉(zhuǎn)存給時(shí)序庫(kù)。架構(gòu)示意圖如下：

夜鶯的配置文件 config.toml 里有 Pushgw 部分，就是用于配置后端時(shí)序庫(kù)的地址，可以配置多個(gè) Writer，數(shù)據(jù)就會(huì)同時(shí)轉(zhuǎn)存到多個(gè)后端，當(dāng)然，你也可以不配置 Writer，不用夜鶯來(lái)轉(zhuǎn)發(fā)數(shù)據(jù)。

監(jiān)控?cái)?shù)據(jù)采集領(lǐng)域，典型有兩種模式，PULL和PUSH，Prometheus的方式就是PULL模式，Datadog、Categraf 的模式是PUSH模式。

夜鶯提供了數(shù)據(jù)接收的 HTTP 端口，是典型的 PUSH 模式，如果你想用 PULL 模式，繼續(xù)使用 Prometheus + Exporter 即可。

PUSH 模式下，較難感知源端是否掛了，即 Nodata 告警，那夜鶯既然選擇了 PUSH 模式，也就專(zhuān)門(mén)提供了 Nodata 告警能力，所以上圖中各類(lèi) PUSH 類(lèi)型的 agent，如果數(shù)據(jù)經(jīng)由夜鶯轉(zhuǎn)發(fā)，則享有了 Nodata 告警能力，可以方便得知道哪個(gè) agent 掛了。

小結(jié)

夜鶯的典型用例場(chǎng)景，是用戶(hù)自行搞定數(shù)據(jù)采集和存儲(chǔ)，夜鶯僅作為告警引擎，對(duì)接數(shù)據(jù)源，做告警判定。

如果你也想讓數(shù)據(jù)流經(jīng)夜鶯，建議選擇下文介紹的 Categraf 采集器。和夜鶯的整合最為絲滑。

夜鶯和 agent 對(duì)接的設(shè)計(jì)邏輯

如前文介紹，社區(qū)已經(jīng)有很多采集器了，為啥還要再搞一個(gè) Categraf 呢？

社區(qū)使用最多的采集器，大概是各類(lèi) Exporter，但是 Exporter 比較零散，體現(xiàn)為：

• 不同的 Exporter 設(shè)計(jì)邏輯不同，有的和監(jiān)控目標(biāo)之間是一對(duì)一關(guān)系，有的是一對(duì)多關(guān)系
• 不同的 Exporter 日志打印方式不同
• 不同的 Exporter 傳參、配置文件格式各異
• 有些采集需求沒(méi)有對(duì)應(yīng)的 Exporter

所以，我們想做一些整合，搞一個(gè)大一統(tǒng)的采集器，同時(shí)，還有另一個(gè)重要原因：

夜鶯除了開(kāi)源版，還有企業(yè)版，企業(yè)用戶(hù)需要一個(gè)一致的產(chǎn)品體驗(yàn)，給他一堆 Exporter 不太能接受，其次，企業(yè)用戶(hù)各種稀奇古怪的采集需求，提到各個(gè) Exporter 那響應(yīng)太慢，另外，我們還想要采集規(guī)則下發(fā)能力。這些需求，勢(shì)必需要一個(gè)單獨(dú)的 agent，于是 Categraf 誕生了。

引入 Categraf 之后，架構(gòu)示意圖如下：

夜鶯有了自己的 agent 之后，就帶來(lái)了額外能力：

• agent 可以采集一些機(jī)器的 metadata 信息上報(bào)給夜鶯，讓用戶(hù)方便查看
• agent 和服務(wù)端周期性心跳，夜鶯就可以額外生成一個(gè)機(jī)器列表，類(lèi)似一個(gè)資產(chǎn)臺(tái)賬，當(dāng)然，自己做 Table 儀表盤(pán)其實(shí)也可以

Categraf 的配置文件里，會(huì)配置兩個(gè)夜鶯接口地址，一個(gè)是 heartbeat 的，一個(gè)是 writer 的：

• heartbeat：心跳接口，用于告訴服務(wù)端自己活著，同時(shí)上報(bào)機(jī)器的 meta 信息，heartbeat 如果 Disable 了，夜鶯的機(jī)器列表里就會(huì)看到機(jī)器的 CPU、內(nèi)存等字段都是 Unknown，點(diǎn)擊機(jī)器也看不到 metadata 信息
• writer：推送數(shù)據(jù)的接口，協(xié)議是 Prometheus remote write，其實(shí) Categraf 也可以把 writer 直接配置為時(shí)序庫(kù)的 remote write 地址，但是這樣數(shù)據(jù)就不走夜鶯了，不太推薦

不想用 Categraf 行不行

其實(shí)是可以的，夜鶯本就側(cè)重做告警引擎，你自己搞定數(shù)據(jù)采集和存儲(chǔ)是完全 OK 的。

不過(guò)，如果是新項(xiàng)目，還是建議使用 Categraf，至少用 Categraf 采集機(jī)器的 CPU、內(nèi)存、進(jìn)程、metadata 等基礎(chǔ)信息，這樣體驗(yàn)更好。至于各類(lèi)數(shù)據(jù)庫(kù)、中間件的監(jiān)控?cái)?shù)據(jù)，可以不用 Categraf，用你自己習(xí)慣的采集器即可。

總結(jié)

在夜鶯體系里，最簡(jiǎn)單的用法，就是僅使用 n9e 進(jìn)程，作為告警引擎，如果有邊緣機(jī)房的情況，可以繼續(xù)引入 n9e-edge 做邊緣機(jī)房的告警。

Categraf 也不是必須的，不過(guò)用 Categraf 采集機(jī)器的基礎(chǔ)指標(biāo)和夜鶯打通，體驗(yàn)會(huì)更好。看你自己的選擇吧。