數(shù)據(jù)收集工具對比

目前社區(qū)已經(jīng)不乏大量優(yōu)秀的數(shù)據(jù)收集工具，如有名的 Elastic Stack(Elasticsearch、Logstash、Kibana)中的 Logstash;CNCF 基金會里面有名的 Fluentd;InfluxData 公司 TICK Stack 中的 Telegraf;Google 出品為 Kubernetes 定制的 cAdvisor;Apache 基金會中的頂級項目 Flume。除了早期誕生的諸如 Fluentd、Flume 等項目，其他項目都是為特定的平臺業(yè)務定制而成，然后在隨后的開源中不斷進化，變得更為通用。所以針對特定業(yè)務量身定制一款數(shù)據(jù)收集工具，是一個較為普遍的需求，也是出現(xiàn)如此多“輪子”的主要原因。

讓我們先來看看這幾種知名開源數(shù)據(jù)收集工具有哪些特點。

[[206982]]

Flume: 毋庸置疑，在流式數(shù)據(jù)處理的場景中，F(xiàn)lume 絕對是開源產(chǎn)品中的不二選擇。其架構(gòu)分為 Source、Channel、Sink 三部分，分別負責從上游服務端獲取數(shù)據(jù)、暫存數(shù)據(jù)以及解析并發(fā)送到下游。Flume 尤以靈活的擴展性和強大的容錯處理能力著稱，非常適合在大數(shù)據(jù)量的情況下做數(shù)據(jù)解析、中轉(zhuǎn)以及上下游適配的工作。另一方面，F(xiàn)lume 也有一些缺陷，如解析與發(fā)送都耦合在 Sink 模塊，用戶在編寫 Sink 插件時不得不編寫解析的邏輯，無法復用一些常規(guī)的解析方式;依賴 JVM 運行環(huán)境，作為服務端程序可以接受，但是部署和運行一個數(shù)據(jù)收集客戶端程序則變得相對笨重;Flume 的配置融合了 Channel 部分，基本配置并不簡單，用戶想用起來需要的前置知識較多。

Logstash: 隨著 Elastic Stack 廣受熱捧，Logstash 自然也成為了技術(shù)圈家喻戶曉的工具，而 Logstash 本身的強大功能也確實名副其實，其架構(gòu)分為 Inputs、Filters 以及 Outputs 三部分。Inputs 作為所有輸入端的集合，包含了各類數(shù)據(jù)輸入插件;Filters 包括解析與數(shù)據(jù)轉(zhuǎn)換兩部分的插件集合，其中就包含了大名鼎鼎的 Grok 解析方式，幾乎可以解析所有類型的數(shù)據(jù);Outputs 則是輸出端的集合。毫無疑問，Logstash 幾乎是使用 Elastic Stack 方案時作為數(shù)據(jù)收集的唯一選擇。但是同樣的，Logstash 也是基于 JVM 運行的，作為一個客戶端程序相對較重;當你希望把它作為一個 agent 收集一些機器的基本信息時，它也無能為力。于是除了 Logstash 之外 Elastic Stack 家族中又增加了 beats 這個成員，但是如果僅僅選擇 beats，其功能又太過單薄。

Fluentd: Fluentd 也是數(shù)據(jù)收集界的老牌重量級選手，如果你玩容器、玩 Kubernetes，那么就一定聽說過 CNCF(Cloud Native Computing Foundation)，而 Fluentd 就是其中的一員，成為了容器圈里多數(shù)人日志收集處理的首選。Fluentd 的架構(gòu)與 Logstash 相似，也大致分為輸入、輸出以及中間的處理層，但與之不同的是，其中間的處理層除了包括常規(guī)的 filter(解析) 以及 buffer(數(shù)據(jù)暫存) 以外，還包含了一個 routing(路由) 功能，這是 Fluentd 的一大特色。routing 功能使得 Fluentd 能夠?qū)⒆约悍Q為一個統(tǒng)一的日志管理中間層，將所有的數(shù)據(jù)輸入和輸出管理起來，按照需求將輸入的數(shù)據(jù)路由到一個或多個輸出端。這是一個非常先進的設(shè)計，其他類似的開源軟件往往要寫多份配置文件才能達到這個效果。Fluentd 由 CRuby 實現(xiàn)，性能表現(xiàn)優(yōu)良但依賴 Ruby 環(huán)境;相較于前面兩者，F(xiàn)luentd 插件支持相對較少;其配置也過于復雜，使用門檻較高。

