從零搭建一個基於ELK的日誌、指標收集與監控系統

摘要：我們在內部的測試環境中配置好了一個監控用的 Kibana 後，將配置文件通過 CI 系統定期導出儲存於 git 倉庫中，下一次更新基礎組件時，更新腳本就會自動將對應的 kibana 配置導入到私有化部署的環境中，在部署時不需要任何手工配置，實現 Infrastructure as Code。我們在所有相關主機上使用 ansible 部署 metricbeat 進行指標的收集，通過配置文件的配置，可以採集到 docker 的資源使用、系統 CPU、內存、磁盤、網絡的使用狀態，同時也開放了 statsd 格式的指標收集端口。

作者 | 陳迪

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

1 背景

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

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

Self-Contained Deployment：我們把所有的部署腳本、配置文件、Jenkins 任務都打包到一個標準化的 Jenkins docker 包中，只要安裝到目標的環境上，即可把所有部署所需的工具都一次性帶入。
Single Source of Truth：在 Jenkins 中內嵌一個 yaml 格式的配置文件管理器，對於所有部署需要依賴的變量進行統一管理，例如 xx 系統後端對外暴露的端口號，只在 Jenkins 中配置一次，所有的腳本都會自動讀取該變量。
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 可以配置多種告警類型，例如：