Logstash之Grok正則匹配，讓正則進階！

簡述

關於ELKStack日誌收集Nginx日誌，如果我們定義的Nginx格式使用JSON，那麼Logstash可以非常輕鬆的按預定義好的JSON格式進行收集，這樣就可以避免額外的 Filter/Grok 配置。但是如果在我們的生產環境中，Nginx日誌格式在某些情況下並不是如此，那就不得不使用Logstash的Filter/Grok元件透過正則匹配過濾，下面我們就來演示下吧。

Nginx日誌格式

為了幫助我們有效的理解grok的正規表示式，因此我特意將日誌格式定義的複雜一些。

Google上好多案例都是套用的預設格式，為了便於大家以後更好的擴充套件使用，我在此並沒有使用預設欄位。

其對應的真實日誌如下：

Logstash正規表示式

Logstash中預設已存在一部分正規表示式供我們使用，在以下路徑中我們可以看到：

其中最基本的定義是在grok-patterns中，但是其中的正則搭配並不適合我們本次Nginx日誌格式，因此我希望透過自定義的規則來實現格式匹配，然後使用Grok元件透過patterns_dir來呼叫即可。

另外，我們可以透過“”或“”這兩個站點來檢視我們的正則是否正確。

下面我們來透過分解日誌中的各個欄位來解析正規表示式：

正規表示式定義完畢後，我們可以到來驗證。

「要點：」

1.上圖中”URIPARAM1“ 是我們自定義的個一個正則，其規則為[A-Za-z0-9$.+!‘|(){},~@#%&/=:;_?-[]]，由%{URIPARAM1:args}呼叫。它和預設URIPARAM規則是有區別的。如果你觀察仔細的話，可以看到預設的“URIPARAM”是以?開頭，而我們自定義的URIPARAM1不是。

注意：這個規則是更新的，可能由於版本的問題，將導致我們在使用預設正則時會出現“Longest prefix that matches”的提示，“after matche”會顯示日誌中未匹配的剩餘內容。

2.http_user_agent和http_cookie欄位使用“patterns#”中“nginx-access”生成的規則“%{QS:agent}”以及類似“%{QS:cookie}”也會出現“Longest prefix that matches”提示，因此這兩個正則是不正確的。我們可以使用%{GREEDYDATA:agent}和%{GREEDYDATA:cookie}代替，而“GREEDYDATA .*”，是匹配的所有字元。注意其和“QS %{QUOTEDSTRING}”的區別。

3.?:%{URI:referrer}|-)正則表示如果$referer欄位為空，則用"-"表示，若不為空則顯示referer的內容。經測試如果直接設定成%{URI:referrer}，過濾時當referer為空時，會導致grokfailure，因此需要注意此欄位的正規表示式。

注意：某些欄位為“-”時，可能會導致grokfailure，此時我們可以透過(?:%{XX:XX}|-)的方式進行匹配，即為空時顯示“-”。

官方正則查詢：

Logstash呼叫

「1.在logstash中定義正則目錄並定義規則」

其中：

URIPARAM1是我們自定義的規則;

NGINXACCESS是我們整體自定義的規則，其中呼叫了URIPARAM1;

注意：若以上的日誌如下

其中referrer欄位為"

經過以上調整，正則就可以正確匹配了。

「2.配置檔案logstash.conf」

其中：patterns_dir定義的是我們自定義的正則存放目錄

「3.重啟logstash」

檢視kibana，欄位就顯示出來了。如果我們的欄位前面是?，可以透過重新整理下我們的“Setting”—“indices”—“Index Patterns”—“logstash-nginx-access-%{+YYYY-MM}”索引即可。

總結

經過以上對Grok正則的一番操作，以後即使我們面臨更復雜的日誌格式，只要對應規則從容不迫，相信我們都可以解決。但是希望大家指導，越複雜的正則匹配只會浪費伺服器效能。因此當我們有海量日誌的需求時，建議還是使用較容易解析的格式吧。