1. <th id="orwrz"></th>
        <tbody id="orwrz"><pre id="orwrz"></pre></tbody>
      2. <rp id="orwrz"><object id="orwrz"></object></rp>
        首頁 運維干貨從零搭建一個基于 ELK 的日志、指標收集與監控系統

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

        運維派隸屬馬哥教育旗下專業運維社區,是國內成立最早的IT運維技術社區,歡迎關注公眾號:yunweipai
        領取學習更多免費Linux云計算、Python、Docker、K8s教程關注公眾號:馬哥linux運維

        在需要私有化部署的系統中,大部分系統僅提供系統本身的業務功能,例如用戶管理、財務管理、客戶管理等。但是系統本身仍然需要進行日志的采集、應用指標的收集,例如請求速率、主機磁盤、內存使用量的收集等。同時方便的分布式系統日志的查看、指標的監控和告警也是系統穩定運行的一個重要保證。

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖

        為了使得私有化部署的系統能更健壯,同時不增加額外的部署運維工作量,本文提出了一種基于 ELK 的開箱即用的日志和指標收集方案。

        背景

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖1

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

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

        需求分析

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

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

        同時需要滿足幾個需求:

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

        方案分析

        方案上有 3 個備選方案:

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖2

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖3

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖4

        目前日志方面能比較好滿足需求的只有開源的 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 部署在同一臺機器上。

        日志專用的 Elasticsearch、Kibana、Beat

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

        日志采集:

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

        日志的查看:

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖5

        系統指標收集:

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖6

        在現場狀態檢測:

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖7

        基于 ES 的告警

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

        Elastalert 可以配置多種告警類型,例如:

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

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

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

        監控大盤

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖8

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖9

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖10

        Kibana 配置自動化

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

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

        擴展監控范圍

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

        監控更多的應用組件

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

        • 服務狀態,我們可以簡單地將應用組件的訪問地址加入 hearbeat 的配置中,就可以在監控面板看到對應組件的狀態了。

        • 應用日志,我們可以將日志的文件路徑加入 filebeat 的配置中,就可以在 Kibana 中搜索到了。

        監控應用相關的指標

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

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

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

        增加服務 tracing

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

        從零搭建一個基于 ELK 的日志、指標收集與監控系統插圖11

        總結

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

        作者簡介:
        陳迪,熵簡技術合伙人,畢業于上海交大,負責熵簡科技大后臺及產品架構相關研發工作。

        (版權歸原作者所有,侵刪)

        本文鏈接:http://www.abandonstatusquo.com/40086.html

        網友評論comments

        發表評論

        您的電子郵箱地址不會被公開。

        暫無評論

        Copyright ? 2012-2022 YUNWEIPAI.COM - 運維派 京ICP備16064699號-6
        掃二維碼
        掃二維碼
        返回頂部
        十分钟免费观看视频高清下载