利用 ELK 處理 Percona 審計日志

2024-07-21 02:51:47

字體：大中小

來源：轉載

供稿：網友

導讀	Percona Server為 MySQL 數據庫服務器進行了改進，在功能和性能上較 MySQL 有著很顯著的提升。該版本提升了在高負載情況下的 InnoDB 的性能、為 DBA 提供一些非常有用的性能診斷工具；另外有更多的參數和命令來控制服務器行為

前提

1、有強烈的審計需求。

2、能允許10%-15%左右的性能損失。

3、有強烈的對數據庫操作實時查看需求(一般都是為了領導要求)。

Logstash 比較坑的配置

input {    file {        path => ["/u02/backup/audit.log"]        codec => json    }}output {    elasticsearch {        hosts  => ["192.168.1.233"]    }}上面的配置看上去是沒有問題的，如果是一般的json數據哪就能解析成功了，
但是在 Percona audit plugin 中應用程序應用程序生成的SQL是五花八門，各種字符都有其中有。
如下審計的日志被 python 讀取后的字符串展現(紅色標記)：
從上圖可以看到有一些換行后tab的字符，這些字符使用 json.load 的時候會報錯,不能解析成json
使用python json 模塊解析相關日志文件報錯：
>>> json.loads(json_line)Traceback (most recent call last):  File "<stdin>", line 1, in <module>  File "/usr/lib64/python2.7/site-packages/simplejson/__init__.py", line 516, in loads    return _default_decoder.decode(s)  File "/usr/lib64/python2.7/site-packages/simplejson/decoder.py", line 370, in decode    obj, end = self.raw_decode(s)  File "/usr/lib64/python2.7/site-packages/simplejson/decoder.py", line 400, in raw_decode    return self.scan_once(s, idx=_w(s, idx).end())simplejson.scanner.JSONDecodeError: Invalid control character '/t' at: line 1 column 232 (char 231)所以在使用logstash的時候也就解析不了這樣的json數據了，
最終logstash只能報錯并將整個message記錄到 Elasticsearch 中
解決辦法解決辦法就是把這些字符替換掉。如下 Logstash 配置文件
input {    file {        path => ["/u02/backup/audit.log"]    }} filter {    mutate {        gsub => ["message", "////n", " "]        gsub => ["message", "/t", " "]        replace => [ "message", "%{message}" ]    }    json{        source => "message"    }    mutate {         remove_field => [ "message" ]    }} output {    elasticsearch {        hosts  => ["192.168.1.233"]    }}該配置文件是投機取巧的辦法, 把 (換行/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")
最終配置文件如下input {    file {        path => ["/u02/backup/audit.log"]    }} filter {    mutate {        gsub => ["message", "////n", " "]        gsub => ["message", "/t", " "]        replace => [ "message", "%{message}" ]    }     json{        source => "message"    }     mutate {        remove_field => [ "message" ]        gsub => ["[audit_record][timestamp]", " UTC", "Z"]        replace => [ "[audit_record][timestamp]", "%{[audit_record][timestamp]}" ]    }} output {    elasticsearch {        hosts  => ["192.168.1.233"]    }}使用上面配置就能順利的將 時間格式 轉化成 Elasticsearch 想要的時間格式，并且能在 Kibana 中正確顯示。
祝大家好運。
本文
免費提供最新linux技術教程書籍，為開源技術愛好者努力做得更多更好：http://www.linuxPRobe.com/