輕鬆籌監控系統實現方案

監控系統是服務管理最重要的組成部分之一，可以幫助開發人員更好的了解服務的運行狀況，及時發現異常情況。雖然阿里提供收費的業務監控服務，但是監控有很多開源的解決方案，可以嘗試自建監控系統，滿足基本的監控需求，以後逐步完善優化。這樣既可以更靈活的滿足自身業務的監控需求，也可以為以後自建機房提供技術積累。通過以下7個方面來建設監控系統。

1 . 日誌列印

完善的日誌是實現監控的基礎，如何列印日誌關係到之後的日誌過濾、存儲以及分析。除了選擇合適的日誌庫，還要滿足一些日誌列印的要求：

日誌風格：以key-value的field形式輸出結構化的日誌。

輸出時機： error日誌一定都需要列印，info日誌結合業務需求適當列印，日誌只需要在業務層關注，model和util等不需要列印。

輸出格式：線上以json的格式列印日誌，方便解析日誌。線下為了方便查看，可以用自定義的format列印日誌，線上和線下的日誌格式通過etcd來控制。

輸出內容： 每一條日誌都要攜帶logid、method、host和level，並且根據不同業務場景，需要攜帶不同業務的標識field，例如projectType、platform、payType等。

用context來傳遞不同goroutine之間的共享信息。

2 . 日誌切分

日誌切分是運維層面的東西，不應該由日誌庫來承擔日誌切分的事情，因為Linux在日誌切分上有很成熟的工具，不需要自己寫碼去重複實現。

目前對日誌切分的需求只有2個：按天切分和刪除切出來的多餘日誌。logrotate就能很好的滿足這些需求，logrotate是基於cron來運行的，其腳本是/etc/cron.daily/logrotate，默認放在/etc/cron.daily下，每天執行一次。

有的時候程序異常或者請求激增會導致日誌量暴增，有可能在短時間內打滿整個磁碟。可以在logrotate的配置文件里加上maxsize來限制日誌文件的大小，並且將logrotate的執行頻率調高至每小時甚至每分鐘，及時切分並刪除超過rotate數量的日誌，來防止異常情況下磁碟被打滿的情況發生。

樣例配置如下所示：

// logrotate config of sample// rotate every day, and keep for 3 days/var/log/sample.log

業務程序只需要負責監聽SIGHUP信號，收到該信號時再重新打開日誌文件。

3 . 日誌採集

從監控系統的角度來說，日誌收集有2種方式：主動採集和被動接收，兩種方式各有利弊。

主動採集

優點：日誌收集和業務程序分開，互不影響。

缺點：日誌收集需要依賴額外的採集服務，過濾和存儲可能還需要額外配置。

被動接收

優點：業務程序直接將日誌發送至存儲，靈活性強，存儲內容可在業務代碼里控制。

缺點：日誌存儲不穩定的話會影響業務程序的正常運行；反之，日誌量大的話也會壓垮日誌存儲。

但是在建設監控系統初期，日誌存儲還不是很穩定的情況下，還是用主動採集的方式比較穩妥，不影響服務穩定性為主。

Collectd功能確實很強大，它的tail插件也能滿足從文件收集日誌，但是tail插件配置比較複雜而且說明文檔相較於Filebeat來說不是很詳細。

Collectd的其他插件可以採集的數據確實很多，而且也有插件支持將數據發送到Logstash和InfluxDB，但是多數插件的功能我們用不到，而且Elastic Stack中的Beats也能夠很好的收集系統參數等數據，而且跟ELK能很好的兼容。

所以在分別試用了Filebeat和Collectd這2個採集服務後，綜合上述分析決定採用Filebeat來負責從日誌文件中採集日誌。如下所示，Filebeat的配置簡單易懂：

