Skip to main content
Version: 2.8.1

常見問題

Admin API (URL) 跟 Proxy API (URL) 該如何取得？#

GOC API Gateway 出廠時即預設可使用 Admin API (URL) 及 Proxy API (URL)。

假設目前出廠時，GOC API Gateway 本身服務的 IP 為 10.112.1.3，則：

  • Admin API (URL)： 預設服務對應的 port 為 31218，或是 8001，所以呼叫 URL 的時候會使用 http://10.112.1.3:31218 或 http://10.112.1.3:8001。
  • Proxy API (URL)： 預設服務對應的 port 為 31215，或是 8000，所以呼叫 URL 的時候會使用 http://10.112.1.3:31215 或 http://10.112.1.3:8000。

Proxy API (URL) 也可以從「快速設定#API Gateway 設定區塊」中查看。

可能會依據出場時安裝的底層環境受限(例如 port range 限制)而有所改變，若不符合上述之預設，請另外詢問 GOC API Gateway 服務安裝人員。

如何導入 API Log 到 ELK？#

需啟用日誌類型的插件：「tcp-body-log」，並設定正確的 logstash 的 host & port，細節可參考此插件詳細說明。

啟用後，嘗試透過 GOC API Gateway 呼叫 API，就可以透過 ElasticSearch API拿取對應 index 的 Log，或是從 Kibana UI 上操作檢視對應 index 的 Log 內容。

tip

若啟用 「tcp-body-log」插件後，仍未看到對應的 API Log，則需注意以下幾項：

  1. logstash 的 config 配置是否正確，常用配置範例如下：
input {
tcp {
port => 5044
codec => json_lines
}
}
filter {
json {
source => "message"
}
}
output {
elasticsearch {
hosts => "http://elasticsearch.apigw.svc.cluster.local:9200"
codec => json_lines
index => "api_gateway_log-%{+YYYY.MM.dd}"
}
}

其中：

  • input：通常直接往 logstash 進行 Log 拋送，這邊代表拋送到自身的 5044 port 進行事件消息接收。
  • filter：將事件消息接受後進行格式處理轉換，最後處理為我們想要的格式 (範例是會將收到的消息都轉為 json 的格式)。
  • output：將處理後的事件消息輸出至其他部分，如 ElasticSearch，需要填入正確的 elasticsearch 的 hosts 位置，以及輸出到 elasticsearch 的 index (範例 index 是會對應當前年月日，傳送消息至對應的 elasticsearch index 內)。
  1. ElasticSearch cluster 狀態是否正常，可以呼叫 GET /_cluster/health 的 API 進行確認，詳細可以參考 Cluster health API。

在 API紀錄 (API History) 畫面中無法看到任何紀錄，或是點選搜尋後．出現 "api-history config not found. Please enabled api-history plugin." 的訊息#

若有出現 "api-history config not found. Please enabled api-history plugin." 的訊息，請先確認是否有正確啟用 「api-history」 的插件。(請務必確認是有顏色的 "啟用" 狀態，而非灰色的 "禁用" 狀態)

不管選擇的來源是 database 或是 elastic-search，都有其搭配的日誌紀錄套件需要啟用，才能正確地把 Log 送至指定儲存空間。詳細請參考 api-history 插件頁面說明。

若插件都以正確設定，但仍無資料，請嘗試搜尋不同時間起訖、移除關鍵字之後再搜尋。若來源端選擇 elastic-search，也須確認 logstash、elastic-search 之間連通狀態，以及 logstash、elastic-search 服務目前的健康狀態。

在 API紀錄 (API Log) 中所查詢到的 client_ip 不是正確的，該如何拿取到正確的 source ip ?#

可能造成此情況的原因有下列幾種：

  1. 部署方式是 Kubernetes 的容器架構，且前方無額外架設 LoadBalancer。此情況請參考 Kubernetes Document - Using Source IP 的說明來設定。
  2. 部署方式是 Kubernetes 的容器架構，前方有另外架設 LoadBalancer，此情況請看後續解決方式。
  3. 部署方式是 VM，前方有另外架設 LoadBalancer，此情況請看後續解決方式。

前方有另外架設 LoadBalancer 的解決方式需要滿足以下兩點：

  1. LoadBalancer 本身的設定可以加上傳入 X-Forwarded-For 的 header，如以下幾種常見 LoadBalancer 設定範例：

    開啟傳入 X-Forwarded-For 的 header 之後，後續收到的 API紀錄 (API Log) 中的 requests.headers 區塊就會多出一個 x-forwarded-for 的欄位並且帶入正確的 IP

  2. GOC API Gateway 本身部署設定中，需要加上以下設定，才能正確辨識出 source ip 的來源：

    • 若為 Kubernetes 的容器架構，請加入至 deployment 的 env 內：
    - name: KONG_REAL_IP_HEADER
    value: X-Forwarded-For
    - name: KONG_REAL_IP_RECURSIVE
    value: "on"
    - name: KONG_TRUSTED_IPS
    value: 0.0.0.0/0,::/0
    • VM 架構，則編輯 /etc/kong/kong.conf，修改以下設定，並於設定完後執行 kong quit && kong start 來重啟 API Gateway：
    real_ip_header = X-Forwarded-For
    real_ip_recursive = "on"
    trusted_ips = 0.0.0.0/0,::/0

    在 GOC API Gateway 加上這些設定後，client_ip 欄位就可以抓取到正確的 IP。

為什麼 IP Restriction 的插件沒有成功阻擋/允許通過所設定的 IP？#

跟上題有關，請參考上題的設定說明。