Spotify是全球最大的正版流媒體音樂服務(wù)平臺。Spotify提供的服務(wù)需要一個(gè)巨大的基礎(chǔ)設(shè)施平臺作為支撐,，而監(jiān)控這個(gè)平臺的運(yùn)行顯得至關(guān)重要,。Spotify實(shí)驗(yàn)室的John-John Tedro近日對Spotify的監(jiān)控進(jìn)行了一個(gè)簡單的介紹。

Spotify的運(yùn)行監(jiān)控一開始是作為兩個(gè)系統(tǒng)的組合,，即Zabbix和sitemon,，其中sitemon是一個(gè)支持RRD的土生土長的圖形系統(tǒng)，它采用Munin用來進(jìn)行數(shù)據(jù)收集,。 Zabbix的所有權(quán)屬于我們的SRE團(tuán)隊(duì),，而sitemon由我們的后端基礎(chǔ)架構(gòu)團(tuán)隊(duì)負(fù)責(zé)運(yùn)行。當(dāng)時(shí),，我們的團(tuán)隊(duì)很小,，身邊的很多問題常常都是由自己親手解決。我們采取了這種方案的原因更多的是因?yàn)槲覀冞x擇這個(gè)問題,。

從2013年年底起,，我們開始把更多的注意力放在自助服務(wù)和分布式運(yùn)行監(jiān)測上。我們想停止監(jiān)控單個(gè)主機(jī),，并開始將服務(wù)作為一個(gè)整體考慮,。Zabbix并不適合，因?yàn)樗饕P(guān)注單個(gè)主機(jī),。唯一可以操作它的是SRE團(tuán)隊(duì)的成員,。隨著整個(gè)基礎(chǔ)設(shè)施變得越來越龐大,，我們的系統(tǒng)在強(qiáng)大的負(fù)載壓力下開始產(chǎn)生裂痕。

我們也在試圖盡力將目前的工作做一些改進(jìn)：基于內(nèi)存的sitemon方案僅僅能在當(dāng)前負(fù)載壓力下保存大約1個(gè)月的指標(biāo)數(shù)據(jù),，從而我們的首席架構(gòu)師提出了一種新的替代方案,。在這種方案下，雖然我們還有一些喘息的空間,，但我們估計(jì)我們最多只能持續(xù)一年,。出于這樣的體驗(yàn)，Spotify組建了一個(gè)新的團(tuán)隊(duì)：Hero,。他們的目標(biāo)是改進(jìn)Spotify的監(jiān)控,，并為未來做好準(zhǔn)備。不惜一切代價(jià),。下面是他們采取的主要做法,。

報(bào)警是我們需要攻克的第一個(gè)問題。

我們考慮進(jìn)一步發(fā)展Zabbix,。它使用觸發(fā)器表達(dá)式來檢查報(bào)警條件,。我們在系統(tǒng)中觀測到大量位衰減，許多正在運(yùn)行的觸發(fā)器很難理解,、已經(jīng)損壞或無效,。這就引出了我們?yōu)橄乱淮瘓?bào)系統(tǒng)所提出的其中一個(gè)要求：它必須使得對觸發(fā)器的測試變得簡單，以使其容易理解,。Zabbix的可擴(kuò)展性也是一個(gè)問題,。在接下來兩年中，我們不相信我們的系統(tǒng)可以在我們預(yù)期的規(guī)模上運(yùn)行,。

在參加Monitorama EU時(shí),，我們偶然發(fā)現(xiàn)了Riemann。一個(gè)分布式監(jiān)控系統(tǒng)解決方案,。Riemann并沒有提供不確定情況下的可擴(kuò)展性,，但對于無狀態(tài)規(guī)則的偏愛很容易地讓它可以對負(fù)載進(jìn)行劃分和分配。我們?yōu)橐粋€(gè)服務(wù)中的每個(gè)主機(jī)配對至少兩個(gè)實(shí)例,，這些實(shí)例運(yùn)行了相同的規(guī)則集,。

我們在Riemann之上建立了一個(gè)庫，稱為Lyceum,。這使我們能夠建立一個(gè)git倉庫,，倉庫內(nèi)部，每一個(gè)方格可以將它們的規(guī)則放入一個(gè)隔離的命名空間中,。使用這個(gè)配置，我們的工程師可以定義可重復(fù)的集成測試,。它使得任何人可以打開repo,，并可以在產(chǎn)品中直接部署這些變更。我們的立場發(fā)生了改變，如果測試通過,，我們便知道它的工作原理,。這被證明是非常成功的。Clojure是一門遠(yuǎn)遠(yuǎn)比觸發(fā)器表達(dá)式更易于理解的語言,，基于git的審查過程更適合我們的開發(fā)方法,。

