國產(chǎn)監(jiān)控之光-夜鶯監(jiān)控（Nightingale）

夜鶯是什么？

夜鶯是一個服務端組件，類似 Grafana，可以對接不同的TSDB時序數(shù)據(jù)庫作為數(shù)據(jù)源，支持的TSDB時序數(shù)據(jù)庫如Prometheus、VictoriaMetrics、Thanos等等，只要數(shù)據(jù)進到這些庫里了，夜鶯就可以對數(shù)據(jù)源的數(shù)據(jù)進行分析、告警、可視化，以及后續(xù)的事件處理、告警自愈。

當然，夜鶯也有端口接收監(jiān)控數(shù)據(jù)，可以跟開源社區(qū)常見的各種監(jiān)控采集器打通，比如Telegraf、Categraf、Grafana-agent、Datadog-agent、Prometheus生態(tài)的各類Exporter等等。這些agent采集了數(shù)據(jù)推給夜鶯，夜鶯適配了這些agent的數(shù)據(jù)傳輸協(xié)議，所以可以接收這些agent上報的監(jiān)控數(shù)據(jù)，轉(zhuǎn)存到后端對接的數(shù)據(jù)源，之后就可以對這些數(shù)據(jù)做告警分析、可視化。

(資料圖片)

夜鶯部署架構(gòu)

根據(jù)生產(chǎn)網(wǎng)絡環(huán)境，夜鶯可以實現(xiàn)中心匯聚式部署方案和邊緣下層式混雜部署方案。

對于網(wǎng)絡結(jié)構(gòu)簡單或小規(guī)模網(wǎng)絡場景下，采用中心匯聚式部署方案實施比較簡單，可以n9e核心組件采用單機或集群方式搭建，集群模式下前端需架設Nginx作為軟負載或F5進行硬件設備負載，同時依賴MySQL和Redis中間件存儲基礎(chǔ)的元數(shù)據(jù)、用戶信息等，不存在大數(shù)據(jù)量問題，因此，不用太考慮性能瓶頸。

Categraf是夜鶯團隊開發(fā)維護的監(jiān)控采集側(cè)核心組件，類似Telegraf、Grafana-Agent、Datadog-Agent，希望對所有常見監(jiān)控對象提供監(jiān)控數(shù)據(jù)采集能力，采用All-in-one的設計，不但支持指標采集，也希望支持日志和調(diào)用鏈路的數(shù)據(jù)采集。Categraf采集器采集了數(shù)據(jù)推送給夜鶯，然后轉(zhuǎn)存到后端數(shù)據(jù)源，如TSDB、ElasticSearch等。

注意：Categraf不屬于夜鶯監(jiān)控系統(tǒng)組件，夜鶯定位是服務端組件，不側(cè)重監(jiān)控數(shù)據(jù)采集側(cè)。

所有機房網(wǎng)絡域下監(jiān)控數(shù)據(jù)采集器都直接推數(shù)據(jù)給n9e，這個架構(gòu)最為簡單，維護成本最低。當然，前提是要求機房網(wǎng)絡域結(jié)構(gòu)簡單、規(guī)模不大場景，即不太關(guān)注跨網(wǎng)絡域訪問安全問題和大規(guī)?？缇W(wǎng)絡域傳輸數(shù)據(jù)網(wǎng)絡帶寬限制等。

如果非上述場景，則要使用下面的邊緣下沉式混雜部署方案：

這個圖嘗試解釋 3 種不同的情形，比如 A 機房和中心網(wǎng)絡鏈路很好，Categraf可以直接匯報數(shù)據(jù)給中心n9e模塊，另一個機房網(wǎng)絡鏈路不好，就需要把時序庫下沉部署，時序庫下沉了，對應的告警引擎和轉(zhuǎn)發(fā)網(wǎng)關(guān)也都要跟隨下沉，這樣數(shù)據(jù)不會跨機房傳輸，比較穩(wěn)定。但是心跳還是需要往中心心跳，要不然在對象列表里看不到機器的 CPU、內(nèi)存使用率。還有的時候，可能是接入的一個已有的Prometheus，數(shù)據(jù)采集沒有走Categraf，那此時只需要把Prometheus作為數(shù)據(jù)源接入夜鶯即可，可以在夜鶯里看圖、配告警規(guī)則，但是就是在對象列表里看不到，也不能使用告警自愈的功能，問題也不大，核心功能都不受影響。

邊緣下沉式混雜部署方案中涉及到兩個核心組件：n9e-pushgw組件和n9e-alert組件。

n9e-pushgw組件提供類似于remote_write和remote_read功能，categraf采集器將數(shù)據(jù)通過remote_write推送給n9e-pushgw組件，然后轉(zhuǎn)存到tsdb時序數(shù)據(jù)，n9e服務端查詢檢索數(shù)據(jù)時通過remote_read講求轉(zhuǎn)發(fā)到對應機房下的n9e-pushgw組件。n9e-alert組件提供基于tsdb時序庫中的指標數(shù)據(jù)告警功能。

