建設DevOps統一運維監控平臺，先從日誌監控提及

前言

隨着Devops、雲計算、微服務、容器等理念的逐步落地和大力發展，機器愈來愈多，應用愈來愈多，服務愈來愈微，應用運行基礎環境越來多樣化，容器、虛擬機、物理機不一而足。

面對動輒幾百上千個虛擬機、容器，數十種要監控的對象，現有的監控系統還可否支撐的住？來自於容器、虛擬機、物理機的應用日誌、系統服務日誌如何採用同一套方案快速、完整的收集和檢索？怎樣的架構、技術方案才更適合如此龐大繁雜的監控需求呢？本文主要從如下幾個方面來分享下筆者在日誌監控方面的一些經驗。

目錄

1、DevOps浪潮下帶來的監控挑戰

2、統一監控平臺架構解析

3、日誌監控的技術棧

4、日誌監控經典方案ELK

5、微服務+容器雲背景下的日誌監控實踐Journald+fluentd+elasticsearch

6、如何選擇適合本身的日誌監控方案？

 

1、DevOps浪潮下帶來的監控挑戰

如今Devops、雲計算、微服務、容器等理念正在逐步落地和大力發展，機器愈來愈多，應用愈來愈多，服務愈來愈微，應用運行基礎環境越來多樣化，容器，監控面臨的壓力愈來愈大。挑戰主要有：

 

• 監控源的多樣化挑戰

  業務、應用、網絡設備、存儲設備、物理機、虛擬機、容器、數據庫、各類系統軟件等等，須要監控的對象愈來愈多，指標也多種多樣，如何以一個統一的視角，監控到全部的數據？

• 海量數據的分析處理挑戰

  設備愈來愈多，應用愈來愈多，要監控的數據天然也排山倒海般襲來，怎樣的監控系統才能應對大數據的採集、存儲和實時分析展示呢？

• 軟硬件數據資源的管理分析挑戰

  數據是採集到了，採集全了，那麼如何對他們進行分析呢？應用、系統軟件和運行環境、網絡、存儲設備的關聯關係是否能準確體現呢，某個點發生了故障、問題影響的鏈路是否能快速找到並進行處理呢？監控離不開和軟硬件資源管理的結合。

面對這些挑戰，是否感受壓力山大呢？一個監控平臺，擁有哪些能力才能知足如此大的挑戰呢？

一個好的統一監控平臺，應當具有如圖所示的能力：

• 高度抽象模型，擴展監控指標：正如以前所說，監控源、指標的多樣化，要求咱們必需要進行監控模型的高度抽象，而且針對於指標能夠動態擴展，這樣才能保證監控平臺的健壯性和可擴展性。

• 多種監控視圖：監控數據天然不能只是簡單的表格展示，餅圖、柱狀圖、折線圖、儀表盤等等，監控的數據須要結合實際狀況選擇最佳的圖標展示。

• 強大的數據加工能力：海量的數據必需要有足夠強大的數據加工、分析處理能力才能獲得直觀的結果

• 多種數據採集技術：數據源的不一樣決定了採集的技術也是有區別的。

• 多種報警機制：短信、郵件、企業內部通信工具等等，結合不一樣場景選擇不一樣的報警機制。

• 全路徑問題跟蹤：一個請求有可能牽扯到數個系統、數十個接口的調用，出了問題有多是其中任何一個環節，也有多是應用所處運行環境、網絡、存儲的問題，因此問題的定位離不開全路徑的跟蹤。

 

2、統一監控平臺架構解析

統一監控平臺由七大角色構成：監控源、數據採集、數據存儲、數據分析、數據展示、預警中心、CMDB(企業軟硬件資產管理)。

 

監控源

從層次上來分，大體能夠分爲三層，業務應用層、中間件層、基礎設施層。業務應用層主要包括應用軟件、企業消息總線等，中間件層包括數據庫、緩存、配置中心、等各類系統軟件，基礎設施層主要有物理機、虛擬機、容器、網絡設備、存儲設備等等。

數據採集

數據源如此多樣，數據採集的任務天然輕鬆不了。數據採集從指標上劃分能夠分爲業務指標、應用指標、系統軟件監控指標、系統指標。

應用監控指標如：可用性、異常、吞吐量、響應時間、當前等待筆數、資源佔用率、請求量、日誌大小、性能、隊列深度、線程數、服務調用次數、訪問量、服務可用性等，業務監控指標如大額流水、流水區域、流水明細、請求筆數、響應時間、響應筆數等，系統監控指標如：CPU負載、內存負載、磁盤負載、網絡IO、磁盤IO、tcp鏈接數、進程數等。

從採集方式來講一般能夠分爲接口採集、客戶端agent採集、經過網絡協議主動抓取（http、snmp等）

