ELK 處理 Percona 審計日誌(填坑)

前提

一、有強烈的審計需求。python

二、能容許10%-15%左右的性能損失。sql

三、有強烈的對數據庫操做實時查看需求(通常都是爲了領導要求)。數據庫

Logstash 比較坑的配置

 

上面的配置看上去是沒有問題的,若是是通常的json數據哪就能解析成功了,json

可是在 Percona audit plugin 中應用程序應用程序生成的SQL是五花八門,各類字符都有其中有。python2.7

以下審計的日誌被 python 讀取後的字符串展示(紅色標記):elasticsearch

ELK

從上圖能夠看到有一些換行後tab的字符,這些字符使用 json.load 的時候會報錯,不能解析成jsonide

使用python json 模塊解析相關日誌文件報錯:性能

因此在使用logstash的時候也就解析不了這樣的json數據了,spa

最終logstash只能報錯並將整個message記錄到 Elasticsearch 中插件

解決辦法

解決辦法就是把這些字符替換掉。以下 Logstash 配置文件

該配置文件是投機取巧的辦法, 把 (換行/tab) 字符替換成空格,要注意的一點最終顯示的SQL和原來的有所差異。

這種方法有點不靈活若是sql語句中還有遇到一些json不能解析的字符又要進行處理。

>>朋友們若是有更好的方法也告知一聲哈!<<<

還不能笑到最後

剛開始覺得這一切都萬事大吉了。其實還有個一坑就是在使用 Kibana 查看的時候,這時候問題就來了。

有是有過 Percona audit 插件的估計都有這樣的問題,就是他記錄的是時間是國際形式的(如上圖黃色標記),不像咱們習慣了北京時間。所以在頁面顯示的時間會比咱們平時的少 8 小時。

通常來講在ELK中使用國際的標準格式是合理的。由於在使用 Kibana 查看的時候會幫你自動轉化成本地時間格式。也就是若是咱們在中國他會自動把 timezone 轉化爲 Asia/Shanghai(東8區) 的。因此顯示的時間應該是正確的纔對。但是實際狀況並無。

沒有轉化的緣由

是應爲 Elasticsearch 將 "2016-08-30T01:45:30 UTC" 這串字符解析成了String類型。按道理應該解析成和@timestamp同樣的date類型。

解決思路

將 "2016-08-30T01:45:30 UTC" 格式轉化成和 @timestamp 同樣的格式("2016-08-30T01:45:30Z")

最終配置文件以下

 

使用上面配置就能順利的將 時間格式 轉化成 Elasticsearch 想要的時間格式,而且能在 Kibana 中正確顯示。

相關文章
相關標籤/搜索