Telegraf/cAdvisor: 這兩款均是 Go 語言編寫的針對系統(tǒng)信息數(shù)據(jù)收集的開源工具，其側(cè)重點在 metric 收集，相較于通用的日志收集和處理，其功能面較窄，但是性能方面均表現(xiàn)優(yōu)異。Telegraf 配合 influxdb，可以讓你對機器各個維度的信息了如指掌;而 cAdvisor 更是 Kubernetes 的親兒子，處理容器資源信息幾無敵手。但是這兩款工具并無意于發(fā)力通用數(shù)據(jù)收集的功能，功能上可能無法滿足一些日志收集的場景。

了解了以上這些開源軟件的特點后，下面我們開始深入介紹構(gòu)建一款數(shù)據(jù)收集工具會遇到哪些設(shè)計與挑戰(zhàn)，以此為你的業(yè)務量身定制。

數(shù)據(jù)收集工具設(shè)計

架構(gòu)設(shè)計

主流數(shù)據(jù)收集工具的主架構(gòu)基本分為 reader、parser，以及 sender 三部分，如圖 1 所示。除了這三個日志收集常規(guī)組成部分，還應該包含可選模塊，如基于解析過后的數(shù)據(jù)轉(zhuǎn)換 (filter/transformer) 以及數(shù)據(jù)暫存管道 (Channel/Buffer)。為了盡可能復用，每個組成部分都應該是插件式的，可以編寫不同類型插件并且靈活地組裝。Channel/Buffer 部分也應該提供基于內(nèi)存或者基于磁盤的選擇。

圖 1 數(shù)據(jù)收集架構(gòu)設(shè)計

對于 Reader、Parser、Sender 等插件共同組裝的業(yè)務數(shù)據(jù)收集單元，我們稱之為一個運行單元 (Runner)，數(shù)據(jù)收集工具必須可以同時運行多個 Runner，且每個 Runner 可以支持更新。

更新可以通過多種方式實現(xiàn)，最常規(guī)的是手動更新配置然后重啟;更好的設(shè)計是支持熱更新，不需要重啟，自動識別配置文件的變化;還可以設(shè)計一個漂亮的 web 界面做配置的變更，以此引導用戶使用并解決數(shù)據(jù)收集配置復雜、用戶使用門檻高的難題。所以在整體架構(gòu)之上還應該構(gòu)建一個簡單的 API 層，支持 web 界面的功能。

語言選擇

數(shù)據(jù)收集屬于輕量級的 agent 服務，一般選擇的語言為 C/C++ 或者近年來特別火熱的 Go，而 Go 語言已經(jīng)成為這類數(shù)據(jù)收集工具編寫的大眾選擇，如 Logstash 新開發(fā)的 beats 工具、Telegraf、cAdvisor 等等，均使用 Go 語言開發(fā)。

社區(qū)已經(jīng)有很多文章描述使用 Go 語言的好處，在此就不再贅述?？傮w而言用 Go 語言開發(fā)門檻較低，性能優(yōu)良，支持跨多種操作系統(tǒng)平臺，部署也極為簡便。

分模塊設(shè)計

數(shù)據(jù)讀取模塊(Reader)

顧名思義，數(shù)據(jù)讀取模塊負責從不同數(shù)據(jù)源中讀取數(shù)據(jù)，設(shè)計 Reader 模塊的時候，需要支持插件式數(shù)據(jù)源接入，且將接口設(shè)計得足夠簡單，方便大家一同貢獻更多的讀取數(shù)據(jù)源驅(qū)動。

自定義數(shù)據(jù)源，最基本的只需要實現(xiàn)如下兩個方法即可。

ReadLine() string  
SyncMeta() error 