filebeat:spool_size: 1024 # 最大可以攢夠 1024 條數據一起發送出去idle_timeout: "5s" # 否則每 5 秒鐘也得發送一次registry_file: "registry" # 文件讀取位置記錄文件，會放在當前工作目錄下。config_dir: "path/to/configs/contains/many/yaml" # 如果配置過長，可以通過目錄載入方式拆分配置prospectors: # 有相同配置參數的可以歸類為一個 prospector - fields: log_source: "sample" # 類似 logstash 的 add_fields，此處的"log_source"用來標識該日誌來源於哪個項目 paths: - /var/log/system.log # 指明讀取文件的位置 - /var/log/wifi.log include_lines: ["^ERR", "^WARN"] # 只發送包含這些字樣的日誌 exclude_lines: ["^OK"] # 不發送包含這些字樣的日誌 - document_type: "apache" # 定義寫入 ES 時的 _type 值 ignore_older: "24h" # 超過 24 小時沒更新內容的文件不再監聽。 scan_frequency: "10s" # 每 10 秒鐘掃描一次目錄，更新通配符匹配上的文件列表 tail_files: false # 是否從文件末尾開始讀取 harvester_buffer_size: 16384 # 實際讀取文件時，每次讀取 16384 位元組 backoff: "1s" # 每 1 秒檢測一次文件是否有新的一行內容需要讀取 paths: - "/var/log/apache/*" # 可以使用通配符 exclude_files: ["/var/log/apache/error.log"] - input_type: "stdin" # 除了 "log"，還有 "stdin" multiline: # 多行合并 pattern: ^[[:space:]] negate: false match: afteroutput:logstash:hosts: ["localhost:5044"] # The Logstash hosts

Filebeat 發送的日誌，會包含以下欄位：

beat.hostname beat 運行的主機名

beat.name shipper 配置段設置的 name，如果沒設置，等於 beat.hostname

@timestamp 讀取到該行內容的時間

type 通過 document_type 設定的內容

input_type 來自 "log" 還是 "stdin"

source 具體的文件名全路徑

offset 該行日誌的起始偏移量

message 日誌內容

fields 添加的其他固定欄位都存在這個對象裡面

4 . 日誌過濾

Logstash 自2009年誕生經過多年發展，已經是很成熟並且流行的日誌處理框架。Logstash使用管道方式進行日誌的搜集處理和輸出。有點類似*NIX系統的管道命令 input filter output，input 執行完了會執行 filter，然後執行 output。在 Logstash 中，包括了三個階段：輸入input 處理filter（不是必須的） 輸出output。每個階段都由很多的插件配合工作，比如 file、elasticsearch、redis 等等。每個階段也可以指定多種方式，比如輸出既可以輸出到elasticsearch中，也可以指定到stdout在控制台列印。

Codec 是 Logstash 從 1.3.0 版開始新引入的概念（Codec 來自 Coder/decoder兩個單詞的首字母縮寫）。在此之前，Logstash 只支持純文本形式輸入，然後以過濾器處理它。但現在，我們可以在輸入 期處理不同類型的數據，這全是因為有 Codec 設置。所以，這裡需要糾正之前的一個概念。Logstash 不只是一個 input filter output 的數據流，而是一個 input decode filter encode output 的數據流！Codec 就是用來 decode、encode 事件的。Codec 的引入，使得 Logstash 可以更好更方便的與其他有自定義數據格式的運維產品共存，比如 graphite、fluent、netflow、collectd，以及使用msgpack、json、edn 等通用數據格式的其他產品等。

Logstash 提供了非常多的插件（Input plugins、Output plugins、Filter plugins、Codec plugins），可以根據需求自行組合。其中 Filter 插件 Grok 是 Logstash 最重要的插件。Grok 通過正則表達式匹配日誌內容，並將日誌結構化，所以理論上只要正則掌握的夠嫻熟，就能解析任何形式的日誌，非常適合用來解析第三方服務產生的非結構化日誌。但是如果是自己寫的服務，就沒必要將日誌輸出成非結構的，增加寫正則的負擔，所以在上述日誌列印一節中才規定線上的日誌輸出成json形式，方便 Logstash 解析，Logstash 提供 json 的 Filter 插件。

Logstash 的配置文件默認放在 /etc/logstash/conf.d 目錄下，如果需要採集多個項目的日誌，每個項目的 Logstash 配置可能不一樣，那就會在 conf.d 里存放多個配置文件，以每個項目命名方便管理。但是這樣會帶來一個問題，因為 Logstash 會將所有配置文件合并為一個，即一條日誌通過input進入到Logstash後，會經過每個配置文件里的filter和output插件，造成對日誌錯誤的處理和輸出。解決方式是在Filebeat的fileds配置項里增加區分不同項目的field，如果日誌路徑就能區分不同項目的話也可以不用額外加field，用 Filebeat 自帶的source欄位就可以，然後在每個項目對應的 Logstash 配置文件里通過IF標識項目，項目各自的日誌進各自的配置，互不干擾。

