[[326553]]

在需要私有化部署的系統(tǒng)中，大部分系統(tǒng)僅提供系統(tǒng)本身的業(yè)務(wù)功能，例如用戶管理、財務(wù)管理、客戶管理等。但是系統(tǒng)本身仍然需要進行日志的采集、應(yīng)用指標的收集，例如請求速率、主機磁盤、內(nèi)存使用量的收集等。同時方便的分布式系統(tǒng)日志的查看、指標的監(jiān)控和告警也是系統(tǒng)穩(wěn)定運行的一個重要保證。為了使得私有化部署的系統(tǒng)能更健壯，同時不增加額外的部署運維工作量，本文提出了一種基于 ELK 的開箱即用的日志和指標收集方案。

1. 背景

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

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

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

2. 需求分析

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

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

同時需要滿足幾個需求：

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

3. 方案分析

方案上有 3 個備選方案：

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

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

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

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

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

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

4. 日志專用的 Elasticsearch、Kibana、Beat

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

日志采集：

我們在所有相關(guān)主機上使用 ansible 部署 filebeat 進行日志的采集，為了簡化系統(tǒng)，我們也沒有使用 logstash 做日志的預(yù)處理，只是簡單地配置了 filebeat 的配置文件，并加入了我們的 jenkins 一鍵部署套件中。

日志的查看：

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

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

我們在所有相關(guān)主機上使用 ansible 部署 metricbeat 進行指標的收集，通過配置文件的配置，可以采集到 docker 的資源使用、系統(tǒng) CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)的使用狀態(tài)，同時也開放了 statsd 格式的指標收集端口。

在現(xiàn)場狀態(tài)檢測：

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

5. 基于 ES 的告警

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

Elastalert 可以配置多種告警類型，例如：

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

每個告警的配置核心其實是一個 elasticsearch 的查詢語句，通過查詢語句返回的條目數(shù)來進行判斷。

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

6. 監(jiān)控大盤

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

Kibana 配置自動化

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

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

7. 擴展監(jiān)控范圍

這套部署組件在擴展上也是有一個標準流程的。

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

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

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

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

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

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

但是目前 metricbeat 收集來的 statsd 信息是不支持 tag 的，所以還只能做一些簡單的指標收集，并不能對同一指標的不同維度做聚合分析。

增加服務(wù) tracing

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

8. 總結(jié)

私有化部署的環(huán)境中，日志的收集和監(jiān)控不像互聯(lián)網(wǎng)產(chǎn)品一樣需要較強的性能和可擴容性，開箱即用和功能的強大就較為重要。7.6.0 版本的 Elasticsearch 和 Kibana 在這方面能很好地滿足需求，只需要對部署流程進行標準化，并提前準備好配置文件，就可以在半小時內(nèi)搭建好一整套監(jiān)控體系。