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

整體定位

了解一個(ge)開(kai)源項(xiang)目，最應該了解的就是其(qi)定位，或者說它(ta)要解決的問題域。

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

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

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

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

有了夜(ye)鶯之后，就可以(yi)在(zai)夜(ye)鶯里統一管理告(gao)警(jing)規(gui)則、通知(zhi)媒介、消息模板、用戶聯系方式(shi)等。而且，夜(ye)鶯可以(yi)對(dui)告(gao)警(jing)事件做 Pipeline 處(chu)理，比(bi)如：

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

夜鶯的核心功能部件

確(que)定了定位之后(hou)，如果(guo)你是夜鶯的(de)設計者，要如何設計其(qi)功能部(bu)件呢？

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

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

其次，需要有一個后(hou)臺任務(wu)執行的邏(luo)輯(ji)，根據用戶配(pei)置的告(gao)(gao)警規則，周期性(xing)執行，去查詢數據源(yuan)，判定數據異常并生成(cheng)告(gao)(gao)警事件，最終發送。

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

這個(ge)功(gong)能部件(jian)主要是負責告警(jing)，姑且稱之為(wei) alert。所以，夜鶯(ying)至少有兩個(ge)功(gong)能部件(jian)：webapi + alert。實際上，夜鶯(ying)還有其他功(gong)能部件(jian)，后文再說。

單進程還是多進程

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

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

高可用設計

對于 webapi 功能部件而言(yan)，是(shi)一個(ge)無狀態的組(zu)件，接收 api 請求(qiu)然后對數據(ju)庫做 CRUD，所以 webapi 可以水(shui)平(ping)擴展，部署(shu)多個(ge)，前面(mian)架(jia)設負(fu)載(zai)均衡，就是(shi)高可用(yong)了。

alert 模(mo)塊需(xu)要協調分配告警規(gui)則，是有(you)狀態的，既然我們(men)不(bu)可避免要使用數據庫存(cun)儲(chu)各類配置信(xin)息，那就順便用數據庫存(cun)儲(chu) alert 的心跳(tiao)信(xin)息得了(le)，比較簡單。

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

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

后記

本文介紹了夜(ye)鶯的(de)(de)(de)定位(wei)、架構、單(dan)進(jin)程(cheng)還(huan)是多(duo)(duo)進(jin)程(cheng)的(de)(de)(de)抉擇、高可用(yong)設計(ji)，如果你們(men)公司只有(you)(you)一(yi)個(ge)機房(fang)(fang)或者(zhe)有(you)(you)多(duo)(duo)個(ge)機房(fang)(fang)但是機房(fang)(fang)之間(jian)(jian)有(you)(you)很(hen)(hen)好(hao)的(de)(de)(de)網(wang)絡專線(xian)，那就部(bu)署一(yi)套夜(ye)鶯就可以了，如果有(you)(you)多(duo)(duo)個(ge)機房(fang)(fang)，但是機房(fang)(fang)之間(jian)(jian)的(de)(de)(de)網(wang)絡鏈路很(hen)(hen)差，就需要考慮夜(ye)鶯的(de)(de)(de)邊緣機房(fang)(fang)架構模式，咱們(men)下(xia)一(yi)節(jie)詳(xiang)細介紹。