在這個(gè)方面，我們折騰了好幾次,。我們初始的堆棧是基于Munin的,，其中的插件對應(yīng)著收集到的所有東西。一些指標(biāo)是標(biāo)準(zhǔn)的,，但最重要的那些是服務(wù)指標(biāo),。

切換到基于push的方式來降低我們選用工程師的門檻，是值得期待的,。使用Munin的經(jīng)歷告訴我們,，復(fù)雜的定義指標(biāo)的過程會延緩最后指標(biāo)的采納?；赑ull的方法需要配置讀出什么,，以及從哪里讀出。而用Push的方法,，你會忘記在最近的API中的樣本,，最好使用一個(gè)共同的協(xié)議?？紤]一個(gè)短暫的任務(wù),，其中可能沒有足夠的時(shí)間被收集器發(fā)現(xiàn)。但對于Push來說,，這并不是問題,，因?yàn)槭侨蝿?wù)本身控制了度量的發(fā)送。

如果您想了解更多,，sFlow和Alan Giles針對這個(gè)問題進(jìn)行了更深入的分析,。

我們最初的實(shí)驗(yàn)中，部署了一個(gè)基于collected和Graphite的通用解決方案來積累經(jīng)驗(yàn),。分析性能測試的結(jié)果,，我們感覺對這種垂直的可擴(kuò)展性并不滿意，我們不想只有一個(gè)Graphite節(jié)點(diǎn),。

whisper寫入模式涉及到跨眾多文件的隨機(jī)搜尋和寫入,。文件搜索過程中的向下采樣，存在一個(gè)很高的成本,。

分片和再平衡Graphite存在的困難也經(jīng)常讓人望而卻步,。其中的一些可能最近通過使用后端支持的Cyanite已經(jīng)得到了解決,。但對我們來說，Graphite仍然遭受了一個(gè)重大的理論障礙：分層命名,。

Graphite中一個(gè)典型的時(shí)間序列按照類似下面這種方式命名：

確切的形式分情況不同,，但是這可以被視為一個(gè)固定的層次結(jié)構(gòu)。在一些情況下這種方式工作得很好,，因?yàn)樗鼈儽举|(zhì)上就是層次結(jié)構(gòu),。但是，如果我們想在一個(gè)特定的網(wǎng)站選擇所有服務(wù)器,。我們有兩個(gè)選擇：我們希望服務(wù)器名稱在不同的基礎(chǔ)架構(gòu)中保持一致,，并執(zhí)行通配符匹配；或者為了解決這個(gè)問題,，我們可以對命名層次結(jié)構(gòu)進(jìn)行重新洗牌：

這種類型的重構(gòu)是很難的,。

沒有正確的答案。一個(gè)團(tuán)隊(duì)可能要求將網(wǎng)站作為篩選的主要手段,，也可能希望將角色作為篩選的主要手段,。這兩個(gè)要求具有相同的優(yōu)點(diǎn)。因此,，弱點(diǎn)也都在于命名方案,。

在解決這個(gè)問題中有一個(gè)完全不同的方式，即考慮將一個(gè)時(shí)間序列的標(biāo)志符由一組標(biāo)簽組成,。

 看看我們前面的例子,，我們將現(xiàn)有層次結(jié)構(gòu)映射到一組標(biāo)簽。

通過一個(gè)過濾系統(tǒng),，其能夠讓工程師將內(nèi)部組件相互連接的一大片時(shí)間序列進(jìn)行拆分。提高了互操作性,。

這樣一來,，這就沒有了我們必須嚴(yán)格遵守的層次結(jié)構(gòu)。按照慣例,，他們可能是結(jié)構(gòu)的一部分（“網(wǎng)站”和“主機(jī)”總是存在）,，但它們既沒有被要求，也不是嚴(yán)格有序的,。

Atlas,、Prometheus、 OpenTSDB,、InfluxDB和KairosDB都是使用標(biāo)簽的數(shù)據(jù)庫,。 Atlas和Prometheus被認(rèn)真考慮過，但在時(shí)間上并不可用,。我們最終并沒有選擇OpenTSDB,，因?yàn)樵谑褂肏Base時(shí)的糟糕的運(yùn)行體驗(yàn),。InfluxDB不成熟,，因?yàn)樗狈ψ灾?wù)的功能,，而這正是我們需要推出的。KairosDB似乎像最好的選擇,，所以我們進(jìn)行了廣泛的試驗(yàn),。但發(fā)現(xiàn)它在性能和穩(wěn)定性上存在問題，我們試圖做一些努力,，但均告失敗,。我們認(rèn)為該項(xiàng)目由于缺乏社區(qū)的參與，并沒有朝著我們期待的方向前進(jìn),。

受KairosDB的啟發(fā),，我們開始了一個(gè)新的項(xiàng)目。我們針對這個(gè)項(xiàng)目做了一些小的實(shí)踐,，并取得了可喜的成果,，所以我們堅(jiān)持下來了，并給它取了一個(gè)名字,；Heroic,。

