這將是一個系列，講解 的設計思考，可(ke)以(yi)理(li)解為(wei)原(yuan)理(li)+最佳實踐+產品設計時(shi)的折中取舍。

整體定位

了解(jie)一(yi)個開源項目，最應該了解(jie)的(de)就是(shi)其定位(wei)，或者說(shuo)它要解(jie)決的(de)問題域(yu)。

夜鶯的定位就是四個字：告警引擎。夜(ye)鶯對接(jie)多種數據源（比如 Prometheus、VictoriaMetrics、MySQL、ClickHouse、Postgres、ElasticSearch），根據用戶配置的(de)告警(jing)規則，判定并產生(sheng)告警(jing)事件(jian)，然后對事件(jian)做(zuo) Pipeline 處理，最(zui)終通(tong)(tong)過各類通(tong)(tong)知媒介發出告警(jing)。

可(ke)以對比 Grafana 來理(li)解，Grafana 也是對接多(duo)種數據源，不過 Grafana 側重在(zai)數據可(ke)視化，夜鶯側重在(zai)告警。

沒有夜鶯之(zhi)前，各個數(shu)據源的告警(jing)是(shi)怎么處理的？

• Prometheus 是直接配置在 prometheus.yml 里，管理起來稍有不便
• VictoriaMetrics 是使用 vmalert，和 Prometheus 是類似的邏輯
• ElasticSearch 社區里用的比較多的是 elastalert 開源項目做告警判定
• ClickHouse、MySQL、Postgres 等貌似沒有專門的告警引擎

有了夜鶯(ying)之(zhi)后，就(jiu)可以(yi)在夜鶯(ying)里統一(yi)管理(li)告警規則、通知(zhi)媒介、消息模(mo)板、用戶(hu)聯系方式等(deng)。而且，夜鶯(ying)可以(yi)對(dui)告警事件做 Pipeline 處理(li)，比如(ru)：

• Relabel：類似指標的 Relabel，夜鶯可以對告警事件做 Relabel
• Enrichment：事件豐富，比如調用 CMDB 的接口為事件附加更多豐富的上下文信息
• Drop：一些特定的告警事件要丟棄掉
• 等等

夜鶯的核心功能部件

確定了定位之后，如(ru)(ru)果你是夜鶯(ying)的(de)設計者，要如(ru)(ru)何設計其功能(neng)部件呢(ni)？

首先，需要(yao)一(yi)個 webapi。用(yong)(yong)于和用(yong)(yong)戶、第(di)三方交互，用(yong)(yong)戶需要(yao)做一(yi)些配(pei)置，比如(ru)：

• 數據源的配置
• 用戶、角色的管理
• 用戶聯系方式管理（比如電話、手機號等，未來在告警觸發時，要打電話發告警短信等）
• 各類規則配置，比如告警規則、屏蔽規則、訂閱規則
• 通知媒介、消息模板的管理
• Pipeline 的管理
• 查看歷史告警事件，做一些統計分析等

其次，需要有(you)一(yi)個后(hou)臺任(ren)務執(zhi)(zhi)行的邏輯，根據用戶配置的告警(jing)規則，周(zhou)期性(xing)執(zhi)(zhi)行，去查詢數據源(yuan)，判(pan)定數據異常并生成告警(jing)事件(jian)，最終發送。

• 最簡單的就是一個告警規則一個 goroutine（輕量級線程）后臺執行
• 如果執行失敗，通過某些監控指標反應異常，同時打印執行失敗的日志
• 需要考慮高可用，如果某個實例掛了，其他實例要頂上來
• 需要考慮 sharding，比如有兩個實例，有 1000 條規則，那每個實例要處理 500 條規則，不能重復執行，而且要均勻分配，如果某個實例掛了，剩下的實例要能承接原本宕機的實例負責的那些規則
• 對于某個實例而言，就要知道當前總共有多少實例，哪些實例存活，哪些實例掛了，否則，我不知道誰掛了我就沒法接管。這需要一個中心狀態存儲，或者引入 Raft 等協議

這個功能部(bu)(bu)件主要是負責告(gao)警，姑且(qie)稱之為 alert。所以，夜鶯(ying)至少有(you)兩個功能部(bu)(bu)件：webapi + alert。實際上(shang)，夜鶯(ying)還(huan)有(you)其他功能部(bu)(bu)件，后(hou)文(wen)再說。

單進程還是多進程

剛才講，夜鶯至少包含兩個功能部(bu)件：webapi + alert。那是做(zuo)成一個進(jin)程？還(huan)是做(zuo)成兩個進(jin)程？

如果是公司內部的系統，我更傾向于做成兩個進程，方便維護。但作為一個開源項目，還要考慮普通用戶的部署復雜度，則更傾向于做成一個進程。

高可用設計

對于 webapi 功(gong)能部件而(er)言，是一個無(wu)狀(zhuang)態的組件，接收 api 請求(qiu)然(ran)后對數據庫做 CRUD，所以(yi) webapi 可以(yi)水平擴展，部署多個，前(qian)面架設負(fu)載均(jun)衡，就(jiu)是高(gao)可用了。

alert 模(mo)塊需要(yao)協調分配告(gao)警規則，是有狀(zhuang)態的，既然我們不可避免要(yao)使用數據(ju)庫存(cun)儲各(ge)類配置(zhi)信息(xi)，那就順便用數據(ju)庫存(cun)儲 alert 的心跳信息(xi)得了，比較簡單。

所以，所有 alert 復(fu)用一個 MySQL，周期性心(xin)跳，這樣 DB 的(de)心(xin)跳表(biao)里就可以查到(dao)所有實(shi)例列表(biao)，以及(ji)最近(jin)一次心(xin)跳時間，從而得知(zhi)哪(na)些(xie)實(shi)例活著哪(na)些(xie)已經掛了（長時間沒(mei)有心(xin)跳就認(ren)為掛了）。

這樣的架構極(ji)為簡單，每個(ge)實例(li)的配置都是相同的，要做(zuo)高可(ke)用(yong)就搞多(duo)個(ge)機器部署多(duo)個(ge)實例(li)即可(ke)。社(she)區用(yong)戶用(yong)起來也(ye)簡單。

后記

本文介紹(shao)(shao)了夜(ye)鶯的定(ding)位、架(jia)構(gou)、單進程還(huan)是(shi)多進程的抉擇、高可用(yong)設計(ji)，如(ru)果你們公司只有(you)(you)一(yi)個機(ji)(ji)房(fang)(fang)(fang)或者有(you)(you)多個機(ji)(ji)房(fang)(fang)(fang)但是(shi)機(ji)(ji)房(fang)(fang)(fang)之(zhi)間有(you)(you)很好的網(wang)絡專線(xian)，那就(jiu)部署(shu)一(yi)套夜(ye)鶯就(jiu)可以了，如(ru)果有(you)(you)多個機(ji)(ji)房(fang)(fang)(fang)，但是(shi)機(ji)(ji)房(fang)(fang)(fang)之(zhi)間的網(wang)絡鏈路很差(cha)，就(jiu)需(xu)要考慮(lv)夜(ye)鶯的邊(bian)緣機(ji)(ji)房(fang)(fang)(fang)架(jia)構(gou)模式，咱們下一(yi)節詳細介紹(shao)(shao)。