在需要私有化部署的系統(tǒng)中，大部分系統(tǒng)僅提供系統(tǒng)本身的業(yè)務(wù)功能，例如用戶管理、財(cái)務(wù)管理、客戶管理等。但是系統(tǒng)本身仍然需要進(jìn)行日志的采集、應(yīng)用指標(biāo)的收集，例如請(qǐng)求速率、主機(jī)磁盤(pán)、內(nèi)存使用量的收集等。同時(shí)方便的分布式系統(tǒng)日志的查看、指標(biāo)的監(jiān)控和告警也是系統(tǒng)穩(wěn)定運(yùn)行的一個(gè)重要保證。

為了使得私有化部署的系統(tǒng)能更健壯，同時(shí)不增加額外的部署運(yùn)維工作量，本文提出了一種基于 ELK 的開(kāi)箱即用的日志和指標(biāo)收集方案。

背景

在當(dāng)前的項(xiàng)目中，我們已經(jīng)使用了 Elasticsearch 作為業(yè)務(wù)的數(shù)據(jù)儲(chǔ)存，同時(shí)利用 ansible、docker、jenkins 組合了一套快速部署的工具。在配置好需要部署主機(jī)的 ssh 連接信息后，我們可以通過(guò) jenkins 一鍵部署一個(gè) Elasticsearch 和 Kibana。

這套系統(tǒng)遵循以下的設(shè)計(jì)原則：

• Self-Contained Deployment：我們把所有的部署腳本、配置文件、Jenkins 任務(wù)都打包到一個(gè)標(biāo)準(zhǔn)化的 Jenkins docker 包中，只要安裝到目標(biāo)的環(huán)境上，即可把所有部署所需的工具都一次性帶入。
• Single Source of Truth：在 Jenkins 中內(nèi)嵌一個(gè) yaml 格式的配置文件管理器，對(duì)于所有部署需要依賴的變量進(jìn)行統(tǒng)一管理，例如 xx 系統(tǒng)后端對(duì)外暴露的端口號(hào)，只在 Jenkins 中配置一次，所有的腳本都會(huì)自動(dòng)讀取該變量。
• Configuration as Code, Infrastructure as Code：當(dāng)所有的配置確定下來(lái)后，后續(xù)的流程理論上是可以做到全自動(dòng)化的，所以所有的安裝都通過(guò)腳本來(lái)完成。

需求分析

在私有化部署的環(huán)境中，日志的收集使用有幾個(gè)特點(diǎn)：

• 需要能快速部署。由于客戶的數(shù)量較多，我們需要能快速地部署監(jiān)控系統(tǒng)，監(jiān)控系統(tǒng)本身的運(yùn)維壓力需要較小。
• 部署組件要簡(jiǎn)單，且健壯性強(qiáng)。由于部署環(huán)境較為復(fù)雜，希望每個(gè)組件自身是健壯的，同時(shí)組件之間的交互盡量簡(jiǎn)單，避免復(fù)雜的網(wǎng)絡(luò)拓?fù)洹?/section>
• 功能性優(yōu)于穩(wěn)定性。由于日志和指標(biāo)信息本身在宿主主機(jī)和應(yīng)用上是有副本的，所以即時(shí)監(jiān)控系統(tǒng)的數(shù)據(jù)丟失了，影響也不大。但是如果系統(tǒng)能提供更多強(qiáng)大的功能，對(duì)于分析是很有幫助的。
• 性能要求不高。由于私有化環(huán)境對(duì)接系統(tǒng)的容量和復(fù)雜度可控，可以使用單機(jī)部署，同時(shí)查詢慢一些也沒(méi)關(guān)系。

同時(shí)需要滿足幾個(gè)需求：

• 需要能采集分布式的日志，并且集中式地查看。
• 需要能采集機(jī)器的基本信息，例如 CPU、磁盤(pán)，并進(jìn)行監(jiān)控。
• 最好能采集應(yīng)用的數(shù)據(jù)，例如導(dǎo)入數(shù)據(jù)的條目數(shù)，并進(jìn)行監(jiān)控。
• 最好能實(shí)現(xiàn)異常指標(biāo)的告警功能。

方案分析

方案上有 3 個(gè)備選方案：

利用 ELK （Elasticsearch、Logstash、Kibana） 做整體的監(jiān)控基礎(chǔ)組件，同時(shí)使用 Elastic 新推出的 beat 系列作為采集工具。

