從大公司投身到創(chuàng)業(yè)型的小公司，我最深的感受就是“由奢入儉難”這五個(gè)字。以前公司里有完善的框架體系，涵蓋了分布式log、監(jiān)控、實(shí)時(shí)報(bào)警、大數(shù)據(jù)存儲(chǔ)等等方面，并且有成熟的團(tuán)隊(duì)來(lái)運(yùn)營(yíng)，使用者大部分時(shí)間只要做好集成就行；換到了小公司，初始的一長(zhǎng)段時(shí)間內(nèi)，技術(shù)團(tuán)隊(duì)只有3人，起步階段一窮二白，而且要做兩個(gè)體系的產(chǎn)品，每天業(yè)務(wù)的壓力就很大，做起事來(lái)只能用些比較粗糙的手段。業(yè)務(wù)的壓力和質(zhì)量的追求始終是個(gè)矛盾。然而，該有的絕不能少，所以我們還是盡量抽出一些時(shí)間做好部分必須的框架工作。在我們看來(lái)，監(jiān)控和報(bào)警框架是優(yōu)先級(jí)***的：
1.創(chuàng)業(yè)型公司在測(cè)試方面，無(wú)法做到非常充分，出現(xiàn)問(wèn)題的概率比較大，需要做好監(jiān)控。
2.對(duì)一個(gè)復(fù)雜系統(tǒng)的把握，必然是大量的自動(dòng)化的監(jiān)控、度量，時(shí)刻要知道系統(tǒng)里每個(gè)組件的各種運(yùn)行指標(biāo)。實(shí)際上，有經(jīng)驗(yàn)的工程師會(huì)體會(huì)到，做好監(jiān)控和運(yùn)營(yíng)，在難度和重要性上要遠(yuǎn)高于你寫(xiě)的功能代碼。
3.人少，就要自動(dòng)化程度高。只有做好監(jiān)控和自動(dòng)化報(bào)警，才能抽出更多的精力忙業(yè)務(wù)，晚上才能放心睡覺(jué)。
因此，想要做出可靠穩(wěn)定的產(chǎn)品，首先要有靠譜的監(jiān)控報(bào)警框架去做支撐。而對(duì)于像我們這樣的創(chuàng)業(yè)公司來(lái)說(shuō)，還需要關(guān)心以下幾點(diǎn)：
1.有沒(méi)有成熟的開(kāi)源產(chǎn)品。大公司可以花費(fèi)一個(gè)團(tuán)隊(duì)專(zhuān)心做一件事情；而小公司每個(gè)人都是非常珍貴的資源，半個(gè)人的開(kāi)銷(xiāo)都嫌大，所以會(huì)更多的借力于開(kāi)源產(chǎn)品。
2.坑多不多。開(kāi)源產(chǎn)品的質(zhì)量和支持沒(méi)有辦法和商業(yè)產(chǎn)品相比，所以我們需要選用可以hold住的，坑少且穩(wěn)定的產(chǎn)品使用。
3.能否支持跨語(yǔ)言。我們的產(chǎn)品基本上是C、Java、Python、JSON的混合產(chǎn)品，尤其是后端主要由Java和python組成。
4.可伸縮性是否足夠好。我們的業(yè)務(wù)和數(shù)據(jù)在快速發(fā)展，所以使用的產(chǎn)品必須能支持后期海量數(shù)據(jù)的涌入。
5.是否有一定的擴(kuò)展性。使用過(guò)程中必然會(huì)有一些特殊的需求，如何快速的做些定制化也是需要考量的點(diǎn)。
6.能否同時(shí)支持單機(jī)和分布式的部署。我們情況比較特殊，既有傳統(tǒng)的私有化部署的軟件解決方案，又有公有的SaaS以及配套的大規(guī)模計(jì)算集群。因此，我們很多產(chǎn)品都要有高低配兩種實(shí)現(xiàn)，同時(shí)通過(guò)配置來(lái)實(shí)現(xiàn)無(wú)縫切換。監(jiān)控系統(tǒng)也不例外。
極度重要，要求又多，資源還少，所以我們?cè)诒O(jiān)控和報(bào)警方面還是花了一些心思。下面，我會(huì)詳細(xì)分享下我們所做的實(shí)踐探索。
先看監(jiān)控
首先要談監(jiān)控。監(jiān)控的要點(diǎn)就是通過(guò)定義多種metrics來(lái)輔助我們?nèi)チ私猱a(chǎn)品。從硬件到軟件，從LB到后端數(shù)據(jù)庫(kù)的實(shí)時(shí)運(yùn)行狀況，幫助我們發(fā)現(xiàn)問(wèn)題、故障甄別和確認(rèn)恢復(fù)。這是最重要的事情。
舉個(gè)例子
廢話(huà)少敘，先來(lái)張以前的圖看個(gè)大概：
此圖是我們業(yè)務(wù)系統(tǒng)metrics的一個(gè)例子，顯示了我們前置nginx的部分metrics，通過(guò)實(shí)時(shí)的分析nginx log，我們可以得到所有機(jī)房nginx在吞吐量、延時(shí)、負(fù)載分配、流量等等多方面的實(shí)時(shí)信息，一目了然；還可以根據(jù)不同維度進(jìn)行分析比較，幫我們有效的找到各種異常情況(圖里就有一個(gè)小缺口)。類(lèi)似的metrics，我們目前已經(jīng)有幾百個(gè)，通過(guò)不同的面板組織起來(lái)，并且還在不斷的增加。目前，公司的原則是每個(gè)項(xiàng)目在開(kāi)發(fā)之前，就需要盡可能多的定義出相應(yīng)的metrics，做好詳盡的監(jiān)控。
技術(shù)選型
眼尖的同學(xué)會(huì)發(fā)現(xiàn)我們用了開(kāi)源組件grafana。事實(shí)上，我們?cè)趍etrics存儲(chǔ)上采用的就是influxdb/redis+grafana的組合：
1.在我們的SaaS后臺(tái)，采用influxdb+grafana 2.0(2.0有單獨(dú)的后臺(tái)服務(wù))的組合，存儲(chǔ)了海量的metrics，同時(shí)滿(mǎn)足大量數(shù)據(jù)的寫(xiě)入，以及監(jiān)控報(bào)警系統(tǒng)的頻繁讀取，同時(shí)保留橫向擴(kuò)展的可能性。
2.在我們的測(cè)試環(huán)境/私有化部署環(huán)境，采用redis+grafana 1.9的組合，這個(gè)組合部署簡(jiǎn)單，開(kāi)銷(xiāo)相對(duì)較小，可以滿(mǎn)足少量的metrics使用。實(shí)現(xiàn)上，我們根據(jù)influxdb的存儲(chǔ)結(jié)構(gòu)在redis上復(fù)刻了一份，并且通過(guò)proxy來(lái)模擬influxdb的接口。
3.實(shí)現(xiàn)方式上，我們提供了Python/Java兩個(gè)庫(kù)，并通過(guò)配置文件來(lái)作redis/influxdb的無(wú)縫切換。每個(gè)應(yīng)用根據(jù)自己的需求來(lái)決定配置，并調(diào)用api將metrics信息記錄到合適的地方；同時(shí)框架自身也做了一些組件專(zhuān)門(mén)用來(lái)收集系統(tǒng)層面的metrics(比如上面的例子就是通過(guò)syslog服務(wù)來(lái)接受nginx日志，并做實(shí)時(shí)的metrics統(tǒng)計(jì))。
得出這樣的架構(gòu)選型，我們當(dāng)初也是傷透了腦筋：
1.前公司用的是類(lèi)opentsdb的系統(tǒng)，在使用便捷性和性能上沒(méi)的說(shuō)，但后端強(qiáng)依賴(lài)于hbase，對(duì)于我們并不合適。
2.當(dāng)時(shí)也看了其他針對(duì)這種Time-series data的開(kāi)源方案，目前其實(shí)沒(méi)有什么特別好的方案。
3.最終我們還是選了influxdb做為主力，這是一個(gè)相對(duì)輕量的開(kāi)源時(shí)間序列數(shù)據(jù)庫(kù)，很適合于做為metrics使用：它有類(lèi)似SQL的查詢(xún)語(yǔ)句比較容易上手；自帶簡(jiǎn)易管理界面；可以用grafana作為前端看板；還有各個(gè)語(yǔ)言的客戶(hù)端支持；***，它最近還是比較火。
4.選redis的原因在于：私有環(huán)境下需要一個(gè)簡(jiǎn)單的方案；比較熟悉，當(dāng)influxdb碰到問(wèn)題時(shí)，redis版可以作為備胎頂上。
5.最初我們也考慮過(guò)用elasticsearch這個(gè)大殺器來(lái)做metrics使用，然而：
?。?）es 是重讀輕寫(xiě)。由于是搜索引擎的出身，它強(qiáng)調(diào)索引。你寫(xiě)一條記錄，還伴隨著大量的索引工作，有人做過(guò)實(shí)驗(yàn)，es和influxdb之間在存儲(chǔ)上是10x的關(guān)系。所以es注定寫(xiě)性能不是強(qiáng)項(xiàng)(就單機(jī)而言)，而且索引的建立必然帶來(lái)延時(shí)和復(fù)雜性。當(dāng)然有了索引，在做一些過(guò)濾和聚合的時(shí)候，搜索引擎的優(yōu)勢(shì)就發(fā)揮出來(lái)了，能出更多的報(bào)表，也能支持長(zhǎng)時(shí)間的查詢(xún)。
?。?）influxdb是面向時(shí)間序列的數(shù)據(jù)庫(kù)，這一類(lèi)數(shù)據(jù)的特征是數(shù)據(jù)量大，寫(xiě)入壓力高，所以influxdb在索引上沒(méi)有側(cè)重，保證了大量數(shù)據(jù)的快速存儲(chǔ)；缺陷在于，沒(méi)有索引，每次查詢(xún)需要過(guò)濾全量數(shù)據(jù)，但是基本上能保證讀到***數(shù)據(jù)(沒(méi)有延遲索引的影響)。所以，influxdb是輕讀重寫(xiě)。
?。?）我們的metrics主要是監(jiān)控當(dāng)前狀況，偶爾會(huì)回溯一下歷史，同時(shí)這些數(shù)據(jù)會(huì)被實(shí)時(shí)報(bào)警系統(tǒng)使用，要求響應(yīng)比較快。從使用場(chǎng)景和成本的角度，我們最終選擇了influxdb做為metrics的存儲(chǔ)，elasticsearch單做BI工具使用。
metrics監(jiān)控架構(gòu)
此圖概括描述了我們的監(jiān)控結(jié)構(gòu)。
1.Python和Java程序通過(guò)metrics庫(kù)將相應(yīng)的數(shù)據(jù)打到指定的地方。
（1）程序里用到的框架組件(如rpc，分布式log等)會(huì)由組件自身進(jìn)行打點(diǎn)，方便框架層面的統(tǒng)一監(jiān)控排錯(cuò)。
?。?）程序里的業(yè)務(wù)metrics需要由工程師手動(dòng)打點(diǎn)，來(lái)記錄每個(gè)業(yè)務(wù)和程序模塊的特殊運(yùn)行狀況。
?。?）為了保證后端metrics數(shù)據(jù)寫(xiě)入的穩(wěn)定性，我們?cè)赾lient段做了部分聚合操作，減少打點(diǎn)數(shù)據(jù)。
‘ * redis和influxdb做成驅(qū)動(dòng)形式，通過(guò)配置來(lái)指定，開(kāi)發(fā)人員不需要關(guān)心具體的實(shí)現(xiàn)。
2.通過(guò)jmx，我們來(lái)獲得系統(tǒng)數(shù)據(jù)，并打入到metrics系統(tǒng)，來(lái)查看各個(gè)機(jī)器的物理狀況(感謝前同事wxc的jmx庫(kù))。
3.建立syslog服務(wù)，對(duì)nginx日志進(jìn)行統(tǒng)計(jì)分析，可以得到網(wǎng)站訪(fǎng)問(wèn)的各種統(tǒng)計(jì)信息。
4.對(duì)于外網(wǎng)延遲等其他數(shù)據(jù)，也可以用相應(yīng)的agent來(lái)打入到metrics系統(tǒng)。
5.由于我們的架構(gòu)是跨數(shù)據(jù)中心的統(tǒng)一架構(gòu)，還需要接收各個(gè)分機(jī)房的數(shù)據(jù)，我們通過(guò)在每個(gè)機(jī)房建立proxy來(lái)接收數(shù)據(jù)，并由自研的跨數(shù)據(jù)中心的rpc服務(wù)來(lái)進(jìn)行數(shù)據(jù)傳遞。這樣，在主機(jī)房的報(bào)表中能看到全國(guó)的系統(tǒng)運(yùn)行狀況。
6.對(duì)于線(xiàn)上的大型系統(tǒng)，我們采用grafana 2.0直連來(lái)進(jìn)行數(shù)據(jù)展示，歷史數(shù)據(jù)通過(guò)proxy來(lái)完成。
7.對(duì)于私有部署環(huán)境和測(cè)試環(huán)境，我們將數(shù)據(jù)記入redis版的tsdb，通過(guò)proxy來(lái)提供influxdb接口，來(lái)無(wú)縫的接入到grafana 1.9(比較輕量，可以嵌入web應(yīng)用)之中。
其他監(jiān)控工具
上文描述的metrics系統(tǒng)解決了我們大部分的問(wèn)題，是我們監(jiān)控系統(tǒng)的主要成分。同時(shí)，我們還使用了一些其他零散的手段：
1.uptime。Uptime是一個(gè)開(kāi)源項(xiàng)目，通過(guò)獲取網(wǎng)頁(yè)的心跳數(shù)據(jù)來(lái)檢測(cè)網(wǎng)頁(yè)的可用性。如圖：
2.系統(tǒng)資源(CPU、內(nèi)存、硬盤(pán))監(jiān)控。系統(tǒng)監(jiān)控工具很多，一開(kāi)始我們使用的是collectd這個(gè)傳統(tǒng)的工具；后來(lái)出于定制化、統(tǒng)一化、練兵的需要，我們改成自己寫(xiě)Java程序，通過(guò)jmx來(lái)獲取相關(guān)數(shù)據(jù)，并打入到metrics系。collectd就停止使用了。
3.腳本和外部工具。在遇到特殊需求，通用的系統(tǒng)無(wú)法滿(mǎn)足的時(shí)候，我們也會(huì)通過(guò)寫(xiě)shell腳本來(lái)做一些工作，這種方式在開(kāi)發(fā)效率和功能上都比較棒，只是不能很好的和其他數(shù)據(jù)集成；同時(shí)，目前互聯(lián)網(wǎng)上也有不少監(jiān)控服務(wù)，我們也用了一些，來(lái)作為自身監(jiān)控系統(tǒng)的補(bǔ)足和備胎。
二次開(kāi)發(fā)
因?yàn)橹饕柚陂_(kāi)源系統(tǒng)，所以有時(shí)候需要進(jìn)行一些二次開(kāi)發(fā)來(lái)滿(mǎn)足公司的定制化需求。這里舉一些比較有用的例子：
1.grafana默認(rèn)的分組顯示(group by)只支持一個(gè)tag，這種使用場(chǎng)景比較有限。為了讓其能支持多個(gè)版本，我們?cè)趦蓚€(gè)版本上都修改了它的前端JS代碼，如下圖所示，修改后的版本可以顯示多個(gè)tag組合的數(shù)據(jù)情況(這里是我們的rpc統(tǒng)計(jì)中，所有服務(wù)的延時(shí)范圍統(tǒng)計(jì))。
2.grafana不支持聚合嵌套，所以像distinct count這樣的功能無(wú)法實(shí)現(xiàn)，這個(gè)也通過(guò)修改前端代碼解決。
3.grafana可以建多個(gè)metrics進(jìn)行比較查看，但永遠(yuǎn)顯示的都是***的數(shù)據(jù)，不方便做同環(huán)比比較。我們通過(guò)proxy來(lái)返回一段時(shí)間前的數(shù)據(jù)，來(lái)達(dá)到這個(gè)目的。
4.Uptime檢測(cè)https的網(wǎng)頁(yè)會(huì)有證書(shū)錯(cuò)誤的問(wèn)題，需要手動(dòng)在代碼里禁用相應(yīng)的環(huán)境變量。
接著，談報(bào)警
光有監(jiān)控是不夠的，因?yàn)檫@么多的數(shù)據(jù)和報(bào)表，無(wú)法通過(guò)人肉的方式跟蹤，所以在收集到這么多數(shù)據(jù)之后，需要有自動(dòng)化的報(bào)警系統(tǒng)來(lái)進(jìn)行進(jìn)一步的分析和處理。為此，我們基于收集到的海量數(shù)據(jù)，開(kāi)發(fā)了一個(gè)輕量級(jí)的報(bào)警系統(tǒng)，包括報(bào)警系統(tǒng)的完整架構(gòu)如下圖所示：
這套系統(tǒng)主要由DataSource，Drivers，Rules，Actions等幾部分組成：
1.DataSource和相應(yīng)的Driver對(duì)應(yīng)了不同的監(jiān)控?cái)?shù)據(jù)來(lái)源。
2.rules表示我們的一些報(bào)警規(guī)則。
3.actions是規(guī)則***后的觸發(fā)動(dòng)作。
DataSource和Driver
data source表示不同的數(shù)據(jù)來(lái)源，每種數(shù)據(jù)來(lái)源都由相應(yīng)的driver來(lái)獲取，并抽象成統(tǒng)一的數(shù)據(jù)格式(我們采用了類(lèi)時(shí)間序列的格式)，這樣可以把數(shù)據(jù)抽取系統(tǒng)和規(guī)則引擎完全解耦，減少開(kāi)發(fā)復(fù)雜度。目前，我們的datasource，包括：
1.tsdb中的metrics數(shù)據(jù)。
2.這是最主要的數(shù)據(jù)來(lái)源，通過(guò)獲取存儲(chǔ)在redis/influxdb中的metrics數(shù)據(jù)，我們可以對(duì)海量的監(jiān)控指標(biāo)進(jìn)行詳盡的分析。
3.grafana面板可以生成influxdb dsl，我們的報(bào)警系統(tǒng)直接支持利用此DSL進(jìn)行報(bào)警，這樣使用者在grafana面板上配置好監(jiān)控項(xiàng)后，可以很方便的進(jìn)行相應(yīng)的報(bào)警。
4.通過(guò)上文描述的metrics proxy可以獲取metrics的歷史數(shù)據(jù)，方便做同環(huán)比檢測(cè)。
5.uptime的數(shù)據(jù)。uptime可以對(duì)各個(gè)url進(jìn)行監(jiān)控，通過(guò)獲取其數(shù)據(jù)可以進(jìn)行網(wǎng)站存活性報(bào)警。
6.其他數(shù)據(jù)。還有其他類(lèi)型的數(shù)據(jù)，比如collectd等，也可以方便的集成到報(bào)警系統(tǒng)中來(lái)。
Rules
從各種data source定期的獲得統(tǒng)一格式的監(jiān)控?cái)?shù)據(jù)后，下一步就是通過(guò)報(bào)警規(guī)則進(jìn)行數(shù)據(jù)檢查了，來(lái)驗(yàn)證數(shù)據(jù)是否超出了預(yù)設(shè)的閥值。報(bào)警規(guī)則向來(lái)是個(gè)復(fù)雜的問(wèn)題，需要滿(mǎn)足各種各樣的需求。為此，我們?cè)陂_(kāi)發(fā)規(guī)則引擎時(shí)，比較重視減少開(kāi)發(fā)的復(fù)雜程度。目前我們的規(guī)則，有以下兩類(lèi)：
1.單數(shù)據(jù)源簡(jiǎn)單規(guī)則。簡(jiǎn)單規(guī)則通過(guò)對(duì)每次***的監(jiān)控?cái)?shù)據(jù)進(jìn)行閾值比較，來(lái)獲得報(bào)警。比如：
?。?）上下限閾值比較。這種是最簡(jiǎn)單的，定義好上限和下限，就可以發(fā)現(xiàn)異常值。
（2）數(shù)據(jù)存活性比較。當(dāng)發(fā)現(xiàn)某一監(jiān)控項(xiàng)的數(shù)據(jù)存在(或消失)時(shí)，即報(bào)警，用來(lái)檢查錯(cuò)誤指標(biāo)(或存活指標(biāo))。
2.單數(shù)據(jù)源組合規(guī)則。簡(jiǎn)單規(guī)則產(chǎn)生的報(bào)警有可能非常多，我們可以通過(guò)對(duì)簡(jiǎn)單規(guī)則產(chǎn)生的結(jié)果進(jìn)行進(jìn)一步的處理，來(lái)減少報(bào)警量。比如：
（1）多次報(bào)警。當(dāng)簡(jiǎn)單規(guī)則觸發(fā)的內(nèi)部報(bào)警在一段時(shí)間內(nèi)超過(guò)一定的次數(shù)時(shí)，才進(jìn)行真正的報(bào)警。
?。?）報(bào)警cooldown。當(dāng)同一報(bào)警不停出現(xiàn)時(shí)，此規(guī)則會(huì)進(jìn)行相應(yīng)的抑制。
?。?）斷崖式報(bào)警。當(dāng)監(jiān)控?cái)?shù)據(jù)出現(xiàn)斷崖式特征時(shí)，才進(jìn)行報(bào)警。
3.多數(shù)據(jù)源組合規(guī)則。有時(shí)候，單一的數(shù)據(jù)源還不夠，需要對(duì)多個(gè)數(shù)據(jù)源進(jìn)行計(jì)算后獲得。比如：
（1）同環(huán)比報(bào)警。對(duì)同一監(jiān)控項(xiàng)可以拉取不同時(shí)間段的兩條數(shù)據(jù)，就可以進(jìn)行相應(yīng)的報(bào)警。
?。?）組合運(yùn)算報(bào)警。比如說(shuō)nginx 2xx狀態(tài)比例的監(jiān)控，可以通過(guò)對(duì)2xx次數(shù)和總訪(fǎng)問(wèn)次數(shù)的計(jì)算來(lái)獲取。
這里只是舉例描述了一些規(guī)則類(lèi)型，實(shí)際系統(tǒng)中會(huì)有更多的類(lèi)型。
Actions
在獲得報(bào)警數(shù)據(jù)后，需要促發(fā)一些行為，來(lái)完成整個(gè)自動(dòng)化。
1.最常用的報(bào)警動(dòng)作就是發(fā)郵件了，通過(guò)對(duì)每一類(lèi)報(bào)警制定不同的監(jiān)控人，可以使相關(guān)人員***時(shí)間獲悉系統(tǒng)異常。
2.微信報(bào)警，郵件的補(bǔ)充。
3.規(guī)則引擎產(chǎn)生的數(shù)據(jù)可以進(jìn)一步寫(xiě)回metrics系統(tǒng)，作第二輪的監(jiān)控報(bào)警。比如前文描述的2xx比例(類(lèi)似的還有各種比例等)。在這種情況下，報(bào)警系統(tǒng)相當(dāng)于一個(gè)定時(shí)的自動(dòng)化引擎，來(lái)做一些定期的數(shù)據(jù)處理，方便我們做更好的監(jiān)控和報(bào)表。實(shí)際上，這個(gè)規(guī)則引擎會(huì)成為我們后期自動(dòng)化任務(wù)引擎的基礎(chǔ)。
有了這套系統(tǒng)，目前我們的運(yùn)營(yíng)監(jiān)控基本實(shí)現(xiàn)了自動(dòng)化。系統(tǒng)故障時(shí)會(huì)有相應(yīng)的報(bào)警郵件來(lái)通知，這樣開(kāi)發(fā)人員可以集中精力在新功能的研發(fā)上。
數(shù)字化運(yùn)營(yíng)
實(shí)際上，整套報(bào)警監(jiān)控系統(tǒng)不但幫助我們?nèi)ゾS護(hù)網(wǎng)站/系統(tǒng)的穩(wěn)定性，提高自動(dòng)化程度，還能提升我們的數(shù)字化運(yùn)營(yíng)能力，***限度的提升整個(gè)公司的效率。
1.簡(jiǎn)單報(bào)表。grafana這種可視化工具可以解決大部分初期的報(bào)表需求，免掉了初期BI人員的投入。
2.定期報(bào)表。我們利用報(bào)警系統(tǒng)，做了簡(jiǎn)單的修改，可以對(duì)一些監(jiān)控項(xiàng)，在每天凌晨進(jìn)行強(qiáng)制報(bào)警(數(shù)據(jù)采集選取1天，報(bào)警顯示詳細(xì)數(shù)據(jù))，這樣每天早晨都可以收到過(guò)去一天的統(tǒng)計(jì)報(bào)表。由于復(fù)用了現(xiàn)有的系統(tǒng)，省掉了相關(guān)報(bào)表功能的開(kāi)發(fā)。
小結(jié)
本文是我們?cè)谶^(guò)去的大半年中，在監(jiān)控報(bào)警上做的一些實(shí)踐探索。事實(shí)上，在后面的日子里，還需要進(jìn)行更多、更復(fù)雜的工作：
1.接收其他來(lái)源的數(shù)據(jù)，同時(shí)大力完善公司內(nèi)部的監(jiān)控體系。
2.完善分布式log機(jī)制，方便排障和更細(xì)粒度的監(jiān)控。
3.將報(bào)警監(jiān)控系統(tǒng)和生產(chǎn)的業(yè)務(wù)發(fā)布系統(tǒng)打通，來(lái)實(shí)現(xiàn)彈性擴(kuò)容和自動(dòng)容災(zāi)的可能性。
關(guān)于作者
呂夢(mèng)琪，上海豈安信息科技公司bigsec框架研發(fā)負(fù)責(zé)人，主導(dǎo)底層框架系統(tǒng)和Java服務(wù)端的研發(fā)工作。她擅長(zhǎng)Java研發(fā)、分布式系統(tǒng)、監(jiān)控系統(tǒng)以及各類(lèi)開(kāi)源項(xiàng)目的引入和改造。
