這將是一個系列，講解(jie) 的設計思(si)考，可以(yi)理(li)解(jie)為原理(li)+最佳實(shi)踐+產品設計時的折中取舍。

本系列其他文章：

本篇主要回答：

• 夜鶯和時序庫對接的設計邏輯
• 夜鶯和 agent 對接的設計邏輯

夜鶯和時序庫對接的設計邏輯

如果(guo)是(shi)夜(ye)鶯老用戶，應該知(zhi)道在 V4 以及之前的(de)(de)版(ban)本，夜(ye)鶯是(shi)有自研時(shi)(shi)序庫(ku)的(de)(de)。而 V5 開始放(fang)棄(qi)了自研時(shi)(shi)序庫(ku)，轉而做各類數據源(yuan)的(de)(de)對接(jie)，這其(qi)中(zhong)是(shi)怎么一(yi)個考慮？

V4 之前(qian)的版本(ben)，其實是沿襲了(le)很(hen)多 Open-Falcon 的設(she)計邏輯，甚至想做一(yi)款運維平(ping)臺。后(hou)來發現有(you)如(ru)下問題：

• 運維平臺是一個很大的東西，需要投入很多人力，靠開源社區比較難
• 運維平臺是一個沒有共識的產品，各家或多或少會有自己的額外需求，什么需求都想往里塞
• 觀察國內外各個知名的開源項目，都是有清晰專注的定位，通常來講，定位越精準細分，越容易做透
• 社區用戶來用夜鶯，大都是奔著其監控功能來的而非其他功能

本質就是項目定位的(de)考(kao)慮。縱觀整個監控領域，時序庫、采集器(qi)、可視(shi)化工具，都有對應的(de)知(zhi)名開(kai)源項目了(le)，唯獨(du)告警引(yin)擎，是缺失的(de)，所以，夜鶯從 V5 開(kai)始，就重點做告警引(yin)擎。

作(zuo)為一(yi)款告警引擎(qing)，需(xu)要(yao)有自己(ji)(ji)的時序庫么？顯然(ran)是(shi)不需(xu)要(yao)的，去(qu)對接各類現成的時序庫就可以了(le)。所以從 V5 開始(shi)，夜(ye)鶯不做自己(ji)(ji)的時序庫了(le)，整個架構示意圖如下：

但是

這(zhe)個架構是(shi)需(xu)要(yao)用戶自己搞定(ding)采(cai)集器+存儲的(de)，拿場景最大的(de)指(zhi)標(biao)場景舉例，需(xu)要(yao)用戶自行搞定(ding) Prometheus（或 VictoriaMetrics）+ 各(ge)類(lei) Exporter。當然，除了(le) Exporter，社(she)區里還(huan)有別(bie)的(de)采(cai)集器。

我們(men)希望(wang)讓(rang)社區(qu)用戶輕松(song)一些，所以(yi)往前(qian)走了一步(bu)，雖然(ran)夜(ye)鶯不做(zuo)時序(xu)庫(ku)，但可(ke)以(yi)接時序(xu)數據(ju)，然(ran)后轉存到時序(xu)庫(ku)。夜(ye)鶯同(tong)時支(zhi)持多種(zhong)采(cai)集器(qi)，比如 Datadog-agent、Grafana-agent、Alloy、Telegraf 等，以(yi)及后來(lai)的 Categraf。

不同(tong)(tong)的采集器有不同(tong)(tong)的協議，夜鶯支持(chi)多種指標(biao)寫(xie)入協議，最(zui)終(zhong)把數據轉存(cun)給時序庫。架構示意圖如(ru)下(xia)：

夜鶯的配(pei)(pei)置文件 config.toml 里有 Pushgw 部分，就是用于配(pei)(pei)置后端時序庫的地址(zhi)，可以配(pei)(pei)置多(duo)個 Writer，數據就會同時轉存到多(duo)個后端，當(dang)然，你也可以不(bu)(bu)配(pei)(pei)置 Writer，不(bu)(bu)用夜鶯來(lai)轉發(fa)數據。