利用 Zabbix、Open-Falcon 等運(yùn)維監(jiān)控工具進(jìn)行系統(tǒng)基礎(chǔ)組件的監(jiān)控。同時(shí)利用自定義指標(biāo)，進(jìn)行數(shù)據(jù)的監(jiān)控和告警。

利用 TICK (Telegraph、InfluxDB、Chronograf、Kapacitor) 做整體的監(jiān)控基礎(chǔ)組件。

目前日志方面能比較好滿足需求的只有開(kāi)源的 ELK 和商業(yè)化的 Splunk，如果 Splunk 的授權(quán)費(fèi)是預(yù)算可接受的，也可以使用方案 2、3 結(jié)合 Splunk 的方式來(lái)實(shí)現(xiàn)。但是目前來(lái)看 Splunk 高昂的授權(quán)費(fèi)并不是大部分公司可以接受的。方案 2 和 3 在需求上不能很好滿足日志的收集和查看功能，所以排除掉了。

方案 1(ELK) 根據(jù)我們的需求進(jìn)一步細(xì)化：

• 需要能快速部署：通過(guò)我們的 Jenkins 可以實(shí)現(xiàn)一鍵部署的功能。
• 部署組件簡(jiǎn)單：我們只部署 Elasticsearch 和 Kibana 組件，同時(shí) Elasticsearch 本身作為最基礎(chǔ)的組件是自包含的，不依賴任何外部組件。而我們也不使用集群，只用單機(jī)部署，保證 Elasticsearch 部署的簡(jiǎn)單和穩(wěn)定。
• 功能性優(yōu)于穩(wěn)定性：雖然業(yè)務(wù)使用的 Elasticsearch 停留在 5.5.3 版本，我們?nèi)罩静杉头治鍪褂玫?Elasticsearch 直接升級(jí)到 7.6.0 版本，同時(shí)后續(xù)的版本升級(jí)也可以較為激進(jìn)，如果遇到不兼容的情況，也不需要保留已有數(shù)據(jù)，刪除數(shù)據(jù)重新部署即可。
• 性能要求不高：使用單機(jī)部署，Elasticsearch 和 Kibana 部署在同一臺(tái)機(jī)器上。

日志專(zhuān)用的 Elasticsearch、Kibana、Beat

為了避免日志使用的 ES 和業(yè)務(wù)使用的 ES 在資源或者配置上發(fā)生沖突，日志專(zhuān)用的 ES 單獨(dú)做了一個(gè)部署，使用約 3G 內(nèi)存。

日志采集：

我們?cè)谒邢嚓P(guān)主機(jī)上使用 ansible 部署 filebeat 進(jìn)行日志的采集，為了簡(jiǎn)化系統(tǒng)，我們也沒(méi)有使用 logstash 做日志的預(yù)處理，只是簡(jiǎn)單地配置了 filebeat 的配置文件，并加入了我們的 jenkins 一鍵部署套件中。

日志的查看：

由于日志直接通過(guò) filebeat 收集到了 es 中，我們使用 Kibana 就能直接進(jìn)行查看了。

系統(tǒng)指標(biāo)收集：

我們?cè)谒邢嚓P(guān)主機(jī)上使用 ansible 部署 metricbeat 進(jìn)行指標(biāo)的收集，通過(guò)配置文件的配置，可以采集到 docker 的資源使用、系統(tǒng) CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)的使用狀態(tài)，同時(shí)也開(kāi)放了 statsd 格式的指標(biāo)收集端口。

在現(xiàn)場(chǎng)狀態(tài)檢測(cè)：

我們?cè)诰W(wǎng)關(guān)機(jī)器上使用 ansible 部署 heartbeat 進(jìn)行主動(dòng)的資源可用性探測(cè)，對(duì)系統(tǒng)相關(guān)的數(shù)據(jù)庫(kù)、http 服務(wù)等監(jiān)控其相應(yīng)狀態(tài)，并將其發(fā)送至默認(rèn)的 ES 儲(chǔ)存索引中。

基于 ES 的告警

