利用 ELK 處理 Percona 審計日誌

linuxpro2023發表於2023-04-12
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 讀取後的字串展現(紅色標記):

利用 ELK 處理 Percona 審計日誌利用 ELK 處理 Percona 審計日誌

從上圖可以看到有一些換行後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 中正確顯示。

祝大家好運。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70028838/viewspace-2945373/,如需轉載,請註明出處,否則將追究法律責任。

相關文章