一鍵部署

筆者已經(jīng)在公有云上搭建了一套臨時環(huán)境，可以先登錄體驗下：

http://124.222.45.207:17000/login 賬號：root/root.2020

下面介紹下使用docker-compose快速一鍵部署。

1、代碼在這里： https://github.com/ccfos/nightingale 。如果有 docker 和 docker-compose 環(huán)境，我們就可以一鍵安裝了：

git clone https://github.com/ccfos/nightingale.git cd nightingale/docker docker-compose up -d

2、安裝完成之后，查看組件部署運行情況：

[root@VM-4-14-centos docker]# docker-compose ps    Name                 Command               State                         Ports                        -------------------------------------------------------------------------------------------------------- categraf     /entrypoint.sh                   Up                                                         ibex         sh -c /wait && /app/ibex s ...   Up      0.0.0.0:10090->10090/tcp, 0.0.0.0:20090->20090/tcp mysql        docker-entrypoint.sh mysqld      Up      0.0.0.0:3406->3306/tcp, 33060/tcp                  n9e          sh -c /wait && /app/n9e          Up      0.0.0.0:17000->17000/tcp                           prometheus   /bin/prometheus --config.f ...   Up      0.0.0.0:9090->9090/tcp                             redis        docker-entrypoint.sh redis ...   Up      0.0.0.0:6379->6379/tcp 

注意，docker中不能有同名組件，比如我在安裝過程中出現(xiàn)：ERROR: for prometheus Cannot create container for service prometheus: Conflict. The container name "/prometheus" is already in use by container xxx. You have to remove (or rename) that container to be able to reuse that name。

3、瀏覽器訪問n9e組件暴露的17000端口，即可看到頁面，默認賬號密碼如下：

username = "root" password = "root.2020"

4、訪問prometheus組件暴露的9090端口，可以打開Prometheus WebUI：

從Targets界面顯示Prometheus接入2個目標采集點，從端口可以識別一個抓取n9e組件監(jiān)控指標，另一個就是抓取prometheus組件自身指標。

基本使用

1、打開【基礎(chǔ)設施】/【機器列表】菜單，該界面提供Categraf采集點機器管理，在【未歸組對象】下就可以看到剛才部署的一個Categraf采集點：

Categraf 是一個監(jiān)控采集 Agent，類似 Telegraf、Grafana-Agent、Datadog-Agent，希望對所有常見監(jiān)控對象提供監(jiān)控數(shù)據(jù)采集能力，采用 All-in-one 的設計，不但支持指標采集，也希望支持日志和調(diào)用鏈路的數(shù)據(jù)采集。

Categraf通過Heartbeat心跳服務將節(jié)點的狀態(tài)、內(nèi)存、CPU、時間偏移、核數(shù)、OS等信息上報給n9e組件，進而Web上方便查看。

方便機器列表管理，可以進行分組，如下圖我們對機器按照機房地域劃分，并創(chuàng)建chengdu業(yè)務組：

這里我打開【作為標簽使用】開關(guān)，該業(yè)務組下機器采集數(shù)據(jù)推送TSDB庫時會自動打上busigroup=英文標識標簽，方便基于該維度進行數(shù)據(jù)聚合統(tǒng)計。

【團隊】這欄用于權(quán)限控制，比如控制哪個團隊成員可以對該業(yè)務組下機器具有讀寫權(quán)限，或者只讀權(quán)限等?！救藛T管理】/【團隊管理】頁面可以創(chuàng)建、管理團隊。

選中機器，點擊【批量操作】下【修改業(yè)務組】，將機器移入到新創(chuàng)建的業(yè)務組里：

還可以選中機器，選擇【批量操作】/【綁定標簽】，手工為機器打上指定標簽，則關(guān)聯(lián)機器指標存儲到TSDB時序數(shù)據(jù)庫時會帶上這些標簽：

2、配置數(shù)據(jù)源

打開【系統(tǒng)配置】/【數(shù)據(jù)源】菜單，進入數(shù)據(jù)源管理界面，選擇添加Prometheus數(shù)據(jù)源：

我這里采用docker compose一鍵部署，所以這里url可以填寫http://prometheus:9090。

2、添加好數(shù)據(jù)源，打開【時序指標】/【即時查詢】菜單：

這個查詢基本類似于Prometheus WebUI查詢頁面，關(guān)聯(lián)數(shù)據(jù)源，輸入PromQL即可查詢指標數(shù)據(jù)，點擊Graph還可以展示對應的區(qū)間趨勢圖。

指標cpu_usage_active{busigroup="chengdu",cpu="cpu-total",env="test",ident="categraf01",source="categraf"}標簽說明：

