當下分佈式系統的 日誌收集、日誌分析、日誌處理、可視化 的熱門技術棧方案固然非 ELK(ElasticSearch、Logstash、Kibana)莫屬,從 L → E → K 構成了一條數據的 Pipeline管道:前端
並且在個人前文《利用 ELK搭建 Docker容器化應用日誌中心》之中,曾利用 ELK 搭建了一條數據管道,用做 Docker容器化應用的日誌中心。數據庫
注: 本文首發於 My 公衆號 CodeSheep ,可 長按 或 掃描 下面的 當心心 來訂閱 ↓ ↓ ↓編程
做爲與數據源 「直接對接」 的 Logstash,位置處於 ELK 數據管道的 最前端,其主要做用是 收集、過濾分析、輸出 各類結構化或者非結構化的原始數據(典型的如日誌數據),原始數據從 「無序變有序」 的重擔就落在了Logstash的肩上了,所以其做用舉足輕重。c#
說到Logstash,不得不說其中的 插件機制,其幾乎全部的功能都是靠插件來實現的,所以靈活易用:ruby
Logstash 插件是使用 Ruby開發的,Logstash 從很早的1.5.0+版開始,其插件模塊和核心模塊便分開維護,其插件使用的是 RubyGems包管理器來管理維護。因此 Logstash插件本質上就是自包含的RubyGems。服務器
RubyGems(簡稱 gems)是一個用於對 Ruby組件進行打包的 Ruby 打包系統。 它提供一個分發 Ruby 程序和庫的標準格式,還提供一個管理程序包安裝的工具。框架
能夠在網址 rubygems.org
上搜索全部Logstash插件:分佈式
關於插件的經常使用操做以下:微服務
能夠在線安裝:工具
bin/plugin install [插件名稱]
固然也能夠將插件提早下載到本地,而後本地安裝:
bin/plugin install path/logstash-xxx-x.x.x.gem
bin/plugin uninstall [插件名稱]
bin/plugin update [插件名稱]
其會將插件更新到最新的版本
Logstash 插件的定義其實使用的就是一套其自定義的 DSL語法,我仍是習慣用圖來講明吧:
從圖中能夠看出主要包含如下幾大部份內容:
該部分通常會用require語法引入以下依賴:
require "logstash/XXX/base" require "logstash/namespace"
須要用 class
語法給每個插件定義一個類,後面我會用實際代碼說明
經過 config_name
語法來給插件取一個名字,這個名字將會用到 Logstash.conf
配置文件的插件配置之中
可使用 config
語法來按需定義任意個配置項。能夠設置配置選項的名字、數據類型、默認值以及是否爲必選項:
舉例:
config :percentage, :validate => :number, :default =>100
:percentage
:定義配置項的名字:validate
:配置指定參數的數據類型,如此處爲 number類型:default
:指定配置項的默認值:required
:用於指定配置項是否必選每一種類型的插件都須要實現一些方法,以下表所示:
插件類型 | 插件方法 |
---|---|
輸入插件 | register、 run |
過濾器插件 | register、 filter |
輸出插件 | register、 receive |
編解碼插件 | register、 encode、 decode |
Logstash 插件所具有的業務處理功能就來源於上述插件方法業務邏輯實現!
好了,理論部分總結到這,下面結合一份Logstash插件定義的源碼來例析一下!
咱們以 Logstash 插件的官網給出的一個 Logstash 過濾器插件 logstash-filter-example 的源碼爲例來進行分析,麻雀雖小,五臟俱全!代碼解析已經標註於圖中,再也不贅述。
固然此處的實例給出的是一個入門實例,畢竟不可能在一篇篇幅有限的文章裏給出一個太過複雜的 Logstash的插件源碼。對照該源碼和上一節的內容,我想應該不難理解Logstash的插件源碼結構了吧。
計劃後續展現一個 根據具體數據需求 來自定義開發一個知足特定需求的 Logstash插件的實例。
做者更多的SpringBt實踐文章在此:
若是有興趣,也能夠抽點時間看看做者一些關於容器化、微服務化方面的文章:
可 長按 或 掃描 下面的 當心心 來訂閱 CodeSheep,獲取更多 務實、能看懂、可復現的 原創文 ↓↓↓