Elasticsearch 的原生告警是付費(fèi)功能，為了搭建一個(gè)更通用的告警系統(tǒng)，這里用了一個(gè)開(kāi)源的項(xiàng)目 elastalert 實(shí)現(xiàn)告警。Elastalert 是 Yelp 公司（美國(guó)的大眾點(diǎn)評(píng)）開(kāi)發(fā)的基于 python 和 Elasticsearch 的告警系統(tǒng)，可以對(duì)接的告警途徑很多，但是大部分都是國(guó)外的工具例如 Slack、HipChat、PagerDuty，所以我們目前只使用了最基礎(chǔ)的郵件告警功能。

Elastalert 可以配置多種告警類(lèi)型，例如：

• 某條件連續(xù)觸發(fā) N 次（frequency 類(lèi)型）。
• 某指標(biāo)出現(xiàn)的頻率增加或者減少（spike 類(lèi)型）。
• N 分鐘未檢測(cè)到某指標(biāo)（flatline 類(lèi)型）等。

每個(gè)告警的配置核心其實(shí)是一個(gè) elasticsearch 的查詢語(yǔ)句，通過(guò)查詢語(yǔ)句返回的條目數(shù)來(lái)進(jìn)行判斷。

目前我們也只使用了最基礎(chǔ)的 frequency 類(lèi)型告警。由于這個(gè)告警是針對(duì)特定幾個(gè)私有化部署的系統(tǒng)，所以我們提前配置好了若干個(gè)告警的配置文件，在部署腳本中，如果沒(méi)有特別需求，就全部復(fù)制到 elastalert 的系統(tǒng)中，不需要任何手工配置。

監(jiān)控大盤(pán)

利用 Kibana 的可視化功能，我們可以針對(duì)每個(gè)業(yè)務(wù)系統(tǒng)創(chuàng)建一個(gè)監(jiān)控大盤(pán)，直觀地看到所有系統(tǒng)組件的情況，以及宿主主機(jī)的健康情況：

Kibana 配置自動(dòng)化

Kibana 當(dāng)中所有持久化了的配置都是一個(gè) Saved Object，包括：快捷搜索、監(jiān)控大盤(pán)、可視化面板、索引配置。

我們?cè)趦?nèi)部的測(cè)試環(huán)境中配置好了一個(gè)監(jiān)控用的 Kibana 后，將配置文件通過(guò) CI 系統(tǒng)定期導(dǎo)出儲(chǔ)存于 git 倉(cāng)庫(kù)中，下一次更新基礎(chǔ)組件時(shí)，更新腳本就會(huì)自動(dòng)將對(duì)應(yīng)的 kibana 配置導(dǎo)入到私有化部署的環(huán)境中，在部署時(shí)不需要任何手工配置，實(shí)現(xiàn) Infrastructure as Code。

擴(kuò)展監(jiān)控范圍

這套部署組件在擴(kuò)展上也是有一個(gè)標(biāo)準(zhǔn)流程的。

監(jiān)控更多的應(yīng)用組件

當(dāng)我們需要監(jiān)控新增的應(yīng)用組件時(shí)。

• 服務(wù)狀態(tài)，我們可以簡(jiǎn)單地將應(yīng)用組件的訪問(wèn)地址加入 hearbeat 的配置中，就可以在監(jiān)控面板看到對(duì)應(yīng)組件的狀態(tài)了。
• 應(yīng)用日志，我們可以將日志的文件路徑加入 filebeat 的配置中，就可以在 Kibana 中搜索到了。

監(jiān)控應(yīng)用相關(guān)的指標(biāo)

當(dāng)我們需要監(jiān)控應(yīng)用相關(guān)的指標(biāo)時(shí)，我們可以通過(guò) statsd 的接口，將指標(biāo)發(fā)布至 metricbeat，統(tǒng)一收集至 Elasticsearch 當(dāng)中。statsd 底層規(guī)則相對(duì)簡(jiǎn)單，所以在每個(gè)編程語(yǔ)言中都有相應(yīng)的 SDK 可以直接使用，并沒(méi)有復(fù)雜的依賴：

https://github.com/statsd/statsd/wiki

但是目前 metricbeat 收集來(lái)的 statsd 信息是不支持 tag 的，所以還只能做一些簡(jiǎn)單的指標(biāo)收集，并不能對(duì)同一指標(biāo)的不同維度做聚合分析。

增加服務(wù) tracing

Elasticsearch 當(dāng)中也帶了 APM 服務(wù)這個(gè)暫時(shí)還沒(méi)有嘗試接入，如果可以使用的話，是一個(gè)性能監(jiān)控和分析的利器。