本文轉自微訊號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！

前言

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

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

目錄
一、DevOps浪潮下帶來的監控挑戰
二、統一監控平臺架構解析
三、日誌監控的技術棧
四、日誌監控經典方案ELK
五、微服務+容器雲背景下的日誌監控實踐Journald+fluentd+elasticsearch
六、如何選擇適合自己的日誌監控方案？
 

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

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

• 監控源的多樣化挑戰
  業務、應用、網路裝置、儲存裝置、物理機、虛擬機器、容器、資料庫、各種系統軟體等等，需要監控的物件越來越多，指標也多種多樣，如何以一個統一的視角，監控到所有的資料？

• 海量資料的分析處理挑戰
  裝置越來越多，應用越來越多，要監控的資料自然也排山倒海般襲來，怎樣的監控系統才能應對大資料的採集、儲存和實時分析展現呢？

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

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

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

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

• 多種監控檢視：監控資料自然不能只是簡單的表格展現，餅圖、柱狀圖、折線圖、儀表盤等等，監控的資料需要結合實際情況選擇最佳的圖示展現。

• 強大的資料加工能力：海量的資料必須要有足夠強大的資料加工、分析處理能力才能得到直觀的結果。

• 多種資料採集技術：資料來源的不同決定了採集的技術也是有區別的。

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

• 全路徑問題跟蹤：一個請求有可能牽扯到數個系統、數十個介面的呼叫，出了問題有可能是其中任何一個環節，也有可能是應用所處執行環境、網路、儲存的問題，所以問題的定位離不開全路徑的跟蹤。

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

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

監控源
從層次上來分，大致可以分為三層，業務應用層、中介軟體層、基礎設施層。業務應用層主要包括應用軟體、企業訊息匯流排等，中介軟體層包括資料庫、快取、配置中心、等各種系統軟體，基礎設施層主要有物理機、虛擬機器、容器、網路裝置、儲存裝置等等。

資料採集
資料來源如此多樣，資料採集的任務自然輕鬆不了。資料採集從指標上劃分可以分為業務指標、應用指標、系統軟體監控指標、系統指標。

應用監控指標如：可用性、異常、吞吐量、響應時間、當前等待筆數、資源佔用率、請求量、日誌大小、效能、佇列深度、執行緒數、服務呼叫次數、訪問量、服務可用性等，業務監控指標如大額流水、流水區域、流水明細、請求筆數、響應時間、響應筆數等，系統監控指標如：CPU負載、記憶體負載、磁碟負載、網路IO、磁碟IO、tcp連線數、程序數等。

從採集方式來說通常可以分為介面採集、客戶端agent採集、通過網路協議主動抓取（http、snmp等）

資料儲存
採集到的資料一般都會儲存到檔案系統（如HDFS）、索引系統（如elasticsearch）、指標庫（如influxdb）、訊息佇列（如kafka，做訊息臨時儲存或者緩衝）、資料庫（如mysql）

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

資料展現
將處理的結果進行圖表展現，在多屏時代，跨裝置的支援必不可少。

預警
如果在資料處理過程發現了問題，則需要進行異常的分析、風險的預估以及事件的觸發或告警。

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

三、日誌監控的技術棧

既然前面講了整個監控系統的架構，下面就按照架構中的角色來分類看看有哪些常用的開源技術。由於篇幅原因，這裡無法詳細描述每一個技術的細節，大家感興趣的話，可以一一瞭解下。

日誌源

首先談談日誌的來源，日誌的一般儲存在三個位置：資料庫、作業系統日誌、日誌檔案。一般操作日誌會習慣於儲存在資料庫中，在這裡暫且不提。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的資料，結合其他資料統一分析，將展現的結果進行滾動展現或者用圖表顯示。

四、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。

nputs用來產生事件資料，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、…

Elasticsearch

Elasticsearch 是一個實時的分散式搜尋和分析引擎，它可以用於全文搜尋，結構化搜尋以及分析。它是一個建立在全文搜尋引擎 Apache Lucene 基礎上的搜尋引擎，使用 Java 語言編寫。據說Elasticsearch最初的目的只是為了給作者當時正在學廚師的妻子做一個菜譜的搜尋引擎，不過到目前這個菜譜搜尋引擎仍然沒有面世。
主要特點如下：

• 實時分析
• 分散式實時檔案儲存，並將每一個欄位都編入索引
• 文件導向，所有的物件全部是文件
• 高可用性，易擴充套件，支援叢集（Cluster）、分片和複製（Shards 和 Replicas） 介面友好，支援 JSON
• 檢索效能強大，ES基於lucene,對於每個新寫入的資料，會針對於每個欄位都建立索引

Kibana

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

五、微服務+容器雲背景下的日誌監控實踐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。

主要解決的問題：

1、所有的日誌都混合在一起了，如果區分哪些是A應用在dev環境下的例項的日誌？哪些是某個資料庫在測試環境下執行的例項日誌？

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

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

2、ES中文分詞外掛，ES預設的分詞會把“中國”分解成“中”，“國”,這樣在檢索“中國”的時候，也會把“美國”搜尋出來，我們最終安裝了ik中文分詞外掛elasticsearch-analysis-ik，就可以把“中國”當成一個整體去檢索了。

六、如何選擇適合自己的日誌監控方案？

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

• 工具能力是否滿足，像logstash/flume/fluentd都滿足我們的要求，雖然fluentd相對於另外兩個工具的外掛少了不少，但是就我們的需求而言，fluentd足夠了。

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

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

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

總之，適合自己的才是最好的。

關於作者
王海龍
現任普元資訊高階研發工程師，畢業於華東師範大學，曾參與和負責銀聯Paas雲平臺專案、興業銀行CAP4J專案、交通銀行信用卡中心統一監控平臺專案、神華災備雲平臺、萬達DevOps平臺等專案。

關於EAWorld
微服務，DevOps，元資料，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公眾號。

掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微訊號：EAWorld，長按二維碼關注。