1、Apache Flume
官網：https://flume.apache.org/
Flume 是Apache旗下的一款開源、高可靠、高擴充套件、容易管理、支援客戶擴充套件的資料採集系統。 Flume使用JRuby來構建，所以依賴Java執行環境。
Flume最初是由Cloudera的工程師設計用於合併日誌資料的系統，後來逐漸發展用於處理流資料事件。
Flume設計成一個分散式的管道架構，可以看作在資料來源和目的地之間有一個Agent的網路，支援資料路由。
每一個agent都由Source，Channel和Sink組成。
Source
Source負責接收輸入資料，並將資料寫入管道。Flume的Source支援HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支援監視一個目錄或者檔案，解析其中新生成的事件。
Channel
Channel 儲存，快取從source到Sink的中間資料。可使用不同的配置來做Channel，例如記憶體，檔案，JDBC等。使用記憶體效能高但不持久，有可能丟資料。使用檔案更可靠，但效能不如記憶體。
Sink
Sink負責從管道中讀出資料併發給下一個Agent或者最終的目的地。Sink支援的不同目的地種類包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。
Flume在source和sink端都使用了transaction機制保證在資料傳輸中沒有資料丟失。
Source上的資料可以複製到不同的通道上。每一個Channel也可以連線不同數量的Sink。這樣連線不同配置的Agent就可以組成一個複雜的資料收集網路。透過對agent的配置，可以組成一個路由複雜的資料傳輸網路。
配置如上圖所示的agent結構，Flume支援設定sink的Failover和Load Balance，這樣就可以保證即使有一個agent失效的情況下，整個系統仍能正常收集資料。
Flume中傳輸的內容定義為事件(Event)，事件由Headers(包含元資料，Meta Data)和Payload組成。
Flume提供SDK，可以支援使用者定製開發：
Flume客戶端負責在事件產生的源頭把事件傳送給Flume的Agent。客戶端通常和產生資料來源的應用在同一個程序空間。常見的Flume客戶端有Avro，log4J，syslog和HTTP Post。另外ExecSource支援指定一個本地程序的輸出作為Flume的輸入。當然很有可能，以上的這些客戶端都不能滿足需求，使用者可以定製的客戶端，和已有的FLume的Source進行通訊，或者定製實現一種新的Source型別。
同時，使用者可以使用Flume的SDK定製Source和Sink。似乎不支援定製的Channel。
2、Fluentd
官網：http://docs.fluentd.org/articles/quickstart
Fluentd是另一個開源的資料收集框架。Fluentd使用C/Ruby開發，使用JSON檔案來統一日誌資料。它的可插拔架構，支援各種不同種類和格式的資料來源和資料輸出。最後它也同時提供了高可靠和很好的擴充套件性。Treasure Data, Inc 對該產品提供支援和維護。
Fluentd的部署和Flume非常相似：
Fluentd的架構設計和Flume如出一轍：
Fluentd的Input/Buffer/Output非常類似於Flume的Source/Channel/Sink。
Input
Input負責接收資料或者主動抓取資料。支援syslog，http，file tail等。
Buffer
Buffer負責資料獲取的效能和可靠性，也有檔案或記憶體等不同型別的Buffer可以配置。
Output
Output負責輸出資料到目的地例如檔案，AWS S3或者其它的Fluentd。
Fluentd的配置非常方便，如下圖：
Fluentd的技術棧如下圖：
FLuentd和其外掛都是由Ruby開發，MessgaePack提供了JSON的序列化和非同步的並行通訊RPC機制。
Cool.io是基於libev的事件驅動框架。
FLuentd的擴充套件性非常好，客戶可以自己定製(Ruby)Input/Buffer/Output。
Fluentd從各方面看都很像Flume，區別是使用Ruby開發，Footprint會小一些，但是也帶來了跨平臺的問題，並不能支援Windows平臺。另外採用JSON統一資料/日誌格式是它的另一個特點。相對去Flumed，配置也相對簡單一些。
3、Logstash
https://github.com/elastic/logstash
Logstash是著名的開源資料棧ELK (ElasticSearch, Logstash, Kibana)中的那個L。
Logstash用JRuby開發，所有執行時依賴JVM。
Logstash的部署架構如下圖，當然這只是一種部署的選項。
一個典型的Logstash的配置如下，包括了Input，filter的Output的設定。
幾乎在大部分的情況下ELK作為一個棧是被同時使用的。所有當你的資料系統使用ElasticSearch的情況下，logstash是首選。
4、Chukwa
官網：https://chukwa.apache.org/
Apache Chukwa是apache旗下另一個開源的資料收集平臺，它遠沒有其他幾個有名。Chukwa基於Hadoop的HDFS和Map Reduce來構建(顯而易見，它用Java來實現)，提供擴充套件性和可靠性。Chukwa同時提供對資料的展示，分析和監視。很奇怪的是它的上一次github的更新事7年前。可見該專案應該已經不活躍了。
Chukwa的部署架構如下：
Chukwa的主要單元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相當複雜。由於該專案已經不活躍，我們就不細看了。
5、Scribe
程式碼託管：https://github.com/facebookarchive/scribe
Scribe是Facebook開發的資料(日誌)收集系統。已經多年不維護，同樣的，就不多說了。
6、Splunk Forwarder
官網：http://www.splunk.com/
以上的所有系統都是開源的。在商業化的大資料平臺產品中，Splunk提供完整的資料採金，資料儲存，資料分析和處理，以及資料展現的能力。
Splunk是一個分散式的機器資料平臺，主要有三個角色：
Search Head負責資料的搜尋和處理，提供搜尋時的資訊抽取。
Indexer負責資料的儲存和索引
Forwarder，負責資料的收集，清洗，變形，併發送給Indexer
Splunk內建了對Syslog，TCP/UDP，Spooling的支援，同時，使用者可以透過開發Script Input和Modular Input的方式來獲取特定的資料。在Splunk提供的軟體倉庫裡有很多成熟的資料採集應用，例如AWS，資料庫(DBConnect)等等，可以方便的從雲或者是資料庫中獲取資料進入Splunk的資料平臺做分析。
這裡要注意的是，Search Head和Indexer都支援Cluster的配置，也就是高可用，高擴充套件的，但是Splunk現在還沒有針對Farwarder的Cluster的功能。也就是說如果有一臺Farwarder的機器出了故障，資料收集也會隨之中斷，並不能把正在執行的資料採集任務Failover到其它的Farwarder上。
總結
其中Flume，Fluentd是兩個被使用較多的產品。如果你用ElasticSearch，Logstash也許是首選，因為ELK棧提供了很好的整合。Chukwa和Scribe由於專案的不活躍，不推薦使用。
Splunk作為一個優秀的商業產品，它的資料採集還存在一定的限制，相信Splunk很快會開發出更好的資料收集的解決方案。
End.
1、Apache Flume
官網：https://flume.apache.org/
Flume 是Apache旗下的一款開源、高可靠、高擴充套件、容易管理、支援客戶擴充套件的資料採集系統。 Flume使用JRuby來構建，所以依賴Java執行環境。
Flume最初是由Cloudera的工程師設計用於合併日誌資料的系統，後來逐漸發展用於處理流資料事件。
Flume設計成一個分散式的管道架構，可以看作在資料來源和目的地之間有一個Agent的網路，支援資料路由。
每一個agent都由Source，Channel和Sink組成。
Source
Source負責接收輸入資料，並將資料寫入管道。Flume的Source支援HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支援監視一個目錄或者檔案，解析其中新生成的事件。
Channel
Channel 儲存，快取從source到Sink的中間資料。可使用不同的配置來做Channel，例如記憶體，檔案，JDBC等。使用記憶體效能高但不持久，有可能丟資料。使用檔案更可靠，但效能不如記憶體。
Sink
Sink負責從管道中讀出資料併發給下一個Agent或者最終的目的地。Sink支援的不同目的地種類包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。
Flume在source和sink端都使用了transaction機制保證在資料傳輸中沒有資料丟失。
Source上的資料可以複製到不同的通道上。每一個Channel也可以連線不同數量的Sink。這樣連線不同配置的Agent就可以組成一個複雜的資料收集網路。透過對agent的配置，可以組成一個路由複雜的資料傳輸網路。
配置如上圖所示的agent結構，Flume支援設定sink的Failover和Load Balance，這樣就可以保證即使有一個agent失效的情況下，整個系統仍能正常收集資料。
Flume中傳輸的內容定義為事件(Event)，事件由Headers(包含元資料，Meta Data)和Payload組成。
Flume提供SDK，可以支援使用者定製開發：
Flume客戶端負責在事件產生的源頭把事件傳送給Flume的Agent。客戶端通常和產生資料來源的應用在同一個程序空間。常見的Flume客戶端有Avro，log4J，syslog和HTTP Post。另外ExecSource支援指定一個本地程序的輸出作為Flume的輸入。當然很有可能，以上的這些客戶端都不能滿足需求，使用者可以定製的客戶端，和已有的FLume的Source進行通訊，或者定製實現一種新的Source型別。
同時，使用者可以使用Flume的SDK定製Source和Sink。似乎不支援定製的Channel。
2、Fluentd
官網：http://docs.fluentd.org/articles/quickstart
Fluentd是另一個開源的資料收集框架。Fluentd使用C/Ruby開發，使用JSON檔案來統一日誌資料。它的可插拔架構，支援各種不同種類和格式的資料來源和資料輸出。最後它也同時提供了高可靠和很好的擴充套件性。Treasure Data, Inc 對該產品提供支援和維護。
Fluentd的部署和Flume非常相似：
Fluentd的架構設計和Flume如出一轍：
Fluentd的Input/Buffer/Output非常類似於Flume的Source/Channel/Sink。
Input
Input負責接收資料或者主動抓取資料。支援syslog，http，file tail等。
Buffer
Buffer負責資料獲取的效能和可靠性，也有檔案或記憶體等不同型別的Buffer可以配置。
Output
Output負責輸出資料到目的地例如檔案，AWS S3或者其它的Fluentd。
Fluentd的配置非常方便，如下圖：
Fluentd的技術棧如下圖：
FLuentd和其外掛都是由Ruby開發，MessgaePack提供了JSON的序列化和非同步的並行通訊RPC機制。
Cool.io是基於libev的事件驅動框架。
FLuentd的擴充套件性非常好，客戶可以自己定製(Ruby)Input/Buffer/Output。
Fluentd從各方面看都很像Flume，區別是使用Ruby開發，Footprint會小一些，但是也帶來了跨平臺的問題，並不能支援Windows平臺。另外採用JSON統一資料/日誌格式是它的另一個特點。相對去Flumed，配置也相對簡單一些。
3、Logstash
https://github.com/elastic/logstash
Logstash是著名的開源資料棧ELK (ElasticSearch, Logstash, Kibana)中的那個L。
Logstash用JRuby開發，所有執行時依賴JVM。
Logstash的部署架構如下圖，當然這只是一種部署的選項。
一個典型的Logstash的配置如下，包括了Input，filter的Output的設定。
幾乎在大部分的情況下ELK作為一個棧是被同時使用的。所有當你的資料系統使用ElasticSearch的情況下，logstash是首選。
4、Chukwa
官網：https://chukwa.apache.org/
Apache Chukwa是apache旗下另一個開源的資料收集平臺，它遠沒有其他幾個有名。Chukwa基於Hadoop的HDFS和Map Reduce來構建(顯而易見，它用Java來實現)，提供擴充套件性和可靠性。Chukwa同時提供對資料的展示，分析和監視。很奇怪的是它的上一次github的更新事7年前。可見該專案應該已經不活躍了。
Chukwa的部署架構如下：
Chukwa的主要單元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相當複雜。由於該專案已經不活躍，我們就不細看了。
5、Scribe
程式碼託管：https://github.com/facebookarchive/scribe
Scribe是Facebook開發的資料(日誌)收集系統。已經多年不維護，同樣的，就不多說了。
6、Splunk Forwarder
官網：http://www.splunk.com/
以上的所有系統都是開源的。在商業化的大資料平臺產品中，Splunk提供完整的資料採金，資料儲存，資料分析和處理，以及資料展現的能力。
Splunk是一個分散式的機器資料平臺，主要有三個角色：
Search Head負責資料的搜尋和處理，提供搜尋時的資訊抽取。
Indexer負責資料的儲存和索引
Forwarder，負責資料的收集，清洗，變形，併發送給Indexer
Splunk內建了對Syslog，TCP/UDP，Spooling的支援，同時，使用者可以透過開發Script Input和Modular Input的方式來獲取特定的資料。在Splunk提供的軟體倉庫裡有很多成熟的資料採集應用，例如AWS，資料庫(DBConnect)等等，可以方便的從雲或者是資料庫中獲取資料進入Splunk的資料平臺做分析。
這裡要注意的是，Search Head和Indexer都支援Cluster的配置，也就是高可用，高擴充套件的，但是Splunk現在還沒有針對Farwarder的Cluster的功能。也就是說如果有一臺Farwarder的機器出了故障，資料收集也會隨之中斷，並不能把正在執行的資料採集任務Failover到其它的Farwarder上。
總結
其中Flume，Fluentd是兩個被使用較多的產品。如果你用ElasticSearch，Logstash也許是首選，因為ELK棧提供了很好的整合。Chukwa和Scribe由於專案的不活躍，不推薦使用。
Splunk作為一個優秀的商業產品，它的資料採集還存在一定的限制，相信Splunk很快會開發出更好的資料收集的解決方案。
End.