數據存儲

採集到的數據通常都會存儲到文件系統（如HDFS）、索引系統（如elasticsearch）、指標庫（如influxdb）、消息隊列（如kafka，作消息臨時存儲或者緩衝）、數據庫（如mysql）

數據分析

針對採集到的數據，進行數據的處理。處理分兩類：實時處理和批處理。技術包括Map/Reduce計算、全日誌檢索、流式計算、指標計算等，重點是根據不一樣的場景需求選擇不一樣的計算方式。

數據展示

將處理的結果進行圖表展示，在多屏時代，跨設備的支持必不可少。

預警

若是在數據處理過程發現了問題，則須要進行異常的分析、風險的預估以及事件的觸發或告警。

CMDB(企業軟硬件資產管理)

CMDB在統一監控平臺中是很重要的一環，監控源雖然種類繁多，可是他們大都有着關係，如應用運行在運行環境中，應用的正常運行又依賴網絡和存儲設備，一個應用也會依賴於其餘的應用（業務依賴），一旦其中任何一個環節出了問題，都會致使應用的不可用。CMDB除了存儲軟硬件資產外，還要存儲這樣一份資產間的關聯關係，一個資產發生了故障，要能根據這個關係迅速得知哪些其餘的資產會被影響，而後逐一解決問題。

 

3、日誌監控的技術棧

既然前面講了整個監控系統的架構，下面就按照架構中的角色來分類看看有哪些經常使用的開源技術。因爲篇幅緣由，這裏沒法詳細描述每個技術的細節，你們感興趣的話，能夠一一瞭解下。

日誌源

首先談談日誌的來源，日誌的通常存儲在三個位置：數據庫、操做系統日誌、日誌文件。通常操做日誌會習慣於存儲在數據庫中，在這裏暫且不提。Syslog、Rsyslog、Journald都是linux系統的日誌服務。

syslog 守護進程的任務是記錄系統日誌。它從應用程序和服務中獲取格式各異的日誌消息並保存到磁盤上，消息的元數據是組件名、優先級、時間戳、進程標籤和 PID，日誌格式非常寬泛，沒有定義結構化的格式，因此係統的分析和日誌消息處理也就變得十分混亂，同時性能和其餘的一些缺點隨着時間推移也慢慢被放大，後來慢慢被Rsyslog所取代。

Rsyslog能夠說是Syslog的升級版，它涵蓋SysLog的經常使用功能，不過在功能和性能上更爲出色。

Red Hat Enterprise Linux 7與SUSE Linux Enterprise Server 12這些新一代的Linux發行版本使用systemd管理服務。

journal是systemd的一個組件，由journald處理。Journald是爲Linux服務器打造的新系統日誌方式，它標誌着文本日誌文件的終結，它再也不存儲日誌文件，而是將日誌信息寫入到二進制文件，使用journalctl閱讀。它捕獲系統日誌信息、內核日誌信息，以及來自原始RAM磁盤的信息，早期啓動信息以及全部服務中寫入STDOUT和STDERR數據流的信息。Journald快速改變着服務器如何處理日誌信息與管理員如何訪問的方式。

數據採集

日誌的採集工做大都是經過客戶端進行，客戶端除了一些直接可用的工具（如fluentd、flume、logstash）外，還能夠經過log4j的appender、自行寫腳本實現等。

fluentd是開源社區中流行的日誌收集工具，fluentd基於CRuby實現，並對性能表現關鍵的一些組件用C語言從新實現，總體性能至關不錯。優勢是設計簡潔，pipeline內數據傳遞可靠性高。缺點是相較於logstash和flume，其插件支持相對少一些。

flume是由JAVA實現的一個分佈式的、可靠的、高性能、可擴展的的日誌收集框架，Flume比較看重數據的傳輸，使用基於事務的數據傳遞方式來保證事件傳遞的可靠性，幾乎沒有數據的解析預處理。僅僅是數據的產生，封裝成event而後傳輸。同時使用zookeeper進行負載均衡，不過JVM帶來的問題天然是內存佔用相對較高。

Logstash相比你們都比較熟悉了，是ELK中的L，logstash基於JRuby實現，能夠跨平臺運行在JVM上。logstash安裝簡單，使用簡單，結構也簡單，全部操做全在配置文件設定，運行調用配置文件便可。同時社區活躍，生態圈提供了大量的插件。早期Logstash並不支持數據的高可靠傳遞，因此在一些關鍵業務數據的採集上，使用logstash就不如flume更加可靠。不過在5.1.1版本發佈了持久化隊列的beta版，顯然logstash也在快速改進本身的缺陷。

數據緩衝

