官網，它不香麼？
直接乾貨 特點和適用場景
-
可以解決機器級、模塊級的監控
-
對象 == 機器
-
服務樹 靈活定製 對機器的一個分組機制
-
客戶端中內置了日誌匹配指標抽取能力，web頁面上支持了日誌匹配規則的配置，同時也支持讀取目標機器特定目錄下的配置文件的方式，讓業務指標監控更爲易用
業務系統自己埋點 插件 日誌抽取 -
告警策略直接與服務樹節點綁定
告警引擎重構爲推拉結合模式 告警引擎judge模塊通過心跳機制做到了故障自動摘除 -
近期幾個小時的數據默認存內存，大幅提升數據查詢效率，硬盤存儲方式仍然使用rrdtool
支持配置爲雙寫模式提升系統容災能力，tsdb會把監控數據轉發一份給index，在內存裏構建索引，便於後續數據檢索 -
補充：
集羣維度的監控指標，是需要聚合整個集羣的所有模塊、機器的指標
接入容器監控
完善更多監控插件 -
多用幾臺機器提高容災能力非常有必要
1000臺左右設備的場景，最好有至少2臺16C/32G/300G SSD以上配置 mysql、redis單獨做高可用部署
既然是生產環境，所有模塊掛掉都要自動拉起，都要設置開機自啓動
模塊
-
monapi部署打包的時候可以把pub目錄一併打包，這是前端資源文件，nginx一般和monapi混部，nginx依賴pub目錄。
-
index是索引處理模塊，可以部署2~3個實例，會發心跳信息給monapi，不依賴其他組件，可以在monapi部署完成之後來部署
-
index的部署依賴的文件是n9e-index二進制、etc/index.yml、etc/address.yml
-
tsdb的部署依賴的文件是n9e-tsdb二進制、etc/tsdb.yml、etc/address.yml
-
judge的部署依賴的文件是n9e-judge二進制、etc/judge.yml、etc/address.yml
-
transfer的部署依賴的文件是n9e-transfer二進制、etc/transfer.yml、etc/address.yml
-
collector的部署依賴的文件是n9e-collector二進制、etc/collector.yml、etc/address.yml
-
nginx作爲反向代理，根據不同location代理了monapi、transfer、index的前端請求
pub目錄下的前端資源也是由nginx來serve
廢話那麼多，先告訴我咋用，老鐵
-
1、用戶管理
-
2、監控對象 - 樹節點：
- 根節點是默認創建好的 一般是單位名字 下面可以是各種組織架構，一般按照不同業務部門
劃分 業務部門下面是不同的團隊
團隊下面是不同的項目
項目下面是不同的模塊
模塊下面是機房，葉子節點 - 將不同對象掛載到節點上
- 根節點是默認創建好的 一般是單位名字 下面可以是各種組織架構，一般按照不同業務部門
-
3、查看全部對象 給對象起別名，其實是要起個有意義的名字，供運維一眼識別
-
4、監控看圖 選擇節點，展示節點及其子節點下包含的所有機器
-
5、大盤 爲了巡檢 對比方便
-
6、策略的複雜 其實是自由、靈活 爲上層的多姿多彩提供服務
- 每條策略都可以單獨配置告警接收人並且可以直接綁定到服務樹節點
- 選擇服務樹後，排除樹下特殊節點 或者直接包含某個子節點
- 報警級別的作用是通過多少條渠道發送
- 有tag過濾，這個就很好了 精細化很多，所以想要做細還不累贅，採用tag管理是最好的方式
- 有hook，與自動化打通
- 留觀 很貼近生活，有病住院 治療結束後需要留院觀察 一週麼有異樣的話，辦理出院
- 有靜默恢復 只發送告警消息，不發送恢復通知
- 生效時間 用週一到週五(永恆)去靈活配置，而不用去修改日期這麼沉重的標識
-
7、端口 進程 監控配置
- 元文件：collector 中提供了portPath 格式看文檔吧 很詳細
- 頁面配置: service = 元文件的內容
-
8、日誌監控配置 讀取進程打印的日誌
- 元文件： log..json
- 頁面配置： 看文檔
-
9、插件
- 配置了plugin的目錄，我們只需把插件腳本放到這個目錄下
- 可以把採集腳本放到業務程序發佈包中 這樣它就業務的聲明週期一樣了 多好
- 插件執行之後要在stdout輸出一個json array，collector會截獲這個輸出，解析爲監控指標上報
- 報錯消息要打印到stderr，不要打印到stdout
-
10、sdk 直接推到 collector 也行