我們都知道天下沒有“永不宕機”的系統，但每次線上出問題都要拉出一個程序員“祭天”。所以一款靠譜、好用的監控工具就顯得十分重要，它可以在生產環境出故障的第一時間發出告警，並提供詳實的數據，幫助程序員儘早發現故障、儘快定位問題。
可以毫不誇張地說：監控就是運維的眼睛、研發的“免死金牌”，程序員“明哲保身、自證清白”的必備利器！
一、夜鶯監控
今天 HelloGitHub 給大家帶來的是一款開箱即用、默認中文、界面美觀的開源監控系統——夜鶯監控（Nightingale），100% 國產更懂你的苦。你還在爲搭建/配置/調優「Prometheus + AlertManager + Grafana」的監控平臺而煩惱嗎？開箱即用的夜鶯監控輕鬆解決你的問題。
夜鶯監控是一款先進的開源雲原生監控分析系統，採用 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 等多種採集插件。
當然，也可以使用其他採集器，比如 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 支持一下，試用反饋遇到的問題，也是對開源的一種支持！
沒有能搞定一切的銀彈，或許這也是技術一直在更新迭代的動力之一吧！ 所以不要停下學習的腳步👣