從數(shù)據(jù)來源上分類，數(shù)據(jù)讀取大致可分為從文件讀取、從數(shù)據(jù)存儲服務端讀取以及從消息隊列中讀取三類。

每一類 Reader 均在發(fā)送成功后通過 SyncMeta() 函數(shù)記錄讀取的位置，保證數(shù)據(jù)不會因為 runner 意外中斷而丟失。

從文件讀取數(shù)據(jù) 最為常見，針對文件的不同 rotate 方式，有不同的讀取模式，主要分為三類：

• file 模式：使用 file 模式的經(jīng)典日志存儲方式類似于 nginx 的日志 rotate 方式，日志名稱是固定的，如access.log，rotate 時直接 move 成新的文件如access.log.1，新的數(shù)據(jù)仍然寫入到access.log。即我們永遠只針對access.log這一個固定名稱的文件進行收集。而檢測文件是否 rotate 的標志是文件的 inode 號，在 windows 下則是 fd 的屬性編號。當文件 rotate 后，則從文件頭開始讀取。
• dir 模式：使用 dir 模式的經(jīng)典日志存儲方式為整個文件夾下存儲單個服務的業(yè)務日志，文件夾下的日志通常有統(tǒng)一前綴，后綴為時間戳，根據(jù)日志的大小 rotate 到新的文件。如配置的文件夾為 logdir，下面的文件為 logdir/a.log.20170621, logdir/a.log.20170622, logdir/a.log.20170623, …。每次分割后新命名文件并以時間戳為后綴，并且該文件夾下只有這一個服務。dir 模式首先會對文件夾下文件整體排序，依次讀取各個文件，讀完最后一個文件后會查找時間 (文件 ctime) 更新文件并重新排序，依次循環(huán)。dir 模式應該將多個文件數(shù)據(jù)串聯(lián)起來，即數(shù)據(jù)讀取過程中 a.log.20170621 中最后一行的下一行就是 a.log.20170622 的第一行。該模式下自然還包括諸如文件前綴匹配、特定后綴忽略等功能。
• tailx 模式：以通配的路徑模式讀取，讀取所有被通配符匹配上的日志文件，對于單個日志文件使用 file 模式不斷追蹤日志更新，例如匹配路徑的模式串為 /home/*/path/*/logdir/*.log*, 此時會展開并匹配所有符合該表達式的文件，并持續(xù)讀取所有有數(shù)據(jù)追加的文件。每隔一定時間，重新獲取一遍模式串，添加新增的文件。

除此之外，還應支持包括多文件編碼格式支持、讀取限速等多種功能。

從數(shù)據(jù)存儲服務中讀取數(shù)據(jù)，可以采用時間戳策略，在諸如 MongoDB、MySQL 中記錄的數(shù)據(jù)，包含一個時間戳字段，每次讀取數(shù)據(jù)均按這個時間戳字段排序，以此獲得新增的數(shù)據(jù)或者數(shù)據(jù)更新。另一方面，需要為用戶設(shè)計類似定時器等策略，方便用戶多次運行，不斷同步收集服務器中的數(shù)據(jù)。

從消息隊列中讀取數(shù)據(jù)，這個最為簡單，直接從消息隊列中消費數(shù)據(jù)即可。注意記錄讀取的 Offset，防止數(shù)據(jù)丟失。

解析模塊 (Parser)

解析模塊負責將數(shù)據(jù)源中讀取的數(shù)據(jù)解析到對應的字段及類型，目前常見的解析器包括：

• csv parser: 按照分隔符解析成對應字段和類型，分隔符可以自定義，如常見的制表符 (\t)、空格 ( )、逗號 (,) 等等。
• json parser: 解析 json 格式的數(shù)據(jù)，json 是一種自帶字段名稱及類型的序列化協(xié)議，解析 json 格式僅需反序列化即可。
• 基于正則表達式 (grok) parser: Logstash grok 解析非常強大，但是它并不指定類型，而 Telegraf 做了一個增強版的 grok 解析器，除了基本的正則表達式和字段名稱，還能標志數(shù)據(jù)類型，基本上能標志數(shù)據(jù)類型的 grok 解析器已經(jīng)是一個完備的數(shù)據(jù)解析器了，可以解析幾乎所有數(shù)據(jù)。當然，類型解析是相對復雜的功能，可能涉及到具體業(yè)務，如時間類型等。
• raw parser: 將讀取到的一行數(shù)據(jù)作為一個字段返回，簡單實用。
• nginx/apache parser: 讀取 nginx/apache 等常見配置文件，自動生成解析的正則表達式，解析 nginx/apache 日志。

除了以上幾種內(nèi)置的解析器，同 Reader 一樣，你也需要實現(xiàn)自定義解析器的插件功能，而 Parser 極為簡單，只需要實現(xiàn)最基本的 Parse 方法即可。

Parse(lines []string) (datas []sender.Data, err error) 

每一種 Parser 都是插件式結(jié)構(gòu)，可以復用并任意選擇。在不考慮解析性能的情況下，上述幾種解析器基本可以滿足所有數(shù)據(jù)解析的需求，將一行行數(shù)據(jù)解析為帶有 Schema(具備字段名稱及類型)的數(shù)據(jù)。但是當你希望對某個字段做操作時，純粹的解析器可能不夠用。于是作為補充，數(shù)據(jù)收集工具還需要提供 Transformer/Filter 的功能。

Transformer

Transformer 是 Parser 的補充，針對字段進行數(shù)據(jù)變化。

舉例來說，如果你有個字段想做字符串替換，比如將所有字段名稱為”name”的數(shù)據(jù)中，值為”Tom”的數(shù)據(jù)改為”Tim”，那么可以添加一個字符串替換的 Transformer，針對”name”這個字段做替換。

又比如說，你的字段中有個”IP”，你希望將這個 IP 解析成運營商、城市等信息，那么你就可以添加一個 Transformer 做這個 IP 信息的轉(zhuǎn)換。

當然，Transformer 應該可以多個連接到一起連動合作。

設(shè)計 Transformer 模塊是一件有趣而富有挑戰(zhàn)的事情，這涉及到 Tranformer 功能多樣性帶來的 3 個問題：

1. 多樣的功能必然涉及到多樣的配置，如何將不同的配置以優(yōu)雅而統(tǒng)一的方式傳達到插件中?
2. 多樣的功能也涉及到不同功能的描述，如何將功能描述以統(tǒng)一的形式表達給用戶，讓用戶選擇相應的配置?
3. 如何將上述兩個問題盡可能簡單地解決，讓用戶編寫 Transformer 插件時關(guān)注盡可能少的問題?

這里我們留個懸念，感興趣的朋友可以閱讀 logkit Transformer 相關(guān) (https://github.com/qiniu/logkit/tree/develop/transforms) 的源碼尋求答案，筆者后續(xù)也會在 logkit 的 wiki 頁面中描述。

Channel

經(jīng)過解析和變換后的數(shù)據(jù)可以認為已經(jīng)處理好了，此時數(shù)據(jù)會進入待發(fā)送隊列，即 Channel 部分。Channel 的好壞決定了一個數(shù)據(jù)收集發(fā)送工具的性能及可靠程度，是數(shù)據(jù)收集工具中最具技術(shù)含量的一環(huán)。

數(shù)據(jù)收集工具，顧名思義，就是將數(shù)據(jù)收集起來，再發(fā)送到指定位置，而為了將性能最優(yōu)化，我們必須把收集和發(fā)送解耦，中間提供一個緩沖帶，而 Channel 就是負責數(shù)據(jù)暫存的地方。有了 Channel，讀取和發(fā)送就解耦了，可以利用多核優(yōu)勢，多線程發(fā)送數(shù)據(jù)，提高數(shù)據(jù)吞吐量。

圖 2 ft sender

一種設(shè)計思路是把整個 Channel，包括多線程發(fā)送做成一個框架，封裝成一個特殊的 sender，我們稱這個特殊的 sender 為”ft sender”。其架構(gòu)如圖 2 所示，ft sender 與其他 sender 一樣也提供了 Send() 方法，解析完畢后的數(shù)據(jù)調(diào)用 Send 方法實際上就是將數(shù)據(jù)傳入到 Channel 中，然后再由 ft sender 處理多線程發(fā)送邏輯，將從隊列中取出的數(shù)據(jù)交由實際的 sender 多線程發(fā)送。

同時需要為用戶提供磁盤和內(nèi)存兩大隊列方式選擇。

如果追求最高的可靠性，就使用磁盤隊列，數(shù)據(jù)會暫存到本地磁盤中，發(fā)送后自動刪除，即使突然宕機也不怕丟失數(shù)據(jù)。

如果追求更高的性能，可以使用內(nèi)存隊列，其實現(xiàn)方式就是 Go 語言的 Channel 機制，穩(wěn)定而簡單，在關(guān)停過程中也需要將 Channel 中的數(shù)據(jù)落地到磁盤，在隨后重新啟動時載入，正常使用過程中也沒有數(shù)據(jù)丟失的風險。得益于 Go 語言的同步 Channel 機制，甚至可以把內(nèi)存隊列的大小設(shè)置為 0，以此實現(xiàn)多線程發(fā)送，這樣使用內(nèi)存隊列即使宕機，也沒有了數(shù)據(jù)丟失的風險。

除了正常地作為待發(fā)送數(shù)據(jù)的等待隊列以外，Channel 還可以具有如下一些非常有趣而實用的功能：

錯誤數(shù)據(jù)篩選

并不是所有解析完畢的數(shù)據(jù)發(fā)送到服務端就一定是正確的，有時服務端指定的數(shù)據(jù)格式和解析完畢的格式存在出入，或者數(shù)據(jù)中含有一些非法字符等情況，則數(shù)據(jù)不能發(fā)送成功。此時，如果一批數(shù)據(jù)中只有一條這樣錯誤的數(shù)據(jù)，就很容易導致這一整批都失敗。

錯誤數(shù)據(jù)篩選的作用就在于，把這一整批數(shù)據(jù)中對的數(shù)據(jù)篩選出來，留下錯誤的數(shù)據(jù)，將正確的發(fā)送出去。

做法很簡單，當發(fā)送時遇到服務端返回存在格式錯誤的數(shù)據(jù)時，將這一批數(shù)據(jù)平均拆分為兩批(二分)，再放入隊列，等待下次發(fā)送。再遇到錯誤時則再拆分，這樣不斷二分，直到一個批次中只有一條數(shù)據(jù)，且發(fā)送失敗，那我們就找到了這個錯誤數(shù)據(jù)，可以選擇丟棄或記錄。

借助隊列，我們很容易就能將錯誤數(shù)據(jù)篩選出來。

包拆分(大包拆小包)

包拆分的由來是服務端不可能無限制開放每個批次數(shù)據(jù)傳輸?shù)拇笮?，出于服務器性能、傳輸性能等原因，總有會有一些限制?/p>

當一個批次的數(shù)據(jù)過大時，就會導致傳輸失敗。此時的做法與錯誤篩選的方法相似，只要將包二分即可，如果還是太大就再次二分，以此類推。

限速

限速的功能最容易理解，數(shù)據(jù)統(tǒng)統(tǒng)經(jīng)過 Channel，那么只要限制這個 Channel 傳輸介質(zhì)的速度即可。例如磁盤隊列，只需要限制磁盤的 IO 讀寫速度;內(nèi)存隊列則限制隊列大小以此達到限速的目的。

常見的流量控制的算法有漏桶算法(Leaky bucket)(https://en.wikipedia.org/wiki/Leaky_bucket)和令牌桶算法(Token bucket)(https://en.wikipedia.org/wiki/Token_bucket) 兩種，比較推薦采用令牌桶算法實現(xiàn)該功能，感興趣的朋友可以閱讀一下 logkit 的 rateio 包 (https://github.com/qiniu/logkit/tree/develop/rateio)。

Sender

Sender 的主要作用是將隊列中的數(shù)據(jù)發(fā)送至 Sender 支持的各類服務，一個最基本的實現(xiàn)同樣應該設(shè)計得盡可能簡單，理論上僅需實現(xiàn)一個 Send 接口即可。

Send([]Data) error 

那么實現(xiàn)一個發(fā)送端有哪些注意事項呢?

多線程發(fā)送：多線程發(fā)送可以充分利用 CPU 的多核能力，提升發(fā)送效率，這一點我們在架構(gòu)設(shè)計中通過設(shè)計 ft sender 作為框架解決了該問題。

錯誤處理與等待：服務端偶爾出現(xiàn)一些異常是很正常的事情，此時就要做好不同錯誤情況的處理，不會因為某個錯誤而導致程序出錯，另外一方面，一旦發(fā)現(xiàn)出錯應該讓 sender 等待一定時間再發(fā)送，設(shè)定一個對后端友好的變長錯誤等待機制也非常重要。一般情況下，可以采用隨著連續(xù)錯誤出現(xiàn)遞增等待時間的方法，直到一個最頂峰(如10s)，就不再增加，當服務端恢復后再取消等待。

數(shù)據(jù)壓縮發(fā)送：帶寬是非常珍貴的資源，通常服務端都會提供 gzip 壓縮的數(shù)據(jù)接收接口，而 sender 利用這些接口，將數(shù)據(jù)壓縮后發(fā)送，能節(jié)省大量帶寬成本。

帶寬限流：通常情況下數(shù)據(jù)收集工具只是機器上的一個附屬程序，主要資源如帶寬還是要預留給主服務，所以限制 sender 的帶寬用量也是非常重要的功能，限流的方法可以采用前面 Channel 一節(jié)提到的令牌桶算法。

字段填充 (UUID/timestamp)：通常情況下收集的數(shù)據(jù)信息可能不是完備的，需要填充一些信息進去，如全局唯一的 UUID、代表收集時間的 timestamp 等字段，提供這些字段自動填充的功能，有利于用戶對其數(shù)據(jù)做唯一性、時效性等方面的判斷。

字段別名：解析后的字段名稱中經(jīng)常會出現(xiàn)一些特殊字符，如”$”、”@”等符號，如果發(fā)送的服務端不支持這些特殊字符，就需要提供重命名功能，將這些字段映射到一個別的名稱。

字段篩選：解析后的字段數(shù)據(jù)未必都需要發(fā)送，這時如果能提供一個字段篩選的功能，就可以方便用戶選擇去掉一些無用字段，并節(jié)省傳輸?shù)某杀?。也可以? Transformer 中提供類似 discard transformer 的功能，將某個字段去掉。

類型轉(zhuǎn)換：類型轉(zhuǎn)換是一個說來簡單但是做起來非常繁瑣的事情，不只是純粹的整型轉(zhuǎn)換成浮點型，或者字符串轉(zhuǎn)成整型這么簡單，還涉及發(fā)送到的服務端支持的一些特殊類型，如date時間類型等，更多的類型轉(zhuǎn)換實際上相當于最佳實踐，能夠做好這些類型轉(zhuǎn)換，就會讓用戶體驗得到極大提升。

簡單、簡單、簡單：除了上述這些，剩下的就是盡可能的讓用戶使用簡單。假設(shè)我們要寫一個 mysql sender，mysql 的數(shù)據(jù)庫和表如果不存在，可能數(shù)據(jù)會發(fā)送失敗，那就可以考慮提前創(chuàng)建;又比如數(shù)據(jù)如果有更新，那么就需要將針對這些更新的字段去更新服務的 Schema 等等。

Metrics

除了基本的自定義的數(shù)據(jù)收集，數(shù)據(jù)收集工具作為一個機器的 agent，還可以采集機器的基本數(shù)據(jù)，例如 CPU、內(nèi)存、網(wǎng)絡(luò)等信息，通過這些信息，可以全面掌控機器的狀態(tài)。

具體的內(nèi)容可以參考 logkit 文檔：Runner 之系統(tǒng)信息采集配置。

至此，一個完整的數(shù)據(jù)收集工具的設(shè)計要點已經(jīng)介紹完畢。

我們已經(jīng)開源的 logkit 正是按照這樣的設(shè)計實現(xiàn)的，logkit 集合了多種開源數(shù)據(jù)收集工具的優(yōu)點，聚焦易用性，致力于打造產(chǎn)品級別的開源軟件。

數(shù)據(jù)收集工具 logkit

logkit(https://github.com/qiniu/logkit) 是七牛大數(shù)據(jù)團隊開源的一個通用的日志收集工具，可以從多種不同的數(shù)據(jù)源中采集數(shù)據(jù)，并對數(shù)據(jù)進行一系列的解析、變換、裁減，最終發(fā)送到多種不同的數(shù)據(jù)下游，其中就包括了 七牛的大數(shù)據(jù)平臺 Pandora。除了基本的數(shù)據(jù)收集、解析以及發(fā)送功能之外，logkit 集合了多種同類開源軟件的優(yōu)勢，涵蓋了容錯、并發(fā)、熱加載、斷點續(xù)傳等高級功能，更提供了頁面方便用戶配置、監(jiān)控以及管理自己的數(shù)據(jù)收集業(yè)務，是一款產(chǎn)品級別的開源軟件。

目前支持的數(shù)據(jù)源包括：

• File Reader: 讀取文件中的日志數(shù)據(jù)，如 nginx/apache 服務日志文件、業(yè)務日志等。
• Elasticsearch Reader: 全量導出 Elasticsearch 中的數(shù)據(jù)。
• MongoDB Reader: 同步 MongoDB 中的數(shù)據(jù)。
• MySQL Reader: 同步 MySQL 中的數(shù)據(jù)。
• MicroSoft SQL Server Reader: 同步 Microsoft SQL Server 中的數(shù)據(jù)。
• Kafka Reader: 導出 Kafka 中的數(shù)據(jù)。
• Redis Reader: 導出 Redis 中的數(shù)據(jù)。

目前支持發(fā)送到的服務包括 Pandora、ElasticSearch、InfluxDB、MongoDB 以及本地文件五種，近期還會支持發(fā)送到 Kafka 以及發(fā)送到某個 HTTP 地址。

• Pandora Sender: 發(fā)送到 Pandora(七牛大數(shù)據(jù)處理平臺) 服務端。
• Elasticsearch Sender: 發(fā)送到 Elasticsearch 服務端。
• File Sender: 發(fā)送到本地文件。
• InfluxDB Sender: 發(fā)送到 InfluxDB 服務端。
• MongoDB Sender: 后發(fā)送到 MongoDB 服務端。

而在這已經(jīng)實現(xiàn)的有限的幾個發(fā)送端中，我們是這么設(shè)計的使用場景：

• 如果收集數(shù)據(jù)是為了監(jiān)控，那么可以使用 InfluxDB Sender，發(fā)送到開源的 InfluxDB 服務端，實現(xiàn)實時數(shù)據(jù)監(jiān)控。
• 如果收集數(shù)據(jù)是為了搜索查看，那么可以使用 Elasticsearch Sender，發(fā)送到開源的 Elasticsearch 服務端，進行日志查詢。
• 如果收集數(shù)據(jù)是為了計量統(tǒng)計或者其他一些涵蓋復雜的增刪改查需求的場景，那么就可以使用 MongoDB Sender，在本地對數(shù)據(jù)進行聚合，再發(fā)送到開源的 MongoDB 服務中。

而發(fā)送到 七牛的 Pandora 服務 中，不僅能涵蓋上述全部場景，還提供了大量可以快速發(fā)掘數(shù)據(jù)價值的實際應用場景的使用模板，同時還可以利用七牛成本較低的云存儲服務對數(shù)據(jù)進行持久備份。

目前 logkit 支持的收集端和發(fā)送端并不多，非常歡迎大家來貢獻更多的收集 / 發(fā)送端。

量身定制

再回過頭來聊聊量身定制的話題，本文描述了一個數(shù)據(jù)收集工具打造的完整過程，我們深知量身定制一個數(shù)據(jù)收集工具有多么重要，而量身定制也是 logkit 的一大特點。logkit 架構(gòu)中的每個組成部分(Reader、Parser、Sender、Transformer、Channel 等)都是一個 GO 語言的 package，你完全可以用 logkit 中的包，自己寫主函數(shù)，從而定制一個專屬的收集工具。我們提供了代碼案例 (https://github.com/qiniu/logkit/tree/develop/samples) ，方便你親自實踐。

優(yōu)勢

總體而言，logkit 有如下優(yōu)勢：

• GO 語言編寫，性能優(yōu)良，資源消耗低，跨平臺支持。
• Web 支持，提供 頁面 對數(shù)據(jù)收集、解析、發(fā)送過程可視化
• 插件式架構(gòu)，擴展性強，使用靈活，易于復用。
• 定制化能力強，可以僅使用部分 logkit 包，以此定制專屬收集工具。
• 配置簡單，易于上手，可通過 頁面 進行操作管理
• 原生中文支持，沒有漢化煩惱
• 功能全面，涵蓋了包括 grok 解析、metric 收集、字段變化 (transform) 在內(nèi)的多種開源軟件特點
• 生態(tài)全面，數(shù)據(jù)發(fā)送到七牛的 Pandora 大數(shù)據(jù)平臺支持包括時序數(shù)據(jù)庫、日志檢索以及壓縮永久存儲等多種數(shù)據(jù)落地方案。

下面讓我們來實踐一下，看看 logkit 在實戰(zhàn)中是什么樣子。

logkit 實戰(zhàn)

下載

編譯完后的 logkit 是一個 Go 的二進制包，你可以在 logkit 的 Download 頁面 (https://github.com/qiniu/logkit/wiki/Download) 找到對應操作系統(tǒng)的 Release 版本。

也可以參照 logkit 源碼編譯指南，從代碼層面定制自己的專屬 logkit。

啟動

logkit 部署非常簡單，將這個 binary 放在系統(tǒng) PATH 路徑中就算部署完成了，推薦使用諸如 supervisor 等進程管理工具進行管理。

啟動 logkit 工具，可以使用默認的配置文件，執(zhí)行如下命令即可。

logkit -f logkit.conf 

配置文件中默認開啟了 3000 端口，初次使用可以通過瀏覽器打開 logkit 配置頁面，配置 runner 并調(diào)試讀取、解析和發(fā)送方式，瀏覽器訪問的地址是 http://127.0.0.1:3000 。

配置

圖 3 logkit 首頁

打開網(wǎng)址后看到如圖 3 所示的 logkit 配置助手首頁，這個頁面會清晰地展示目前所有的 logkit Runner 運行狀態(tài)，包括讀取速率、發(fā)送速率、成功 / 失敗數(shù)據(jù)條數(shù)，以及一些錯誤日志。還可以在這里修改和刪除 Runner。

點擊左上角【增加 Runner】按鈕，可以添加新的 logkit Runner。

圖 4 數(shù)據(jù)源 Reader 配置

如圖 4 所示，新增 Runner 的第一步就是配置數(shù)據(jù)源，為了盡可能方便用戶，logkit 將絕大多數(shù)選項都預設(shè)了默認值，用戶只需要根據(jù)頁面提示填寫黃色的必填項即可。

按頁面步驟依次配置數(shù)據(jù)源、解析方式、以及發(fā)送方式。

圖 5 解析數(shù)據(jù)

如圖 5 所示，在配置解析方式的頁面還可以根據(jù)配置嘗試解析樣例數(shù)據(jù)，這個頁面可以根據(jù)你的實際數(shù)據(jù)非常方便地調(diào)試解析方式。

圖 6 字段變化 Transformer

如圖 6 所示，除了解析以外，還可以針對解析出來的某個字段內(nèi)容做數(shù)據(jù)變換(Transform)，即上一章中描述的 Transformer。可以像管道一樣拼接多個 Transformer，做多重字段變化。

最后配置完發(fā)送方式，可以在如圖 7 所示的頁面做二次確認。

圖 7 確認并添加頁

在二次確認的頁面中，可以直接修改表達內(nèi)容也可以返回上一步修改，最終點擊添加 Runner 即可生效。

到這里，一個復雜的數(shù)據(jù)收集工作就完成了，怎么樣，就是這么簡單，快來實際體驗一下吧!