前置說明
各種環境的選型建議
- Docker compose 方式：僅僅用於簡單測試，不推薦在生產環境使用 Docker compose，升級起來挺麻煩的，除非你對 Docker compose 真的很熟
- 二進位制部署：最推薦的方式，穩，升級也方便
- Helm 方式：公司大規模使用了 Kubernetes，可以選擇 Helm 方式，前提是貴司對 Helm 這套真的很熟
- 儲存選型：如果之前沒有部署過，是個新環境，時序庫選型建議使用 VictoriaMetrics，單機版 VictoriaMetrics 就可以抗住每秒上百萬資料點，效能很好，CPU、記憶體的佔用都比 Prometheus 少，而且，完全相容 Prometheus 的查詢介面
- 時間校準：社群反饋的很多問題都是因為機器時間沒有校準，監控系統對時間很敏感，請各位先把機器時間校準一致，讓服務端的機器、時序庫的機器、要監控的目標機器、瀏覽器所在的 PC 時間，都保持一致
使用者名稱密碼
預設使用者是 root，密碼是 root.2020。
使用 Docker compose 快速體驗
具體可以參考這個文件。不推薦使用，除非你對 Docker compose 真的很熟！
安裝前置依賴
我們更推薦二進位制的方式來部署，後文都是以二進位制的方式來說明部署方式以及架構。夜鶯依賴 mysql 儲存使用者配置類資料，依賴 redis 儲存 jwt token 和機器心跳上報的 metadata，所以，先準備 mysql 和 redis。這倆元件請大家自行安裝，這裡也提供一個小指令碼來安裝這兩個元件，大家可以參考：
# install mysql
yum -y install mariadb*
systemctl enable mariadb
systemctl restart mariadb
mysql -e "SET PASSWORD FOR 'root'@'localhost' = PASSWORD('1234');"
# install redis
yum install -y redis
systemctl enable redis
systemctl restart redis上例中 mysql 的 root 密碼設定為了 1234，建議維持這個不變，後續就省去了修改配置檔案的麻煩。如果你想修改預設使用者名稱和密碼，就要對應的修改配置檔案中的 mysql 連線資訊，配置檔案的哪個地方配置了 mysql 的密碼呢？透過下面的命令可以找到：
# 夜鶯的主配置檔案是 etc/config.toml
grep "1234" etc/config.toml安裝夜鶯
可以去 https://flashcat.cloud/download/nightingale/ 找最新版本的包，文件裡的包地址可能已經不是最新的了
# 建立個 n9e 的目錄，後面把 n9e 相關的檔案解壓到這裡
mkdir -p /opt/n9e && cd /opt/n9e
# 下載 n9e 釋出包，amd64 是 x84 的包，下載站點也提供 arm64 的包，如果需要其他平臺的包則要自行編譯了
tarball=n9e-v6.0.0-ga.7.0.2-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如果日誌和埠都沒啥問題，恭喜，你完成了夜鶯的安裝！透過瀏覽器訪問這個機器的 17000，理論上就可以看到登入頁面了。
玩法1：僅使用夜鶯做告警管理
如果您之前已經部署了 Prometheus、Thanos、VictoriaMetrics、M3DB、Mimir 等某個時序庫，只是想使用夜鶯的告警管理功能，沒問題，架構如下：
假設你之前有個 Prometheus，只需要把 Prometheus 作為資料來源配置進來就可以了，入口在：
具體配置樣例如下：
這裡一些配置項的含義解釋如下：
- 名稱：隨意取名，就是個標識，使用英文命名
- URL：Prometheus 的訪問地址，如果是其他時序庫，這個地址就不同嘍，比如叢集版本的 VictoriaMetrics，可能是類似這麼個地址：
http://127.0.0.1:8481/select/0/prometheus - 超時時間：單位是毫秒，建議最小設定為10000，即10s，如果一些大的查詢，就會比較耗時
- 授權：如果時序庫啟用了 Basic auth，這裡就配置對應的 Basic auth username 和 password 即可
- 跳過 SSL 驗證：如果證書不是正兒八經的證書想要跳過校驗，就勾選這個項
- 自定義 HTTP 頭：訪問時序庫的時候可以附加一些 HTTP Header
- write_addr：這個是時序庫的 remote write 地址，我的例子中是 Prometheus，所以 url path 是
/api/v1/write，如果是其他時序庫可能不同，比如叢集版本的 VictoriaMetrics，remote write 地址可能是類似這個樣子：http://127.0.0.1:8480/insert/0/prometheus/api/v1/write。這個資訊用在哪裡呢？平時都用不到，除非你在夜鶯裡使用了記錄規則（recording rule），記錄規則會生成新指標，新指標要回寫時序庫，所以要求時序庫提供 remote write 地址。如果你不知道啥是 recording rule，可以 google 一下，google 關鍵字：“Prometheus recording rule”，或者跳過以後再說 - 關聯告警引擎叢集：這個說起來有點複雜了，選中預設的 default 即可，如果需要在邊緣機房單獨部署 n9e-alert 的時候，才需要詳細瞭解這個資訊
以上配置完成之後，我們去即時查詢驗證一下，看看能否查詢到這個 Prometheus 的資料：
如上就表示正常的，如果有些資料確定時序庫裡是有的，但是在即時查詢裡查不到，有可能是時間沒有校準，請自行檢查時間。之後，就可以在夜鶯裡配置告警規則了，具體可以參考後續告警相關的文件。
玩法2：使用 categraf 採集資料，使用夜鶯接收資料
社群裡經常有小夥伴諮詢，問夜鶯可以監控xx麼？
其實，夜鶯啥都可以監控，又啥都監控不了。夜鶯是一個服務端元件，類似 Grafana，可以接入不同的資料來源，比如 Prometheus、VictoriaMetrics、Thanos 等等，只要資料進到這些庫裡了，夜鶯就可以對資料來源的資料進行分析、告警、視覺化，以及後續的事件處理、告警自愈。
當然，夜鶯也有埠接收監控資料，可以跟開源社群常見的各種監控採集器打通，比如 Telegraf、Categraf、Grafana-agent、Datadog-agent、Prometheus 生態的各類 Exporter 等等。這些 agent 採集了資料推給夜鶯，夜鶯適配了這些 agent 的資料傳輸協議，所以可以接收這些 agent 上報的監控資料，轉存到後端對接的資料來源，之後就可以對這些資料做告警分析、視覺化。
所以夜鶯本身不做監控資料採集，啥都不能監控，但是夜鶯可以對接資料來源，又啥都可以監控。
這一小節，我們介紹使用 Categraf 作採集器，然後推資料給夜鶯，夜鶯轉存到時序庫，並且後續對這些資料做視覺化、告警等，整個架構如下圖所示：
圖上畫了三個 agent：datadog-agent、telegraf、categraf，都可以和夜鶯對接，我們推薦的是 categraf，所以本節主要以 categraf 舉例。夜鶯預設監聽的埠是 17000，透過 api：/prometheus/v1/write 接收 remote write 協議的監控資料，categraf 恰好可以以 remote write 協議上報監控資料，所以二者可以對接，telegraf、grafana-agent 其實也可以以 remote write 協議上報監控資料，所以也可以和夜鶯對接。
夜鶯收到監控資料之後，夜鶯自身不儲存這些時序資料，直接轉存到後端時序庫，在這裡，夜鶯的角色只是一個 Pushgateway 的角色。我們推薦的時序庫是單機版本的 VictoriaMetrics，後文就以此演示。當然了，夜鶯可以同時並行轉發資料給後端多個時序庫，就像上圖畫的，把一份資料同時儲存在 VictoriaMetrics 和 Prometheus，也是可以透過配置實現的。
安裝單機版本的 VictoriaMetrics
如果選用叢集版本的 VictoriaMetrics，可以參考 這裡。當然，單機版本對絕大部分公司，夠用了，配合雲盤保障資料可靠性，穩。所以這裡，我就演示單機版本的部署。
安裝 VictoriaMetrics
VictoriaMetrics 下載地址在 github releases 上，作為技術人員，我想，你應該可以下載的到。我的環境是 x86_64 的 linux，所以選擇下載：victoria-metrics-linux-amd64-v1.90.0.tar.gz （撰寫這個文件的時候，最新版本是 v1.90.0）。
VictoriaMetrics 解壓縮之後，裡邊就一個二進位制：
[root@vm-159 tarball]# ll vic*
-rw-r--r--. 1 root root 10370599 5月 17 18:43 victoria-metrics-linux-amd64-v1.90.0.tar.gz
-rwxr-xr-x. 1 1000 1000 20191152 4月 7 09:00 victoria-metrics-prod啟動它：
[root@vm-159 tarball]# nohup ./victoria-metrics-prod &> stdout.log &
[1] 12632
[root@vm-159 tarball]# ss -tlnp|grep 12632
LISTEN 0 128 *:8428 *:* users:(("victoria-metric",pid=12632,fd=10))透過上面的命令可以看出，單機版本的 VictoriaMetrics 監聽在 8428 埠。透過瀏覽器訪問 VictoriaMetrics 的 8428，理論上可以看到下面的頁面：
如上，就表示 VictoriaMetrics 安裝成功，當然，我僅僅使用 nohup 簡單啟動的，如果生產環境，建議使用 systemd 託管並設定開機自啟動。
打通夜鶯和 VictoriaMetrics
分兩個步驟，首先就類似上面配置 Prometheus 資料來源那種方式，在夜鶯裡配置一個 VictoriaMetrics 的資料來源，比如我的配置：
其次，就需要修改配置檔案了。開啟夜鶯的 etc/config.toml 配置，找到 HTTP.Pushgw 部分，預設配置如下：
[HTTP.Pushgw]
Enable = true
# [HTTP.Pushgw.BasicAuth]
# user001 = "ccc26da7b9aba533cbb263a36c07dcc5"這個表示：開啟夜鶯的監控資料接收類的 API，預設就是開啟的，所以，預設配置就夠了，不用動。那個 HTTP.Pushgw.BasicAuth 表示 BasicAuth（不懂啥是 BasicAuth 請自行 Google 哈） 的配置，如果是內網環境就維持註釋就可以了，不用開啟 BasicAuth，如果要把夜鶯接收資料的介面暴露到公網，為了安全考慮，就需要 HTTPS + BasicAuth 雙重保障了，這裡的 HTTP.Pushgw.BasicAuth 相關的配置在公網環境下就應該開啟，而且，應該修改這個 password：ccc26da7b9aba533cbb263a36c07dcc5，不要使用預設的 password。
另一個要修改的配置是 Pushgw.Writers 部分，把 VictoriaMetrics 的 remote write 地址配置上，我的環境的例子如下：
[Pushgw]
LabelRewrite = true
[[Pushgw.Writers]]
Url = "http://127.0.0.1:8428/api/v1/write"這裡的 [[Pushgw.Writers]] 是雙中括號擴起來的，這在 toml 配置中表示陣列，如果你想把資料轉發給後端多個時序庫，就可以配置多個 [[Pushgw.Writers]]，比如：
[Pushgw]
LabelRewrite = true
[[Pushgw.Writers]]
Url = "http://127.0.0.1:8428/api/v1/write"
[[Pushgw.Writers]]
Url = "http://127.0.0.1:9090/api/v1/write"OK，這樣一來，夜鶯接收到 categraf、telegraf、grafana-agent 等各類 agent 上報上來的監控資料，都會轉發給後端的 VictoriaMetrics，完活。
部署 categraf 上報監控資料
Categraf 的安裝請 參考文件，這個文件已經很詳細了就不再贅述了。重點關注配置檔案 config.toml，一個是 heartbeat 的配置：
[heartbeat]
enable = true
url = "http://127.0.0.1:17000/v1/n9e/heartbeat"這個配置是 Categraf 向夜鶯心跳的地址，夜鶯 v5 的話沒有這個機制，需要把 Categraf heartbeat 的 enable 關掉。我這裡演示的夜鶯 v6，所以 heartbeat 的 enable 要設定為 true，建議大家用高版本的 Categraf，我這裡用的是 v0.3.4。
另一個配置是 writers 部分：
[[writers]]
url = "http://127.0.0.1:17000/prometheus/v1/write"這表示：把資料推給夜鶯的 17000 埠，url path 是 /prometheus/v1/write 這是夜鶯的 remote write 協議的資料接收地址。
上面我的例子中，夜鶯的地址都是：127.0.0.1:17000，因為我的 Categraf 和 夜鶯 在一臺機器上，如果你的 Categraf 和夜鶯在不同的機器，注意改成合適的 IP。
按照 文件 中介紹的方法啟動 Categraf，我這只是臨時測試，所以，直接 nohup 啟動得了：
nohup ./categraf &> categraf.log &驗證結果
如果一切正常，Categraf 就會推資料給夜鶯，夜鶯轉發給 VictoriaMetrics，而 VictoriaMetrics 又是夜鶯的資料來源，所以在夜鶯的即時查詢頁面，理論上可以查詢到 VictoriaMetrics 的資料，驗證一下：
cpu_usage_active 這個指標就是 Categraf 採集上報的，看起來一切正常。歐耶！
夜鶯高可用方案
這裡服務端總共涉及到4個元件：時序庫、mysql、redis、夜鶯，其中時序庫、mysql、redis 的高可用，大家 Google 一下網上大堆資料，這裡不展開。關鍵是夜鶯如何做高可用？
其實，很簡單，多部署幾個 n9e 例項就可以了。多個 n9e 例項會自動組成叢集，分擔壓力。n9e 前面可以架設負載均衡，四層、七層都可以，某個 n9e 例項掛掉，負載均衡會自動剔除，使用者透過瀏覽器訪問夜鶯的時候，訪問負載均衡的地址，Categraf 的 writer 和 heartbeat 也配置成負載均衡的地址，就可以了。
如果夜鶯裡配置了3千條告警規則，部署了3個n9e例項，這三個n9e例項就會自動分配（透過一致性雜湊演算法）要處理的告警規則，確保每個n9e例項只處理大概1千條告警規則，分擔告警引擎處理壓力。如果某個n9e例項掛掉，其他例項會自動感知（利用mysql做了一些心跳機制）自動接管未被處理的告警規則，這也是把n9e叢集化部署的好處。
高階玩法
如果，夜鶯部署在北京機房，某些機房和北京機房網路鏈路較差，此時，應該把時序庫、告警引擎下沉部署，具體應該如何做呢？看這裡
https://flashcat.cloud/docs/content/flashcat-monitor/nighting...