1、認知前提
老生常談，夯實基礎認知。
ELK Stack是三個開源項目的首字母縮寫：Elasticsearch，Logstash和Kibana。 它們可以共同構成一個日志管理平台。
Elasticsearch：搜尋和分析引擎。
Logstash：伺服器端資料處理管道，它同時從多個源中提取資料，對其進行轉換，然後将其發送到Elasticsearch存儲。
Kibana：圖表和圖形來可視化資料ES中資料。
Beats後來出現，是一個輕量級的資料傳輸帶（data shipper）。 Beats的引入将ELK Stack轉換為Elastic Stack。
2、啥是Grok？
Grok是Logstash中的過濾器，用于将非結構化資料解析為結構化和可查詢的資料。
它位于正規表達式之上，并使用文本模式比對日志檔案中的行。
下文分析你會看到，使用Grok在有效的日志管理方面大有裨益！
一圖勝千言。
如果沒有Grok，當日志從Logstash發送到Elasticsearch并在Kibana中呈現時，它隻會出現在消息值中。
在這種情況下，查詢有意義的資訊很困難，因為所有日志資料都存儲在一個key中。
白話文——Grok的目的：
将如上一個key對應的一長串非結構的Value，轉成多個結構化的Key對應多個結構化的Value。
3、日志資料非結構化 VS 結構化
3.1 非結構化原始日志資料
localhost GET / v2 / applink / 5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0
1
如果仔細檢視原始資料，可以看到它實際上由不同的部分組成，每個部分用空格分隔符分隔。
對于更有經驗的開發人員，您可以猜測每個部分的含義，以及來自API調用的日志消息。
從資料分析的角度：非結構化資料不便于檢索、統計、分析。
3.2 結構化日志資料
localhost == environment （基礎環境資訊）
GET == method （請求方式）
/v2/applink/5c2f4bb3e9fda1234edc64d == url （URL位址）
400 == response_status （響應狀态碼）
46ms == response_time （響應時間）
5bc6e716b5d6cb35fc9687c0 == user_id （使用者Id）
2
3
4
5
6
如上切分的中間轉換正是借助grok實作。非結構化資料變成結構化資料後才凸顯價值，檢索、統計、分析等都變得非常簡單了。
4、Grok模式
4.1 内置模式
Logstash提供了超過100種内置模式，用于解析非結構化資料。
對于常見的系統日志，如apache，linux，haproxy，aws等，内置模式是剛需+标配。
但是，當您擁有自定義日志時會發生什麼？ 必須建構自己的自定義Grok模式。
4.2 自定義模式
建構自己的自定義Grok模式需要反複試驗。 推薦使用Grok Debugger和Grok Patterns做驗證。
Grok Debugger位址：
https://grokdebug.herokuapp.com/，注意：需要梯子。
Grok Patterns位址：
https://github.com/elastic/logstash/blob/v1.4.2/patterns/grok-patterns請注意，Grok模式的文法是：％{SYNTAX：SEMANTIC}
實踐一把：
步驟1：進入Grok Debugger中的Discover頁籤。
期望這個工具可以自動生成Grok模式，但它沒有太大幫助，因為它隻發現了如下兩個比對。
步驟2：借助Elastic的github上的文法在Grok Debugger上構模組化式。
步驟3：Grok Debugger實操驗證。
如上截圖：
輸入待比對的源非結構化資料：
localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0
輸入比對模式：
%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}
輸出結構化資料解析後比對結果：
{
"environment": [
[
"localhost"
]
],
"method": [
"GET"
"url": [
"/v2/applink/5c2f4bb3e9fda1234edc64d"
"response_status": [
"400"
"BASE10NUM": [
"response_time": [
"46ms"
"user_id": [
"5bc6e716b5d6cb35fc9687c0"
]
}
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
在使用不同的文法後，終于能夠以期望的方式建構日志資料。
5、grok內建到Logstash filter環節驗證
步驟1：切換路徑。
在安裝ELK Stack的伺服器上，切換到Logstash配置。
sudo vi /etc/logstash/conf.d/logstash.conf
步驟2：拷貝核心Grok配置， 更新Logstash.conf。
将驗證後的grok部分貼過來。
注意：核心三段論結構。
1、輸入：日志路徑；
2、中間處理ETL：grok解析
3、輸出：ES。
input {
file {
path => "/your_logs/*.log"
}
filter{
grok {
match => { "message" => "%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}"}
output {
elasticsearch {
hosts => [ "localhost:9200" ]
步驟3：重新開機。
儲存更改後，重新啟動Logstash并檢查其狀态以確定它仍然有效。
sudo service logstash restart
sudo service logstash status
6、Kibana可視化驗證
最後，為了確定更改生效，請務必重新整理Kibana中Logstash寫入的Elasticsearch索引！
Grok能夠自動将日志資料映射到Elasticsearch。 這樣可以更輕松地管理日志并快速實作查詢、統計、分析操作。
7、小結
這是一篇翻譯文章。當近期在嘗試寫類似解析文章的時候，發現國外已經有講解的非常透徹的文章。
是以，在原文基礎上做了實踐驗證和通俗化的解讀，希望對你有幫助。
劃重點：Grok Debugger和Grok Patterns工具的使用，會事半功倍，極大提高開發效率，避免不必要的“黑暗中摸索”。
思考：如果内置的grok pattern和自定義的pattern都不能滿足已有複雜日志的比對？我們該如何處理呢？
歡迎留言，寫下你的思考。相信深度的思考，能提升你的技術認知！
原文位址：
https://hackernoon.com/structuring-unstructured-data-with-grok-bcdbb240fcd1推薦閱讀：
https://www.elastic.co/cn/blog/do-you-grok-grok