圖7：ELK on Mesos
上圖7是ELK on Mesos結(jié)構(gòu)圖，也是團(tuán)隊(duì)的無(wú)奈之選。因?yàn)镸esos還暫時(shí)不支持multi-role framework功能，所以選擇了這種折中的方式來(lái)做。在一個(gè)Marathon里，根據(jù)業(yè)務(wù)線設(shè)置好Quota后，用業(yè)務(wù)線重新發(fā)一個(gè)新的Marathon接入進(jìn)去。對(duì)于多租戶來(lái)講，可以利用Kubernetes做后續(xù)的資源管控和資源申請(qǐng)。
部署ES以后，有一個(gè)關(guān)于服務(wù)發(fā)現(xiàn)的問(wèn)題，可以去注冊(cè)一個(gè)callback，Marathon會(huì)返回信息，解析出master/slave進(jìn)程所在的機(jī)器和端口，配合修改Haproxy做一層轉(zhuǎn)發(fā)，相當(dāng)于把后端整個(gè)TCP的連接都做一個(gè)通路。ES跟Spark不完全相同，Spark傳輸本身流量就比較大，而ES啟動(dòng)時(shí)需要主動(dòng)聯(lián)系Master地址，再通過(guò)Master獲取相應(yīng)集群，后面再做P2P，流量比較低，也不是一個(gè)長(zhǎng)鏈接。
監(jiān)控與運(yùn)維
這部分包括了Streaming監(jiān)控指標(biāo)與報(bào)警、容器監(jiān)控指標(biāo)與報(bào)警兩方面。
Streaming監(jiān)控指標(biāo)與報(bào)警
Streaming監(jiān)控含拓?fù)浔O(jiān)控和業(yè)務(wù)監(jiān)控兩部分。
1.Streaming拓?fù)浔O(jiān)控
2.業(yè)務(wù)監(jiān)控
（1）Kafka Topic Lag
（2）處理延遲mean90/upper90
（3）Spark scheduler delay/process delay
（4）Search Count/Message Count
（5）Reject/Exception
（6）JVM
拓?fù)浔O(jiān)控包括數(shù)據(jù)源和整個(gè)拓?fù)淞鞒?，需要用戶自己去整理和?gòu)建，更新的時(shí)候就能夠知道這個(gè)東西依賴誰(shuí)、是否依賴線上服務(wù)，如果中途停的話會(huì)造成機(jī)器故障。業(yè)務(wù)監(jiān)控的話，第一個(gè)就是Topic Lag，Topic Lag每一個(gè)波動(dòng)都是不一樣的，用這種方式監(jiān)控會(huì)頻繁報(bào)警，90%的中位數(shù)都是落在80—100毫秒范圍內(nèi)，就可以監(jiān)控到整個(gè)范圍。
容器監(jiān)控指標(biāo)與報(bào)警
容器監(jiān)控上關(guān)注以下三方面：
1.Google cAdvisor足夠有效
mount rootfs可能導(dǎo)致容器刪除失敗 #771
–docker_only
–docker_env_metadata_whitelist
2.Statsd + Watcher
基于Graphite的千萬(wàn)級(jí)指標(biāo)監(jiān)控平臺(tái)
3.Nagios
容器這一塊比較簡(jiǎn)單，利用Docker并配合Mesos，再把Marathon的ID抓取出來(lái)就可以了。我們這邊在實(shí)踐的過(guò)程發(fā)現(xiàn)一個(gè)問(wèn)題，因?yàn)镾tatsd Watcher容易出現(xiàn)問(wèn)題，你直接用Docker的時(shí)候它會(huì)報(bào)一些錯(cuò)誤出來(lái)，這個(gè)問(wèn)題就是Statsd Watcher把路徑給掛了的原因。目前我們平臺(tái)就曾遇到過(guò)一次，社區(qū)里面也有人曝，不過(guò)復(fù)現(xiàn)率比較低。用的時(shí)候如果發(fā)現(xiàn)這個(gè)問(wèn)題把Statsd Watcher直接停掉就好。指標(biāo)的話，每臺(tái)機(jī)器上放一個(gè)statsd再發(fā)一個(gè)后臺(tái)的Worker，報(bào)警平臺(tái)也是這個(gè)。
其實(shí)針對(duì)Docker監(jiān)控的話，還是存在著一些問(wèn)題：
1.基礎(chǔ)監(jiān)控壓力
（1）數(shù)據(jù)膨脹
（2）垃圾指標(biāo)增多
（3）大量的通配符導(dǎo)致數(shù)據(jù)庫(kù)壓力較高
2.單個(gè)任務(wù)的容器生命周期
(1）發(fā)布
(2)擴(kuò)容
(3)異常退出
首先主要是監(jiān)控系統(tǒng)壓力比較大。原來(lái)監(jiān)控虛擬機(jī)時(shí)都是針對(duì)每一個(gè)虛擬機(jī)的，只要虛擬機(jī)不刪的話是長(zhǎng)期匯報(bào)，指標(biāo)名固定，但在容器中這個(gè)東西一直在變，它在這套體系下用指標(biāo)并在本地之外建一個(gè)目錄存文件，所以在這種存儲(chǔ)機(jī)制下去存容器的指標(biāo)不合適。主要問(wèn)題是數(shù)據(jù)膨脹比較厲害，可能一個(gè)容器會(huì)起名，起名多次之后，在Graphite那邊對(duì)應(yīng)了有十多個(gè)指標(biāo)，像這種都是預(yù)生成的監(jiān)控文件。比如說(shuō)定義每一秒鐘一個(gè)數(shù)據(jù)點(diǎn)，要保存一年，這個(gè)時(shí)候它就會(huì)根據(jù)每年有多少秒生成一個(gè)RRD文件放那兒。這部分指標(biāo)如果按照現(xiàn)有標(biāo)準(zhǔn)的話，可能容器的生命周期僅有幾天時(shí)間，不適用這種機(jī)制。測(cè)試相同的指標(biāo)量，公司存儲(chǔ)的方式相對(duì)來(lái)說(shuō)比Graphite好一點(diǎn)。因?yàn)镚raphite是基于文件系統(tǒng)來(lái)做的，第一個(gè)優(yōu)化指標(biāo)名，目錄要轉(zhuǎn)存到數(shù)據(jù)庫(kù)里做一些索引加速和查詢，但是因?yàn)槿萜鬟@邊相對(duì)通配符比較多，不能直接得知具體對(duì)應(yīng)的ID，只能通配符查詢做聚合。因?yàn)殚L(zhǎng)期的通配符在字符串的索引上還是易于使用的，所以現(xiàn)在算是折中的做法，把一些常用的查詢結(jié)果、目錄放到里邊。
另一個(gè)是容器的生命周期?？梢宰鲆恍徲?jì)或者變更的版本，在Mesos層面基于Marathon去監(jiān)控，發(fā)現(xiàn)這些狀態(tài)后打上標(biāo)記：當(dāng)前是哪一個(gè)容器或者哪一個(gè)TASK出了問(wèn)題，對(duì)應(yīng)擴(kuò)容和記錄下來(lái)。還有Docker自己的問(wèn)題，這樣后面做整個(gè)記錄時(shí)會(huì)有一份相對(duì)比較完整的TASK-ID。
作者簡(jiǎn)介：徐磊，去哪兒網(wǎng)平臺(tái)事業(yè)部運(yùn)維開發(fā)工程師。