作為該系列文章的下半部分，本文介紹了免費(fèi),、可擴(kuò)展的時(shí)間序列數(shù)據(jù)庫——Heroic,。

Heroic是Spotify公司內(nèi)部使用的時(shí)間序列數(shù)據(jù)庫。在大規(guī)模搜集和呈現(xiàn)近實(shí)時(shí)數(shù)據(jù)時(shí),，Spotify公司曾面臨著巨大挑戰(zhàn),。Heroic就是該公司用來應(yīng)對這些挑戰(zhàn)的工具。其內(nèi)部包含了兩個(gè)核心技術(shù)——Cassandra和Elasticsearch,。其中,，Cassandra負(fù)責(zé)存儲，而Elasticsearch負(fù)責(zé)索引所有的數(shù)據(jù),。Spotify公司目前使用分布在全球各地的集群所運(yùn)行的,、超過200個(gè)的Cassandra節(jié)點(diǎn)，來服務(wù)超過五千萬的時(shí)間序列,。

作為一個(gè)商業(yè)公司的團(tuán)隊(duì),，他們清楚知道Elasticsearch在數(shù)據(jù)安全方面一直表現(xiàn)不好，因此采取了應(yīng)對措施——在系統(tǒng)發(fā)生故障后,，公司可以從數(shù)據(jù)流水線或Cassandra中迅速重建索引,。

Heroic的關(guān)鍵特性就是全球聯(lián)合。不同的集群可以相互獨(dú)立運(yùn)行,，而且可以把請求轉(zhuǎn)移到其他集群來形成一個(gè)全球的接口,。一個(gè)地區(qū)節(jié)點(diǎn)的失效只會造成該地區(qū)的數(shù)據(jù)無法訪問,，而不影響其他節(jié)點(diǎn)的數(shù)據(jù)。這種跨地域的聯(lián)合使得集群擁有更好的性能,。

框架中的每一個(gè)主機(jī)都會運(yùn)行一個(gè)負(fù)責(zé)接收和轉(zhuǎn)發(fā)統(tǒng)計(jì)數(shù)據(jù)的ffwd代理,。輸出統(tǒng)計(jì)數(shù)據(jù)的進(jìn)程負(fù)責(zé)將其發(fā)送到ffwd代理。這就使得Spotify工程師可以輕松調(diào)度運(yùn)行在一個(gè)主機(jī)上的任何東西,。庫文件也可以直接假設(shè)主機(jī)上已經(jīng)存在ffwd代理,，并且基本上不需要配置。由于延遲很小,，該代理大大減輕了低效率客戶端所帶來的影響,。ffwd所收集的統(tǒng)計(jì)數(shù)據(jù)最后會輸出到每個(gè)地域的Kafka集群中。

這樣的配置使得Spotify團(tuán)隊(duì)可以利用服務(wù)拓?fù)溥M(jìn)行實(shí)驗(yàn),。而Kafka提供了一個(gè)緩沖,，使得團(tuán)隊(duì)成員在Cassandra或Elasticsearch出現(xiàn)問題時(shí)得以繼續(xù)工作。其中,，每一個(gè)組件都可以根據(jù)需求擴(kuò)展或縮減,。

在后端，所有的數(shù)據(jù)都如同提供給代理一樣進(jìn)行存儲,。如果需要任何downsampling,，使用Dropwizard metric等庫就可以在數(shù)據(jù)進(jìn)入代理之前進(jìn)行執(zhí)行。工程師還可以利用Heroic API對存儲的數(shù)據(jù)執(zhí)行額外的聚合操作,。但是,，Spotify團(tuán)隊(duì)采用了一種合理的采樣密度——一般情況下，每30多秒對每個(gè)時(shí)間序列進(jìn)行采樣,。這種方法有效避免了非穩(wěn)定狀態(tài)的處理流水線所遇到的延遲和復(fù)雜度問題,。

在使用Heroic時(shí)，Spotify團(tuán)隊(duì)能夠利用相同的接口來構(gòu)建定制化的顯示板和警告系統(tǒng),。它使得團(tuán)隊(duì)可以基于相同UI內(nèi)的圖來定義警告,，大大簡化了工程師構(gòu)建的難度。但是,，原有的問題不可能一次性就可以完全解決,。該團(tuán)隊(duì)發(fā)現(xiàn)，擁有第二種方法來監(jiān)控某些部分工作狀態(tài)非常有必要,。其長期目標(biāo)仍然是更多的轉(zhuǎn)向可視化警告方面,。

現(xiàn)在，Heroic的所有部分都已經(jīng)免費(fèi),。用戶可以直接通過GitHub來下載源碼,。文檔和項(xiàng)目的相關(guān)信息也可以在官方網(wǎng)站中找到（GitHub鏈接請點(diǎn)擊原文鏈接獲取）。