ELK技術棧介紹
一、 ELK工作棧簡介
1． 簡介
ELKStack 是 Elasticsearch、Logstash、Kibana 三個開源軟件的組合。在實時數據檢索和分析場合，三者通常是配合共用，而且又都先後歸於 Elastic.co 公司名下，故有此簡稱。
ELKStack 在最近兩年迅速崛起，成爲機器數據分析，或者說實時日誌處理領域，開源界的第一選擇。和傳統的日誌處理方案相比，ELK Stack 具有如下幾個優點：
處理方式靈活。Elasticsearch 是實時全文索引，不需要像storm 那樣預先編程才能使用；
配置簡易上手。Elasticsearch 全部採用 JSON 接口，Logstash 是 Ruby DSL 設計，都是目前業界最通用的配置語法設計；
檢索性能高效。雖然每次查詢都是實時計算，但是優秀的設計和實現基本可以達到全天數據查詢的秒級響應；
集羣線性擴展。不管是 Elasticsearch 集羣還是 Logstash 集羣都是可以線性擴展的；
前端操作炫麗。Kibana 界面上，只需要點擊鼠標，就可以完成搜索、聚合功能，生成炫麗的儀表板。
當然，ELK Stack 也並不是實時數據分析界的靈丹妙藥。在不恰當的場景，反而會事倍功半。我自 2014 年初開 QQ 羣交流 ELK Stack，發現網友們對 ELKStack 的原理概念，常有誤解誤用；對實現的效果，又多有不能理解或者過多期望而失望之處。更令我驚奇的是，網友們廣泛分佈在傳統企業和互聯網公司、開發和運維領域、Linux 和 Windows 平臺，大家對非專精領域的知識，一般都缺乏瞭解，這也成爲使用 ELK Stack 時的一個障礙。
二、 Logstash數據採集工具安裝和使用
1． 官方網站
https://www.elastic.co/products/logstash#
2． 簡介
Logstash是一款輕量級的日誌蒐集處理框架，可以方便的把分散的、多樣化的日誌蒐集起來，並進行自定義的處理，然後傳輸到指定的位置，比如某個服務器或者文件。
3． 安裝
下載後直接解壓，就可以了。
4． helloword使用
通過命令行，進入到logstash/bin目錄，執行下面的命令：
logstash -e "" |
可以看到提示下面信息（這個命令稍後介紹），輸入hello world!
可以看到logstash尾我們自動添加了幾個字段，時間戳@timestamp，版本@version，輸入的類型type，以及主機名host。
4.1． 簡單的工作原理
Logstash使用管道方式進行日誌的蒐集處理和輸出。有點類似*NIX系統的管道命令 xxx | ccc | ddd，xxx執行完了會執行ccc，然後執行ddd。
在logstash中，包括了三個階段:
輸入input --> 處理filter（不是必須的） -->輸出output
每個階段都由很多的插件配合工作，比如file、elasticsearch、redis等等。
每個階段也可以指定多種方式，比如輸出既可以輸出到elasticsearch中，也可以指定到stdout在控制檯打印。
由於這種插件式的組織方式，使得logstash變得易於擴展和定製。
4.2． 命令行中常用的命令
-f：通過這個命令可以指定Logstash的配置文件，根據配置文件配置logstash
-e：後面跟着字符串，該字符串可以被當做logstash的配置（如果是“” 則默認使用stdin作爲輸入，stdout作爲輸出）
-l：日誌輸出的地址（默認就是stdout直接在控制檯中輸出）
-t：測試配置文件是否正確，然後退出。
4.3． 配置文件說明![]()
前面介紹過logstash基本上由三部分組成，input、output以及用戶需要才添加的filter，因此標準的配置文件格式如下：
input {...} filter {...} output {...}
在每個部分中，也可以指定多個訪問方式，例如我想要指定兩個日誌來源文件，則可以這樣寫：
input { file { path =>"/var/log/messages" type =>"syslog"} file { path =>"/var/log/apache/access.log" type =>"apache"} }類似的，如果在filter中添加了多種處理規則，則按照它的順序一一處理，但是有一些插件並不是線程安全的。
比如在filter中指定了兩個一樣的的插件，這兩個任務並不能保證準確的按順序執行，因此官方也推薦避免在filter中重複使用插件。
說完這些，簡單的創建一個配置文件的小例子看看：
input { file { #指定監聽的文件路徑，注意必須是絕對路徑 path => "E:/software/logstash-1.5.4/logstash-1.5.4/data/test.log" start_position => beginning } } filter {
} output { stdout {} }
|
日誌大致如下：注意最後有一個空行。
1 hello,this is first line in test.log! 2 hello,my name is xingoo! 3 goodbye.this is last line in test.log! 4 |
執行命令得到如下信息：
5． 最常用的input插件——file。
這個插件可以從指定的目錄或者文件讀取內容，輸入到管道處理，也算是logstash的核心插件了，大多數的使用場景都會用到這個插件，因此這裏詳細講述下各個參數的含義與使用。
5.1． 最小化的配置文件
在Logstash中可以在 input{} 裏面添加file配置，默認的最小化配置如下：
input { file { path => "E:/software/logstash-1.5.4/logstash-1.5.4/data/*" } } filter {
} output { stdout {} } |
當然也可以監聽多個目標文件：
input { file { path => ["E:/software/logstash-1.5.4/logstash-1.5.4/data/*","F:/test.txt"] } } filter {
} output { stdout {} } |
5.2． 其他的配置
另外，處理path這個必須的項外，file還提供了很多其他的屬性：
input { file { #監聽文件的路徑 path => ["E:/software/logstash-1.5.4/logstash-1.5.4/data/*","F:/test.txt"]
#排除不想監聽的文件 exclude => "1.log"
#添加自定義的字段 add_field => {"test"=>"test"}
#增加標籤 tags => "tag1"
#設置新事件的標誌 delimiter => "\n"
#設置多長時間掃描目錄，發現新文件 discover_interval => 15
#設置多長時間檢測文件是否修改 stat_interval => 1
#監聽文件的起始位置，默認是end start_position => beginning
#監聽文件讀取信息記錄的位置 sincedb_path => "E:/software/logstash-1.5.4/logstash-1.5.4/test.txt"
#設置多長時間會寫入讀取的位置信息 sincedb_write_interval => 15
} } filter {
} output { stdout {} } |
其中值得注意的是：
1 path
是必須的選項，每一個file配置，都至少有一個path
2 exclude
是不想監聽的文件，logstash會自動忽略該文件的監聽。配置的規則與path類似，支持字符串或者數組，但是要求必須是絕對路徑。
3start_position
是監聽的位置，默認是end，即一個文件如果沒有記錄它的讀取信息，則從文件的末尾開始讀取，也就是說，僅僅讀取新添加的內容。對於一些更新的日誌類型的監聽，通常直接使用end就可以了；相反，beginning就會從一個文件的頭開始讀取。但是如果記錄過文件的讀取信息，這個配置也就失去作用了。
4sincedb_path
這個選項配置了默認的讀取文件信息記錄在哪個文件中，默認是按照文件的inode等信息自動生成。其中記錄了inode、主設備號、次設備號以及讀取的位置。因此，如果一個文件僅僅是重命名，那麼它的inode以及其他信息就不會改變，因此也不會重新讀取文件的任何信息。類似的，如果複製了一個文件，就相當於創建了一個新的inode，如果監聽的是一個目錄，就會讀取該文件的所有信息。
5 其他的關於掃描和檢測的時間，按照默認的來就好了，如果頻繁創建新的文件，想要快速監聽，那麼可以考慮縮短檢測的時間。
6add_field
就是增加一個字段，例如：
file { add_field => {"test"=>"test"} path => "D:/tools/logstash/path/to/groksample.log" start_position => beginning }
6． Kafka與Logstash的數據採集對接
基於Logstash跑通Kafka還是需要注意很多東西，最重要的就是理解Kafka的原理。
6.1． Logstash工作原理
由於Kafka採用解耦的設計思想，並非原始的發佈訂閱，生產者負責產生消息，直接推送給消費者。而是在中間加入持久化層——broker,生產者把數據存放在broker中，消費者從broker中取數據。這樣就帶來了幾個好處:
1 生產者的負載與消費者的負載解耦
2 消費者按照自己的能力fetch數據
3 消費者可以自定義消費的數量
另外，由於broker採用了主題topic-->分區的思想，使得某個分區內部的順序可以保證有序性，但是分區間的數據不保證有序性。這樣，消費者可以以分區爲單位，自定義讀取的位置——offset。
Kafka採用zookeeper作爲管理，記錄了producer到broker的信息，以及consumer與broker中partition的對應關係。因此，生產者可以直接把數據傳遞給broker，broker通過zookeeper進行leader-->followers的選舉管理；消費者通過zookeeper保存讀取的位置offset以及讀取的topic的partition分區信息。
由於上面的架構設計，使得生產者與broker相連；消費者與zookeeper相連。有了這樣的對應關係，就容易部署logstash-->kafka-->logstash的方案了。
接下來，按照下面的步驟就可以實現logstash與kafka的對接了。
6.2． 啓動kafka
啓動zookeeper：
$zookeeper/bin/zkServer.sh start
啓動kafka：
$kafka/bin/kafka-server-start.sh $kafka/config/server.properties&
6.3． 創建主題
創建主題:
$kafka/bin/kafka-topics.sh --zookeeper 127.0.0.1:2181--create --topic hello --replication-factor 1--partitions 1
查看主題:
$kafka/bin/kafka-topics.sh --zookeeper127.0.0.1:2181 --describe
6.4． 測試環境
執行生產者腳本:
$kafka/bin/kafka-console-producer.sh --broker-list 10.0.67.101:9092 --topic hello
執行消費者腳本，查看是否寫入:
$kafka/bin/kafka-console-consumer.sh--zookeeper 127.0.0.1:2181 --from-beginning--topic hello
6.5． 向kafka中輸出數據
input{ stdin{} } output{ kafka{ topic_id => "hello" bootstrap_servers => "192.168.0.4:9092,172.16.0.12:9092" # kafka的地址 batch_size => 5 codec => plain { format => "%{message}" charset => "UTF-8" } } stdout{ codec => rubydebug } }
|
6.6． 從kafka中讀取數據
logstash配置文件:
input{ kafka { codec => "plain" group_id => "logstash1" auto_offset_reset => "smallest" reset_beginning => true topic_id => "hello" zk_connect => "192.168.0.5:2181" } } output{ stdout{ codec => rubydebug } }
|