elastic search 練習 audit log

發表於 更新於 閱讀次數： Disqus：

其實會有這一篇原因也只是因為DB是珍貴資源，如果將Log都放在DB內是很傷的一件事情，如果可以將Log從DB拿出來，對DB的負擔就減輕了

在實作 audit log 系統的時候，除了程式的部分，其實在儲存體的部分也可以改用 elastic Search 來做
關於 audit log 的文章，可以參考這一篇:Audit Trail And Data Versioning With C# And MVC

範例文章是利用 C#及 EF 來實作，從頭到尾都解說過一次，連 UI 的 razor 頁面都做了，可以先瀏覽過一次
es 的功能很多也蠻強大的，可以做全文檢索搜尋、可以跟 APM 整合來記錄應用程式效能紀錄，作為改善效能的依據，不過那些就等以後學習到在研究了

這一次的練習則是延續上次的 ELK Stack，這次直接透過 Restful API 進行資料的操作，為的就是要先模擬出來後端資料儲存的這一塊
使用 es 的好處最直覺的一個就是將 log 記錄與 DB 拆開來，對於 LOG 的查詢、操作，不再影響現有的資料庫
對於 DB 效能是有好處的，否則當資料量大，大家都在查詢的時候，網站卻因為資料庫效能的關係而影響到 end-user 體驗，那就不是很好了

一般來說，大部分的專案可能都會有兩種資訊需要被記錄下來

  1. 歷程：資料異動後，需要記錄異動前後、異動人員、時間的資料，例如：商品資料異動、會員資料異動
  2. 紀錄：發生事件後，需要記錄觸發事件的相關資料，例如：個資查詢記錄、系統登入記錄

設計思路是利用群組、類型來區分資料，查詢則透過 unique Key，紀錄的內容則放在一個自定義的屬性內

要注意的是，因為 elasticSearch 先前設計上的錯誤，同一個 index 底下目前僅支援一個 type

中文的文件可以先參考這一份

  1. logType：資料類型
  2. refId：unique Key
  3. content：要保存的資料內容

客戶異動歷程試資料

content的資料內容為一個資料集合，可儲存多筆，每一筆資料紀錄異動的資料項目，異動前後的值

1
2
3
4
5
6
7
{
  "refId": 10002000,
  "logType": "customer",
  "modifiedBy": 1234,
  "modifiedDate": "2019-04-24 06:22:16",
  "content": [{ "field": "Mobile Phone", "valueBefore": "0912345678", "valueAfter": "0912333444" }]
}

系統登入紀錄測試資料

content的資料內容為一個物件，紀錄了登錄時間、狀態、IP 等資訊

1
2
3
4
5
6
7
8
9
10
{
  "refId": 1234,
  "logType": "login",
  "content": {
    "loginDate": "2018-10-09 12:03:00",
    "ipAddress": "123.123.123.123",
    "machineName": "LAPTOP-XXXXXXX",
    "loginStatus": "Y"
  }
}

查詢某位客戶的異動歷程紀錄

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "logType": "customer"
          }
        },
        {
          "match": {
            "refId": 10002000
          }
        }
      ]
    }
  }
}

查詢某位使用者針對客戶資料操作的歷程記錄

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "logType": "customer"
          }
        },
        {
          "match": {
            "modifiedBy": 1234
          }
        }
      ]
    }
  }
}

在異動紀錄的部分可以猜想的到的情境，大概都是以某個客戶、某個東西為出發點，所以就拿它當作 unique key

以個資紀錄查詢的這個例子來看，情境如果是客戶資料外洩，要求來查詢他的資料有誰看過，那麼就以客戶編號查詢即可
但假設第二個情境：內部稽核發現某位系統使用者有做一些資安疑慮的事情，因此需要查詢他看過那些人的資料，這個時候就會需要用員工編號查詢

因此在這邊的資料結構設計可能需要再想想
在 Content 目前的結構是沒有辦法很好的運用索引，可能就是要拆開來，做兩個不同的 index/type 來處理這兩類的紀錄 (歷程、LOG)

不過目前為止，只是為了練習基本操作，就先這樣吧

瀏覽器操作 Elastic Search 有一個外掛很好用，叫做 Elastic Search HEAD，有興趣的再自己研究一下吧