1、busigroup="chengdu"：這個就是剛才創(chuàng)建業(yè)務組時打開【作為標簽使用】開關(guān)配置的標簽；

2、cpu="cpu-total"：組件暴露指標自身業(yè)務標簽；

3、env="test"：剛才在機器上手工綁定標簽配置；

4、ident="categraf01"：機器標識，即Categraf組件所屬主機名；

當然也可以在Categraf組件config.toml配置文件中指定hostname：

5、source="categraf"：Categraf組件config.toml配置文件中g(shù)lobal.labels配置信息：

[global.labels] source="categraf" # region = "shanghai" # env = "localhost"

總結(jié)

夜鶯監(jiān)控系統(tǒng)部署架構(gòu)簡單，對于小規(guī)模監(jiān)控場景下快速搭建一套監(jiān)控系統(tǒng)來說是比較值得推薦的方式，整體體驗也比較友好。但對于大規(guī)模監(jiān)控場景，可能還不是那么的足夠完善。

Categraf采集組件

1、categraf采集器采用推送模式(push)，而不是Prometheus的拉(pull)模式，push模式導致采集器存在狀態(tài)，即采集器要知道自己要推送給哪個服務后端的配置，少量categraf采集器來說無所謂，但是一旦成千上萬采集點，甚至幾百采集點，維護成本都是比較高的，特別是后端地址發(fā)生變更等。

2、push模式還存在接入權(quán)限問題，因為往往服務后端和采集器維護是兩撥人，服務后端是運維人員，而采集器是項目組人員維護，比較難于控制接入，可能個別項目組大量接入采集點造成服務端壓力過大奔潰，從而影響整個系統(tǒng)運行穩(wěn)定。

3、push模式還存在推送頻率問題，categraf組件可以配置推送頻率，但是只能在采集器端控制，不同項目組運維人員可能配置不同推送頻率，難以從全局控制，或者這么個場景：前期采集點少，數(shù)據(jù)量不大，推送頻率5s，但是后面接入的越來越多，存儲不夠用，需要下調(diào)推送頻率15s，沒有統(tǒng)一修改調(diào)整方式。

部署架構(gòu)優(yōu)化

邊緣下沉式混雜部署方案中categraf采集器還需要和夜鶯后端n9e組件進行heartbeat心跳交互，這里可能會存在問題，對于大規(guī)模網(wǎng)絡下，categraf會部署成千上萬個實例，服務后端n9e組件維護這些心跳性能：

1、服務后端n9e組件維護這些心跳對服務性能和網(wǎng)絡IO都存在損耗問題，一個心跳交互影響微乎其微，但是放到成千上萬個節(jié)點心跳這個影響就會擴大；

2、邊緣下沉式混雜部署方案往往就是由于網(wǎng)絡環(huán)境復雜，為了heartbeat需要打通服務后端和那么多categraf組件網(wǎng)絡連通性，可能影響是致命的；

3、n9e服務后端和categraf組件心跳傳遞數(shù)據(jù)主要：在線狀態(tài)、CPU%、內(nèi)存、CPU核數(shù)、CPU架構(gòu)等，這個在線狀態(tài)更多的是反映后端和categraf組件連通性，我覺得在線狀態(tài)應該反映categraf有沒有正常采集指標數(shù)據(jù)并推送到tsdb庫可能更加合理，查看categraf采集組件歷史一段區(qū)間內(nèi)的在線狀態(tài)、CPU、內(nèi)存等，后端還需要考慮存儲這些指標數(shù)據(jù)；

所以，categraf心跳交互這個邏輯應該移除，將心跳數(shù)據(jù)以指標方式暴露，并增加一個up指標反映在線狀態(tài)，在categraf向n9e-pushgw組件推送數(shù)據(jù)時一并存儲到tsdb時序庫中。n9e后端在查詢categraf當前狀態(tài)或某歷史區(qū)間在線情況時，都可以通過n9e-pushgw從tsdb時序庫中拉取展示。

比如中心網(wǎng)絡和邊緣下沉網(wǎng)絡可能有一段時間網(wǎng)絡斷開，這種只會影響后端過來的查詢不能執(zhí)行，categraf采集組件本身依然可以正常采集數(shù)據(jù)并推送到tsdb時序庫，對于categraf采集器組件來說依然是正常在線的，因為網(wǎng)絡域內(nèi)部是正常的，待網(wǎng)絡恢復后，n9e服務端就可以通過n9e-pushgw組件從tsdb時序庫中查詢出這段時間categraf是否正常采集、CPU使用率等等情況。

邊緣下沉式混雜部署方案不同網(wǎng)絡域下TSDB時序庫是割裂的，全局聚合匯總數(shù)據(jù)暫未發(fā)現(xiàn)如何實現(xiàn)：