下列配置示例是對一個sample服務產生的json日誌，通過Filebeat採集，用json的Filter插件進行解析，並將結果輸出到標準輸出。

input }// The filter part of this file is commented out to indicate that it is// optional.filter ruby { code => "event.set( time ,(Time.parse(event.get( time )).to_f*1000000).to_i)" }}}output }}

5 . 日誌存儲

InfluxDB vs. Elasticsearch

根據 DB-ENGINES 的排名，InfluxDB和Elasticsearch在各自專攻的領域都是NO.1，InfluxDB統治Time Series DBMS，Elasticsearch制霸Search engine，關於它們的原理和使用，各自都有非常詳細的文檔和資料，這裡就不再贅述。

在時序數據方面，InfluxDB表現強勁，Elasticsearch在主要的指標上均遠落於下風：

數據寫入：同時起4個進程寫入8百64萬條數據，Elasticsearch平均為 115,422 條/秒，InfluxDB平均 926,389 條/秒，寫入速度是Elasticsearch的8倍。這種寫入速度的差距隨著數據量的增大保持相對一致。

磁碟存儲：存儲相同的8百64萬條數據，使用默認配置的Elasticsearch需要2.1G，使用針對時序數據配置的Elasticsearch需要517MB，而InfluxDB只需要127MB，壓縮率分別是前兩者的16倍和4倍。

數據查詢：在24h的數據集（8百64萬條數據）里隨機查詢1個小時內的數據，按1分鐘的時間間隔聚合，Elasticsearch和InfluxDB分別單進程執行1000次這種查詢，算耗時的平均值。Elasticsearch耗時4.98ms（201次查詢/秒），InfluxDB耗時1.26ms（794次查詢/秒），查詢速度是Elasticsearch的4倍。隨著數據集的增大，查詢速度之間的差距逐漸拉大，最大相差10倍之多。而且隨著執行查詢的進程數增加，InfluxDB的查詢速度增幅顯著，而且在不同數據集之間的查詢速度基本一致，但是Elasticsearch增幅就不大，而且隨著數據集的增大查詢速度是遞減的。

詳細的比較說明參見：InfluxDB Markedly Outperforms Elasticsearch in Time-Series Data & Metrics Benchmark（http://t.cn/RS1S4ih）。

Elasticsearch強在全文搜索，InfluxDB擅長時序數據，所以還是具體需求具體分析。如果需要保存日誌並經常查詢的，Elasticsearch比較合適；如果只依賴日誌做狀態展示，偶爾查詢，InfluxDB比較合適。

輕鬆籌的業務各有特點，單一選擇Elasticsearch或者InfluxDB都不能很好的查詢日誌和指標展示，所以有必要InfluxDB和Elasticsearch共存。在 Logstash 里配置2個輸出，同一條日誌輸出2份，一份保留全部欄位輸出至 Elasticsearch；另一份過濾文本性的欄位保留指標性的欄位，然後輸出至 InfluxDB。

InfluxDB如果作為Logstash的輸出，有個坑需要注意，就是Logstash的InfluxDB插件支持的時間戳精度太粗，不能精確到納秒，會導致同一個值的時間戳在插入InfluxDB的時候出現異常。因為InfluxDB用measurement名、tag集和時間戳來唯一標識一條記錄。如果插入InfluxDB的一條記錄與已經存在的一條記錄measurement名、tag集和時間戳都相同，那麼filed會是新老兩條記錄的集合，相同field的值會被新記錄覆蓋。 解決方式有2種，一種是增加一個tag來標識新記錄。另一種是手動提升時間戳的精度，提升至微秒，理論上每天可以支持86,400,000,000條不重複的日誌，可以很大程度避免時間戳的重疊，配置如下所示：

// 業務日誌輸出時時間戳格式化到微秒：2006-01-02T15:04:05.999999Z07:00// Logstash的filter根據時間戳轉換filter }

6 . 數據展示

Grafana vs. Kibana

比較Kibana和Grafana，Kibana在圖表展示上沒有Grafana美觀，而且Grafana的配置更加簡單靈活。既然在日誌存儲中決定InfluxDB和Elasticsearch共存，展示上就也需要Kibana和Grafana共同協作，Kibana從Elasticsearch中檢索日誌，Grafana從InfluxDB和Elasticsearch中獲取展示數據。下面2張圖片展示了Grafana在輕鬆籌業務監控上的應用：

