我們都知道天下沒有“永不宕機”的系統，但每次線上出問題都要拉出一個程序員“祭天”。所以一款靠譜、好用的監控工具就顯得十分重要，它可以在生產環境出故障的第一時間發出告警，并提供詳實的數據，幫助程序員盡早發現故障、盡快定位問題。

可以毫不夸張地說，監控就是運維的眼睛、研發的“免死金牌”，程序員“明哲保身、自證清白”的必備利器！

一、夜鶯監控

今天 HelloGitHub 給大家帶來的是一款開箱即用、默認中文、界面美觀的開源監控系統——夜鶯監控（Nightingale），100% 國產更懂你的苦。你還在為搭建/配置/調優「Prometheus + AlertManager + Grafana」的監控平臺而煩惱嗎？開箱即用的夜鶯監控輕松解決你的問題。

GitHub：https://github.com/ccfos/nightingale

夜鶯監控是一款先進的開源云原生監控分析系統，采用 All-In-One 的設計，集數據采集、可視化、監控告警、數據分析、權限管理于一體，擁有企業級的監控分析和告警能力。

圖片

圖片

圖片

夜鶯監控在運維圈里很有名，它“出身名門”最初是由滴滴孵化并開源，在此期間沉淀了一線互聯網公司可觀測性的最佳實踐，有大廠的實踐背書可靠性和實用性上毋庸置疑。之后則捐贈給了中國計算機學會（CCF）進行托管，由運維圈的“老炮”秦曉輝等人設計、開發和維護。截止到發文前，夜鶯監控已在 GitHub 上獲得了 7200+ 個 Star、1200+ 次 Fork，發展勢頭迅猛、開源社區活躍，并且已經服務了上千家分布在各行各業的企業。

圖片

接下來，就和 HelloGitHub 一起上手這款開箱即用的開源監控利器吧！

二、安裝啟動

最簡單的部署方式是使用 docker-compose，可實現一鍵啟動，執行下面的命令即可：

git clone https://github.com/ccfos/nightingale.git
cd nightingale/docker
docker-compose up -d
# 成功后會有以下輸出
# Creating mysql      ... done
# Creating redis      ... done
# Creating prometheus ... done
# Creating ibex       ... done
# Creating agentd     ... done
# Creating n9e        ... done
# Creating telegraf   ... done

啟動之后瀏覽器直接訪問：127.0.0.1:17000，輸入賬號 root 密碼：root.2020，登陸后就能看到管理界面啦！

圖片

不過，我還是更推薦大家使用二進制方式部署，因為這種方式不依賴 Docker、更穩定、升級也方便，可用于生產環境（官方推薦），部署起來也不麻煩，也就多幾行命令的事。下面是 linux x86 環境的示例和注解：

# 創建個 n9e 的目錄，后面把 n9e 相關的文件解壓到這里
mkdir -p /opt/n9e && cd /opt/n9e

# 下載 n9e 發布包，amd64 是 x84 的包，下載站點也提供 arm64 的包，如果需要其他平臺的包則要自行編譯了
tarball=n9e-v6.1.0-linux-amd64.tar.gz
urlpath=https://download.flashcat.cloud/${tarball}
wget -q $urlpath || exit 1

# 解壓縮發布包
tar zxvf ${tarball}

# 解壓縮之后，可以看到 n9e.sql 是建表語句，導入數據庫
mysql -uroot -p1234 < n9e.sql

# 啟動 n9e，先使用 nohup 簡單測試，如果需要 systemd 托管，請自行準備 service 文件
nohup ./n9e &> n9e.log &

# 檢查 n9e.log 是否有異常日志，檢查端口是否在監聽，正常應該監聽在 17000
ss -tlnp|grep 17000

至此，安裝部分就結束了，接下來就是上手體驗了。

三、快速上手

3.1 配置數據源

夜鶯不生產日志，只是日志的“監工”。所以安裝完第一件事就是配置日志數據，用法類似 Grafana 可直接接入數據源，菜單位置：「系統配置」-「數據源」，目前支持：prometheus、victoriametrics、thanos、m3、elasticsearch、loki 等數據源。