監控數據(ju)采集領域(yu)，典(dian)型有兩(liang)種模式，PULL和(he)PUSH，Prometheus的方式就(jiu)是(shi)(shi)PULL模式，Datadog、Categraf 的模式是(shi)(shi)PUSH模式。

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

PUSH 模式下，較難感知源端是否掛(gua)了，即 Nodata 告(gao)(gao)警(jing)，那夜鶯既然選擇了 PUSH 模式，也就(jiu)專門(men)提供了 Nodata 告(gao)(gao)警(jing)能力(li)，所(suo)以上圖中各類 PUSH 類型的 agent，如果數據(ju)經由夜鶯轉發，則享有(you)了 Nodata 告(gao)(gao)警(jing)能力(li)，可以方便得知道哪個 agent 掛(gua)了。

小結

夜鶯的典型用例場景，是用戶自行搞定數據采(cai)集(ji)和(he)存儲，夜鶯僅作(zuo)為告(gao)警引(yin)擎，對接數據源，做告(gao)警判定。

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

夜鶯和 agent 對接的設計邏輯

如(ru)前文介紹，社區(qu)已經有很多采集器了(le)，為啥還要(yao)再搞一個 Categraf 呢？

社區使用最多的采集器，大概是(shi)(shi)各類 Exporter，但是(shi)(shi) Exporter 比(bi)較零散，體(ti)現為：

• 不同的 Exporter 設計邏輯不同，有的和監控目標之間是一對一關系，有的是一對多關系
• 不同的 Exporter 日志打印方式不同
• 不同的 Exporter 傳參、配置文件格式各異
• 有些采集需求沒有對應的 Exporter

所以，我們(men)想做一些整(zheng)合，搞一個大一統的采集器(qi)，同時(shi)，還有(you)另一個重要原因(yin)：

夜鶯除了(le)開源版，還(huan)有企業(ye)版，企業(ye)用戶(hu)需要一(yi)個(ge)一(yi)致(zhi)的(de)產(chan)品(pin)體(ti)驗，給他一(yi)堆 Exporter 不太(tai)能接(jie)受，其次，企業(ye)用戶(hu)各(ge)種稀奇古怪的(de)采(cai)集(ji)需求，提到(dao)各(ge)個(ge) Exporter 那響應太(tai)慢(man)，另外，我們還(huan)想要采(cai)集(ji)規則下發能力。這些需求，勢必需要一(yi)個(ge)單獨的(de) agent，于是 Categraf 誕(dan)生(sheng)了(le)。

引入 Categraf 之后，架構示意圖如下：

夜(ye)鶯有了(le)自己的 agent 之后，就(jiu)帶來了(le)額外能力：

• agent 可以采集一些機器的 metadata 信息上報給夜鶯，讓用戶方便查看
• agent 和服務端周期性心跳，夜鶯就可以額外生成一個機器列表，類似一個資產臺賬，當然，自己做 Table 儀表盤其實也可以

Categraf 的配(pei)置文件(jian)里，會配(pei)置兩個夜鶯接口地(di)址，一個是(shi) heartbeat 的，一個是(shi) writer 的：

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

不想用 Categraf 行不行

其實是可以的(de)(de)，夜(ye)鶯(ying)本(ben)就(jiu)側(ce)重做告警引(yin)擎(qing)，你自(zi)己搞定數據采集和存儲是完全 OK 的(de)(de)。

不過，如果是新項目，還是建議使用(yong)(yong) Categraf，至少用(yong)(yong) Categraf 采集(ji)機器的(de) CPU、內(nei)存、進程、metadata 等基礎信息，這(zhe)樣體驗更好(hao)。至于各類數據(ju)庫、中間件的(de)監(jian)控數據(ju)，可以不用(yong)(yong) Categraf，用(yong)(yong)你自己習慣的(de)采集(ji)器即可。

總結

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

Categraf 也不是(shi)必須的，不過用 Categraf 采集機器的基礎指標和(he)夜鶯打通，體驗會更好(hao)。看(kan)你自(zi)己的選擇吧。