Log 判讀

Request 實驗

在進入Log的判讀之前，總是要先有流量才能夠有Log，因此先進行兩個實驗。第一個實驗是不帶認證方式的request，預期得到的結果是401的錯誤，因為我們使用apikey進行認證。第二個實驗則是在headers加入apikey=user1-api-key，預期得到200的狀態。接著就能夠進行log的判讀。

Case 1 ：未提供認證資訊

圖8-1 未提供認證資訊

Case 2 ：提供認證資訊

圖8-2 提供認證資訊

相關參數：

• url: http://localhost:8000/my-service/weatherforecast
• http method: get
• header:
  • apikey: user1-api-key

Kibana的一些事先設定

由於實驗是初次運行Kibana，因此需要做一些設定值，才可以在Kibana看到相關的Log，接著請跟這下面的步驟執行，才能順利看到request的相關 Log。

1. 用瀏覽器開啟http://localhost:5601後，點選左邊的Management-> Stack Management

圖8-3 Stack Management

2. 選擇Data Views，並建立一個data view。

圖8-4 Data Views

3. 這時候可以觀察到，目前已經有兩個index被建立起來，如圖8-5。

圖 8-5 index sources

4. 接下來，建立兩個data view，參數分別如下，可參考圖8-6：

• data view 1
  • Name: kong
  • Index pattern: kong*
• data view 2
  • Name: api
  • Index pattern: api*

圖 8-6 data view

5. 將這些都設定好了之後，回頭去選擇 Analytics -> Discover。接下來就可以準備來判讀Log了。

圖 8-7 Discover

index 設計的思考

在判讀Log之前，先來回想一下。前面有提及兩個index，來源資料第一個是Kong裡面的http log plugin 的設定檔，讀者可以看著設定稍微回想一下：

# ironman2025\case_ELK\1.Kong_declarative\declarative\kong.yml
plugins:
- name: http-log
  config:
    http_endpoint: http://elasticsearch:9200/kong-logs/_doc
    method: POST
    content_type: application/json

可以關注到，設定檔裡面有一段http_endpoint，會發現到在路徑中，有kong-logs。這個就是 Elasticsearch 的 index 名稱。Kong 的 http-log plugin 會把日誌資料 POST 到指定的 endpoint，而 /kong-logs/_doc 代表要把資料寫入 Elasticsearch 的 kong-logs index。

另外就是程式碼的部分

    #ironman2025\case_ELK\2.api_provider\case_withelk\Program.cs
    Log.Logger = new LoggerConfiguration()
        
        ....中間省略
        
        .WriteTo.Elasticsearch(new Serilog.Sinks.Elasticsearch.ElasticsearchSinkOptions(new Uri("http://elasticsearch:9200"))
        {
            AutoRegisterTemplate = true,
            IndexFormat = "api-logs-{0:yyyy.MM.dd}"
        })
        .CreateLogger();

在IndexFormat這個參數，就可以看到傳入elasticsearch index 是以api-logs-{0:yyyy.MM.dd}為命名方式。

這部分筆者是刻意分開，用以分辨Log是由Kong 還是由後端API 服務紀錄。Kong 對於Plugin 的使用非常彈性，像這次HTTP Log plugin是被放在全域層級。這表示所有進出Kong API Gateway的request/response，都會被記錄到elasticsearch中。

相信讀者對於不同層級的Plugin 應該有些疑惑，筆者接下來會找機會補充，先把Kibana的任務完成。

Log 判讀

Kong log

圖8-8 Kong log

首先先來選擇剛剛命名為kong 的Data view，已經被建立起來。在圖8-8 可以看到，目前僅有兩筆Log紀錄，這符合前一天做的兩個實驗，接下來來關注欄位。

圖8-9 Log 判讀-Kong

圖8-9 可以注意到我們關注了一些欄位，簡單說明如下：

• 欄位說明
  • request.headers.apikey： header 的apikey這個欄位，第一筆有提供值為 user1-api-key。
  • response.status：http response 的狀態碼。
  • upstream_status：上游API回覆的狀態碼。
  • latencies：
    • request：request 從進入Kong到回覆response的延遲總時間(kong+proxy的總和)。
    • kong：request 進入時，kong所造成的總延遲時間。
    • proxy：request 進入時，上游API所造成的總延遲時間。

從上面各個欄位我們就可以關注到，兩次的request的一些特點，說明如下：

• 第一次request，因為有帶apikey且正確，因此kong協助做revert proxy的行為，最終耗費4,631 ms(3,345+1,286)，且回覆 http:200。
• 第二次request，因為沒有通過認證，因此kong直接回覆http:401，當然也不需要傳任何request 到上游API，所以proxy:-1。

API log

圖 8-10 Data view - api

接著就是判讀API 所傳入的Log了，把Data view 切換成api，可以看到相關的Log 都有傳入，可參考圖 8-10。

圖 8-11 Log 判讀-API

同樣的，我們將關注的欄位濾出，可以發現在 fields.StatusCode這個欄位，有一個回覆 200 的狀態碼。

小結

今天的範例很清楚的示範了，在不同的instance是如何分別將Log都收攏到elasticsearch中，並透過kibana來進行判讀。

可以注意到的是，當外部的請求並未帶入正確的認證方式時，Kong API Gateway 在第一線扮演了阻擋的角色。

這種設計可以預先過濾掉不合法的請求，避免後端API服務要處理不合法的請求，消耗運算資源。

不過還是有一些待解的問題需要去面對，簡單列出如下：

1. API Key 曝露的風險：相信工程師如讀者你在看的時候，一定覺得很過癮，因為可以快速查找合法與不合法的請求。但是在Log平台中可以看到API Key.....那是不是很容易不小心被取走？
2. Kong 的Log 居然沒有timestamp？？筆者也是邊做實驗引入後才發現，雖說有把Log的json引入elasticsearch，但是原生的Log居然沒有timestamp，這問題勢必要克服。

好吧！今天先到這，明日再戰。