圖片

完成數據源接入之后，就可以十分方便地通過可視化的方式查看日志了。

圖片

夜鶯默認提供了一些可視化大盤（菜單位置：「儀表盤」-「內置儀表盤」）和內置告警規則（菜單位置：「告警管理」-「內置規則」），導入自己的業務組（這是個管理概念，不同的告警規則和儀表盤可以使用不同的業務組分門別類管理 + 控制權限）就能使用啦。

3.2 好看的儀表盤

夜鶯的儀表盤展示效果美觀、性能出眾、功能豐富，雖然還沒有 Grafana 的全面，但基本可以作為 Grafana 的國產化平替了。夜鶯的儀表盤支持暗黑主題，效果如下：

圖片

前端 GitHub 地址：https://github.com/n9e/fe

3.3 采集器

如果之前沒有做過監控數據收集，可以使用夜鶯團隊提供的采集器 categraf，這同樣是一款開源的 telemetry 數據采集器，它內置了 OS、SNMP、IPMI、MySQL、Redis、MongoDB、Oracle、Kafka、ElasticSearch、cAdvisor 等多種采集插件。

GitHub：https://github.com/flashcatcloud/categraf

當然，也可以使用其他采集器，比如 telegraf、grafana-agent 等，但是 categraf 的對接最為絲滑。夜鶯支持多種數據接入協議，比如 prometheus remote write、OpenTSDB、Datadog 等，接收到數據之后做統一轉換，然后轉發給后端時序庫，具體轉發給哪些時序庫可以在夜鶯的配置文件中配置。

3.4 告警管理

靈活的告警是優秀監控系統的標配，夜鶯在這方面做得十分出色。它可以將一套規則應用于多個數據源，支持級別抑制、生效時間、告警屏蔽、告警訂閱、告警自愈等規則。

• 級別抑制：高級別抑制低級別告警，比如磁盤利用率超過 95% 產生 P1 告警，超過 85% 產生 P2 告警，如果某一時刻磁盤利用率跑到 100%，就只會觸發 P1 告警，P2 被抑制，避免告警打擾；
• 生效時間：可配置告警規則判定的生效時間，支持配置不同的多個日期和時段；
• 告警屏蔽：減少已知告警的干擾，比如某個機器要維護，可以提前屏蔽相關告警；
• 告警訂閱：告警消息分組通知；
• 告警自愈：告警可觸發預先設定好的腳本，自動解決故障；

菜單「告警管理」-「規則配置」的界面和示例如下：

圖片

四、深入了解

監控并不僅僅是可視化+告警那么簡單，里面有很多道道，下面讓我們“往下”走一點，深入了解下夜鶯監控的架構和解決的痛點。

4.1 架構介紹

夜鶯作為一款 Go 寫的監控系統，不僅部署方便，而且整體設計上非常開放和靈活，可以和開源生態上其他軟件組合使用，適用于已有監控系統升級或從零搭建監控平臺等場景。

• 采集器：可對接 telegraf、categraf、grafana-agent、datadog-agent、以及各類 exporter；
• 存儲：可對接 prometheus、thanos、m3、victoriametrics 等；

架構圖如下：

圖片

從依賴上看，夜鶯就只依賴 MySQL 和 Redis，它倆對于技術人員來說，都是非常熟悉的。除此之外，夜鶯在部署時只需一個二進制文件 + 配置文件，將開箱即用的精神貫徹到底！

4.2 項目結構

下面簡單介紹一下夜鶯的項目結構，即核心功能模塊介紹，方便想要深入了解夜鶯的同學快速進入源碼。