7 . 異常報警

即使上述6個環節都建立了，如果沒有報警一切都是沒有意義的，因為不可能每時每刻都盯著曲線看，所以需要設置異常閾值，讓監控系統定時檢查，發現異常立即發送報警通知。

報警的服務有很多，但是數據展示的Grafana自帶報警功能，功能也能滿足我們的報警需求，而且配置簡單，所以規則簡單的報警可以採用Grafana的報警服務。不過Grafana的報警只支持部分資料庫，分別是Graphite, Prometheus, InfluxDB 和 OpenTSDB，所以在Elasticsearch中的日誌報警還需要Elastic Stack的X-Pack。

Condition

如上圖所示，可以設置報警檢查的頻率，報警條件是最近的5分鐘內指定指標的平均值是否大於70，如果這個條件為True則觸發報警。這種報警條件還比較單一，像錯誤數在十分鐘內超過幾次才報警，當前訂單數與昨天同一時間的訂單數比較跌了超過百分之幾就報警，控制報警通知發送的頻率，等等，Grafana就不能滿足了，針對這種報警規則我們自己實現了一個報警引擎，用來滿足這些比較複雜的報警規則。

Notification

Grafana的報警通知只有在狀態轉換時才會觸發，即報警狀態的時候會發送告警通知，如果到恢復之前的一段時間裡條件一直是滿足報警條件的，Grafana不會一直發送通知，直到恢復的時候再發送一次恢復的通知。如果觸發報警，Grafana支持4中通知方式：Email、Slack、Webhook 和 PagerDuty。其中Slack是國外的一種協作工具，類似釘釘，PagerDuty是一個收費的告警平台，所以可選的只剩下Email和Webhook了。下面簡單的介紹如何配置Email和Webhook。

Email

Grafana的郵件配置很簡單，可以利用QQ企業郵箱的smtp服務來發送報警郵件，郵件內容是配置的報警，配置比較簡單：

Webhook

Webhook 就是在觸發報警時，Grafana主動調用配置的http服務，以POST或者PUT方式傳遞json數據。這樣就可以在我們自己開發的http服務里增加額外的通知方式，例如簡訊、微信甚至電話。

Reception

配置了報警通知，不接收不去看也是白搭。一方面我們盡量實現多種通知途徑，比如郵件、微信和簡訊。另一方面需要項目負責人接到報警及時響應，查看問題。

Q&A

Q：Logstash 你們遇到過收集慢和丟日誌的情況嗎？現在你們Logstash收集日誌到什麼規模了？

A：我們目前的日質量大概每天2億條，高峰時候每小時2000萬條左右。Logstash運行的還可以，如果後期遇到手機慢，做簡單的方式是擴機器，先解決問題，再想更好的優化策略。

Q：如果類似於Nginx、MySQL這種日誌，類型增加需要解析每增加一個就要去改Logstash的grok嗎？

A：針對常用的服務，grok已經提供了一些正則的pattern，例如你提到的Nginx、MySQL。目前是每增加一個就需要修改grok，後期可以實現一個UI來提高修改效率。

Q：這個lostash日誌格式轉換怎麼學習？

A：Logstash有很完善的文檔，感興趣的話可以參考：https://www.elastic.co/guide/en/logstash/current/index.html

Q：據說Logstash比較吃內存，fluentd作為EFK組合也經常出現，請問你們有沒有做過選型呢？

A：當時選擇了ELK，就沒有做太多的選型了，Logstash吃內存的問題現在還不是太突出。

Q：日誌的完整性怎麼保證的？怎麼知道沒丟日誌，或丟失了多少日誌？

A：Filebeat和Logstash的輸出插件都有一些重試的策略，但是也免不了日誌丟失。日誌的完整性確實和保證日誌不丟也是我們目前在嘗試解決的問題。

Q：請問監控系統需要考慮高可用嗎？

A：肯定是要考慮高可用，當後期更多的業務依賴監控系統後，就要保證監控系統不掛，查詢要快，實時監控，報警準確等。

輕鬆籌，一億用戶信賴的全民眾籌平台！（https://m2.qschou.com）

Docker精品訓練營

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！