[[326553]]

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

1. 背景

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

這套系統遵循以下的設計原則：

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

2. 需求分析

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

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

同時需要滿足幾個需求：

• 需要能采集分布式的日志，并且集中式地查看。
• 需要能采集機器的基本信息，例如 CPU、磁盤，并進行監控。
• 最好能采集應用的數據，例如導入數據的條目數，并進行監控。
• 最好能實現異常指標的告警功能。

3. 方案分析

方案上有 3 個備選方案：

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

利用 Zabbix、Open-Falcon 等運維監控工具進行系統基礎組件的監控。同時利用自定義指標，進行數據的監控和告警。

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

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

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

• 需要能快速部署：通過我們的 Jenkins 可以實現一鍵部署的功能。
• 部署組件簡單：我們只部署 Elasticsearch 和 Kibana 組件，同時 Elasticsearch 本身作為最基礎的組件是自包含的，不依賴任何外部組件。而我們也不使用集群，只用單機部署，保證 Elasticsearch 部署的簡單和穩定。
• 功能性優于穩定性：雖然業務使用的 Elasticsearch 停留在 5.5.3 版本，我們日志采集和分析使用的 Elasticsearch 直接升級到 7.6.0 版本，同時后續的版本升級也可以較為激進，如果遇到不兼容的情況，也不需要保留已有數據，刪除數據重新部署即可。
• 性能要求不高：使用單機部署，Elasticsearch 和 Kibana 部署在同一臺機器上。

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

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

日志采集：

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

日志的查看：

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

系統指標收集：

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

在現場狀態檢測：

我們在網關機器上使用 ansible 部署 heartbeat 進行主動的資源可用性探測，對系統相關的數據庫、http 服務等監控其相應狀態，并將其發送至默認的 ES 儲存索引中。

5. 基于 ES 的告警

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

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

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

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

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

6. 監控大盤

利用 Kibana 的可視化功能，我們可以針對每個業務系統創建一個監控大盤，直觀地看到所有系統組件的情況，以及宿主主機的健康情況：

 

Kibana 配置自動化

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

我們在內部的測試環境中配置好了一個監控用的 Kibana 后，將配置文件通過 CI 系統定期導出儲存于 git 倉庫中，下一次更新基礎組件時，更新腳本就會自動將對應的 kibana 配置導入到私有化部署的環境中，在部署時不需要任何手工配置，實現 Infrastructure as Code。

7. 擴展監控范圍

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

監控更多的應用組件

當我們需要監控新增的應用組件時。

• 對于服務狀態，我們可以簡單地將應用組件的訪問地址加入 hearbeat 的配置中，就可以在監控面板看到對應組件的狀態了。
• 對于應用日志，我們可以將日志的文件路徑加入 filebeat 的配置中，就可以在 Kibana 中搜索到了。

監控應用相關的指標

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

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

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

增加服務 tracing

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

8. 總結

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