? # 夜鶯的目錄結構介紹
.
├── ...
├── alert         告警引擎相關邏輯，對 Prometheus、Loki、TDEngine 等數據源做異常數據判斷并產生告警事件。
├── center        Web 后端的邏輯。
├── cli           命令行工具，用于 v5 版本升級 v6 版本時的數據遷移。
├── cmd           入口包，所有的二進制的 main 函數入口都在這里。
├── conf          配置文件在內存里映射的數據結構。
├── docker        容器相關的文件，包括 Dockerfile 和 docker-compose 等，數據庫的建表 SQL 也在這里。
├── etc           配置文件，重點關注 config.toml，如果使用了邊緣機房的部署方案，還需要關注 edge.toml。
├── integrations  集成目錄，包含比如 MySQL、Redis、Elasticsearch 等各個監控目標的內置儀表盤、告警規則等。
├── models        數據庫操作相關的代碼。
├── pkg           通用 lib 庫。
├── prom          Prometheus 相關的代碼，包括 remote write 寫數據以及查詢接口的封裝。
├── tdengine      查詢 TDEngine（時序數據庫）相關的代碼。
├── storage       MySQL 和 Redis 的初始化連接相關的代碼。
└── pushgw        Pushgateway 相關的代碼，用于接收 remote write 數據、opentsdb 格式的數據、datadog 格式的數據、open-falcon 格式的數據，然后統一做格式轉換寫入后端存儲。

4.3 多機房場景

你是否遇到過需要監控多機房的場景？

目前，大多數公司都有很多機房，它們分布在不同的區域，這讓監控變得不再簡單。因為如果機房之間網絡鏈路很好，那么只需要部署一套監控系統就搞定了。但如果機房之間的網絡不太好，無法做到監控數據實時、可靠的上傳，但是告警規則又想在一個中心管理。

這個時候就需要高級部署方案，夜鶯提供了現成的邊緣機房部署方案，可以方便地解決上面的問題。架構圖如下：

圖片

通過夜鶯提供的高級部署方案，即在網絡不好的機房（邊緣）部署（下沉）時序數據庫和告警引擎（n9e-edge），從而保證數據不丟失和告警規則的同步，輕松構建統一的監控中心，實現多機房監控只需管理一套告警規則和可視化平臺。

真·企業級監控和告警一體化解決方案！

五、最后

開源的監控系統，目前用的比較廣泛的是 Zabbix 和 Prometheus，但它們或多或少都有一些不擅長的場景。

Zabbix 擅長設備監控，對各類操作系統、網絡設備有較好的兼容適配，但是不擅長微服務和云原生環境的監控。

• 不擅長動態變化對象的監控：Zabbix 是資產管理式，在云原生環境下，資產是動態變化的，比如 Pod、Service、Deployment 等。
• 不擅長微服務的監控：在微服務和云原生環境下，監控指標爆炸性增長，而且指標有不同的維度描述，Zabbix 使用關系型數據庫存儲時序數據，不擅長處理這種大規模的多維度的指標數據。

Prometheus 擅長微服務和云原生環境的監控，基本已經成為 Kubernetes 的標配，在云原生環境下非常流行，但它也有缺點。

• 設計上偏工具化，使用配置文件來管理規則，缺少權限化管理的 WebUI。
• 使用 Prometheus 的公司通常會不止一套，比如每個 Kubernetes 一套 Prometheus，多個 Prometheus 可能有很多相同的規則，管理起來比較重復。
• 其他一些小點：告警引擎是單點，告警事件沒有持久化；告警規則缺乏一些更為靈活的配置，比如生效時間。

夜鶯作為一款開源的云原生監控系統，在云原生方面有著先天優勢，而且使用國外的開源監控項目，最擔心的就是沒有技術支持，夜鶯作為“100% 國產”開源項目，在技術支持上分為社區支持和商業支持（響應更及時）兩種，服務的企業用戶已有上千家，比如移動、聯通、電信、米哈游、莉莉絲、方正證券、國泰君安、海底撈、海康、搜狐、新浪等，分布在各行各業。

圖片

最后，還是那句話：開源不易如果覺得夜鶯監控不錯的話，就請給個 Star 支持一下，試用反饋遇到的問題，也是對開源的一種支持！

GitHub：https://github.com/ccfos/nightingale

官網：https://flashcat.cloud/