在大批量的監控數據涌過來後，考慮到網絡的壓力和數據處理的瓶頸，通常會在存儲前先通過一層數據緩衝，將採集到的數據先放置到消息隊列中，而後再從分佈式隊列中讀取數據並存儲。這張圖是新浪的日誌檢索系統的架構圖，能夠看到數據採集後，通過kafka緩衝，而後再使用logstash去讀取kafka中的數據並存儲到es中：

 

 關於分佈式隊列這裏就不詳細講解了，經常使用有kafka，rabbitmq，zeromq等。

數據存儲&分析

存儲和分析息息相關，監控數據的處理一般分爲實時處理和非實時處理（如大數據的批處理框架hadoop等），如Elasticsearch就是一個實時的分佈式搜索和分析引擎，它能夠用於全文搜索，結構化搜索以及分析。

除了ES外，還有一些流式大數據處理框架能夠作到實時或者準實時的處理大數據流。如Spark和Storm。關於大數據處理的內容由於本人也沒有多少實踐經驗，就不在此多作分享了。後面主要仍是針對於Elasticsearch這一框架進行介紹。

數據展示

Kibana和Elasticsearch能夠說是無縫銜接，再加上Logstash，組成的ELK赫赫有名，不少企業都會直接採用這一種框架。

Kibana確實也能知足大部分的監控需求，可是其畢竟只能依靠現有的數據進行展示，若是須要和外部數據結合處理，就會沒法知足了，而且在本身構建一個統一監控平臺時，須要將日誌和性能等監控數據結合CMDB、預警中心、等統一展示，因此對於kibana的替換就沒法避免了。咱們是經過使用JAVA去查詢Elasticsearch的數據，結合其餘數據統一分析，將展示的結果進行滾動展示或者用圖表顯示。

 

4、ELK-日誌監控經典方案

ELK stack ：是一個實時的分佈式搜索和分析引擎，它能夠用於全文搜索，結構化搜索以及分析。以Elasticsearch、Logstash、Kibana組成的數據處理工具鏈,在實時數據檢索和分析場合，三者一般是配合共用，並且又都前後歸於 Elastic.co 公司名下，故有此簡稱。

優勢：

• 處理方式靈活：Elasticsearch是實時全文檢索，不須要像storm那樣預先編程才能使用。

• 配置簡易上手：Elasticsearch所有采用JSON接口，LogStash是Ruby DSL設計，都是目前業界最通用的配置語法設計。

• 檢索性能高效：Elasticsearch的優秀設計和實現基本能夠達到百億級數據查詢的秒級響應。

• 集羣線性擴展：無論是Elasticsearch集羣仍是Logstash集羣都是能夠線性擴展的。

• 前端展示絢麗：Kibana爲 Elasticsearch 提供分析和可視化的 Web 平臺。它能夠在 Elasticsearch 的索引中查找，交互數據，並生成各類維度的表圖。

• 開源：三個軟件所有開源，便於自主掌控。

• 三個工具相互緊密結合：由同一個公司提供，而且做爲一套解決方案ELK Stack對外提供，無論是部署仍是功能的整合，三者無縫銜接，便於安裝和使用。

   

   

Logstash

logstash是一個開源的、服務端的數據流轉管道，支持從多個目標中收取數據、轉換而且發送，在logstash中，包含三個階段：inputs、filters、outputs。

 

Inputs用來產生事件數據，Filters用來定義、過濾數據事件，outputs用來把事件數據發送到外部。Inputs和Outputs支持經過codecs在管道中對數據進行編碼和反編碼。Logstash提供了強大的插件機制，每個角色都包含了多種插件，易於擴展和選擇。比較典型的插件以下： 

Input plugins：beats、file、syslog、http、kafka、github、jmx、…

Filter plugins：grok、json、csv、…

Output plugins：file、http、jira、kafka、elasticsearch、mongodb、opentsdb、rabbitmq、zeromq、…

Codec plugins：json、msgpack、plain、…

若想了解更多關於logstash的插件，能夠到官網去自行了解：https://www.elastic.co/guide/en/logstash/5.2/index.html

 

Elasticsearch

Elasticsearch 是一個實時的分佈式搜索和分析引擎，它能夠用於全文搜索，結構化搜索以及分析。它是一個創建在全文搜索引擎 Apache Lucene 基礎上的搜索引擎，使用 Java 語言編寫。聽說Elasticsearch最初的目的只是爲了給做者當時正在學廚師的妻子作一個菜譜的搜索引擎，不過到目前這個菜譜搜索引擎仍然沒有面世。

主要特色以下：

• 實時分析

• 分佈式實時文件存儲，並將每個字段都編入索引

• 文檔導向，全部的對象所有是文檔

• 高可用性，易擴展，支持集羣（Cluster）、分片和複製（Shards 和 Replicas）

• 接口友好，支持 JSON

• 檢索性能強大，ES基於lucene,對於每一個新寫入的數據，會針對於每一個字段都建立索引

 

Kibana

 

如官網所述，Kibana是ELK的窗口，專門針對於Elasticsearch進行數據分析展示。它提供的諸如面板、儀表盤、可視化功能等能力，基本上承載了對es的查詢和分析能力。

 

5、微服務+容器雲背景下的日誌監控實踐

Journald+fluentd+elasticsearch

下面給你們介紹下咱們在微服務+容器雲背景下的日誌監控實踐，首先要介紹下咱們的DevOps平臺架構，平臺運行在由kubernetes+docker構建的容器雲中，kubernetes、docker等服務運行在IaaS平臺上（咱們的生產環境是阿里雲）。

 

咱們的監控系統在選型時，也是糾結了很久。咱們的需求來自於多方面的，一方面要對系統服務的日誌進行監控（在虛擬機中），如kubernetes、etcd等服務的日誌，另外一方面要對應用、數據庫、redis等其餘軟件的日誌進行監控（在容器中）。

考慮到統一日誌源，咱們最終決定讓全部的日誌都輸入到系統日誌journald中，由journald做爲統一對外日誌發送來源。UMC系統的日誌監控架構如圖所示：

 

跑在容器中的應用、數據庫等軟件都會把日誌落到容器日誌（docker日誌），而後在docker系統服務上進行配置，將docker容器日誌輸出到系統日誌服務journald中。這樣，容器中的日誌就統一到了系統日誌中。針對於運行在虛擬機上的系統軟件，如kubernetes、etcd等，配置成系統服務service，使用systemd管理，天然也就作到了將其日誌輸入到journald中。

再往上就比較簡單了，自實現一個agent，讀取journald中的日誌，經過tcp協議發送到fluentd中，考慮到如今的日誌量並不會太大，因此沒有再使用kafka進行緩衝，而是直接通過fluentd的攔截和過濾，將日誌發送到Elasticsearch中。

爲何選擇Fluentd而不是選擇logstash？

• logstash插件至關豐富，可是fluentd的插件已經能知足要求了

• Logstash是JRuby語言實現的，依賴jvm運行，內存佔用較高，性能也比較差

• 咱們的日誌主要來源仍是docker，Fluentd的方案與Logstash差很少，可是它能夠省掉Indexer這層，並且它的核心代碼是C++寫的，從效率上說會比Logstash高不少。Fluentd是除了Splunk之外惟一一個在Docker官方日誌驅動裏面的工具。Fluentd則不只支持Logstash那種文件的方式去搜集日誌，還能夠經過Docker的Fluentd driver直接定向蒐集

• 咱們的虛擬機操做系統是coreos，安裝fluentd更加方便，不須要再去安裝jre。

 

主要解決的問題：

一、全部的日誌都混合在一塊兒了，若是區分哪些是A應用在dev環境下的實例的日誌？哪些是某個數據庫在測試環境下運行的實例日誌？

容器的日誌一個記錄如圖所示

 

咱們的ContainerName是有命名規則的，其中包含了產品名（如mysql-1）,環境名（如env-deployment），經過這兩個屬性來進行模糊查詢匹配。找到對應的日誌。從而也作到了不須要分析日誌內容、也不用區分是應用日誌仍是數據庫日誌，達到將日誌和其對應的產品實例關聯起來的目的。

二、ES中文分詞插件，ES默認的分詞會把「中國」分解成「中」，「國」,這樣在檢索「中國」的時候，也會把「美國」搜索出來，咱們最終安裝了ik中文分詞插件elasticsearch-analysis-ik，就能夠把「中國」當成一個總體去檢索了。

 

6、如何選擇適合本身的日誌監控方案？

介紹了整個監控平臺架構，也介紹了日誌監控的技術棧，那麼，如何選擇適合本身的日誌監控方案呢？我認爲應當從以下幾個方面來綜合考量。

• 工具能力是否知足，像logstash/flume/fluentd都知足咱們的要求，雖然fluentd相對於另外兩個工具的插件少了很多，可是就咱們的需求而言，fluentd足夠了。

• 性能對比，既然logstash/flume/fluentd都符合要求，相比之下，fluentd的性能最好。

• 看技術能力是否能cover住，若是有些本身特殊的需求是工具知足不了的，就會須要自行擴展工具，那就要好好考量該工具的實現語言本身的團隊是否能cover住，好比一個純java團隊，去用ruby語言擴展logstash的能力，就會有些風險了。

• 監控平臺日誌量評估，要從可擴展性去設計日誌監控的架構，固然，對於整個監控平臺而言也是如此。

總之，適合本身的纔是最好的。