簡介： 阿里雲API網關服務提供API託管服務，提供了強大的適配和集成能力，可以將各種不同的業務系統API實現統一管理。API網關同時支持將API訪問日誌一鍵存儲到日誌服務，通過日誌服務強大的查詢分析能力，用戶可以針對訪問日誌自定義計算多種指標，監測服務運行情況。繼而通過定時SQL將結果指標直接存儲到時序庫，直接查詢API網關指標，而且可以通過較低成本長期存儲指標數據。 下面我們一步步從頭開始，學習如何利用日誌服務監測API網關及其代理的服務。
背景
阿里雲API網關服務提供API託管服務，提供了強大的適配和集成能力，可以將各種不同的業務系統API實現統一管理。API網關同時支持將API訪問日誌一鍵存儲到日誌服務，通過日誌服務強大的查詢分析能力，用戶可以針對訪問日誌自定義計算多種指標，監測服務運行情況。繼而通過定時SQL將結果指標直接存儲到時序庫，直接查詢API網關指標，而且可以通過較低成本長期存儲指標數據。 下面我們一步步從頭開始，學習如何利用日誌服務監測API網關及其代理的服務。
數據採集
數據採集一直是讓開發運維比較頭疼的事情，要學習各種不同的採集工具，適配形形色色的環境，解析各式各樣的數據格式，在不斷試錯的情況下，才能夠完成第一次的數據採集。而在此之後，還需要不斷地完善優化，耗費大量的經歷。下面簡單介紹下數據採集以及採集到的日誌格式，詳情可以參考官方文檔。
一鍵採集
阿里雲API網關已經很好的集成了日誌服務，用戶只需要在API網關的日誌管理界面關聯日誌服務，即可完成API訪問日誌的一鍵採集，極其方便。
- 在API網關的日誌管理界面點擊創建日誌配置；
- 在彈出窗中選擇日誌服務的Project/Logstore；
- 點擊確認，完成數據採集；
日誌格式
下面是採集到的API訪問日誌示例，
{
"exception": " ",
"apiName": "getbill",
"apiStageName": "stage3",
"__tag__:__receive_time__": "1667222540",
"httpMethod": "POST",
"path": "/request/path-1/file-6",
"__pack_meta__": "1|MTY2NzIwNzcxMTIyMzU0Mzc1Ng==|1094|1093",
"requestHandleTime": "31/Oct/2022:13:02:49",
"requestId": "d6b86756-83c2-e5a8-63f6-da39045f6595",
"appId": "9fb195bd-3d39-be83-ca8c-44a6e85262eb",
"__time__": 1667221369,
"__topic__": "apigateway_log",
"apiStageUid": "e5c13606-f96e-5653-26b1-750d766dd3ae",
"appName": "app3",
"__source__": "127.0.0.1",
"apiGroupUid": "3a51584d-20de-2da1-3095-7f82aa7022dc",
"errorMessage": " ",
"responseSize": "472",
"serviceLatency": "967",
"providerAliUid": "9e21f8dc-54bd-7ad0-5fb4-a898614bc41c",
"apiGroupName": "group4",
"apiUid": "316af01f-8f8f-e2f9-17d7-ac0ea3b28518",
"domain": "www.qt.mock.com",
"clientIp": "123.161.24.126",
"__tag__:__receive_time___0": "1667222540",
"region": "cn-chengdu",
"requestSize": "945",
"statusCode": "200"
}
關於各字段的含義，可以查看下錶，也可以參考官方文檔。訪問日誌的字段也會隨着API網關能力的增強進行補充，不需要用戶手動增刪，極大的減輕了維護負擔。
|
日誌項 |
描述 |
|
apiGroupUid |
API的分組ID |
|
apiGroupName |
API分組名稱 |
|
apiUid |
API的ID |
|
apiName |
API名稱 |
|
apiStageUid |
API環境ID |
|
apiStageName |
API環境名稱 |
|
httpMethod |
調用的HTTP方法 |
|
path |
請求的PATH |
|
domain |
調用的域名 |
|
statusCode |
HttpStatusCode |
|
errorMessage |
錯誤信息 |
|
appId |
調用者應用ID |
|
appName |
調用者應用名稱 |
|
clientIp |
調用者客戶端IP |
|
exception |
後端返回的具體錯信息 |
|
providerAliUid |
API提供者帳戶ID |
|
region |
區域，如：cn-hangzhou |
|
requestHandleTime |
請求時間，UTC |
|
requestId |
請求ID，全局唯一 |
|
requestSize |
請求大小，單位：字節 |
|
responseSize |
返回數據大小，單位：字節 |
|
serviceLatency |
訪問後端資源耗時總和，包括申請連接資源耗時，建立連接耗時，調用後端服務耗時，單位：毫秒 |
|
errorCode |
錯誤碼code，如：X500ER |
|
requestProtocol |
客戶端請求協議：HTTP/HTTPS/WS |
|
instanceId |
API服務所在的網關實例ID |
|
initialRequestId |
API網關自調用時，例如API-1調用API-2 ，那麼API-2的日誌中會用initialRequestId來記錄API-1的requestid。 |
|
clientNonce |
客戶端X-Ca-Nonce頭 |
|
requestQueryString |
客戶端請求的queryString |
|
requestHeaders |
客戶端請求的header內容 |
|
requestBody |
客戶端請求的body內容，最多1024個字節 |
|
responseHeaders |
API響應的header內容 |
|
responseBody |
API響應的response內容，最多1024個 |
|
consumerAppKey |
API請求的appKey |
|
totalLatency |
API請求的總延遲，單位毫秒 |
|
customTraceId |
全鏈路日誌的traceId |
|
jwtClaims |
從JWT中解析出來的Claim，可以在分組上配置 |
|
plugin |
API請求命中的插件列表及相關上下文 |
查詢分析
有了日誌，就可以針對訪問日誌進行簡單的查詢分析，查看自己感興趣的指標。日誌服務即支持簡單的查詢，也支持複雜的聚合分析，下面進行簡單的介紹。
簡單過濾
最常見的情況是查看錯誤請求，可以通過查詢語句: * not statusCode: 200來查看所有的異常請求。
當然還可以通過更多的字段進行過濾，詳情可以參考官方文檔。
聚合分析
對於更復雜的分析，例如不同錯誤碼的的錯誤數量，不同api的平均響應時間，就需要用到聚合分析。下面以平均響應時間爲例，介紹下如何使用聚合分析。
在查詢框中輸入過濾以及分析語句：
* and statusCode: 200 | select avg(serviceLatency) as rt, (__time__ - __time__ % 300) as ts from log group by ts order by ts limit 10000
其中* and statusCode: 200 用來過濾出正常請求，其餘的sql語句則用來計算過濾後的數據，並通過圖表展示出來，如下圖所示。可以清楚地看到平均請求延遲的變化曲線。
確認指標
瞭解瞭如何進行基本的查詢分析，我們能做的事情就非常多了。可以根據自己的需求以及業務場景，自定義多種不同的業務指標，滿足自己的日常運維、監測需求。下面列出一些常用的指標，以及對應指標的查詢分析語句。
請求延遲
在查詢分析中，本文已經介紹過簡單的平均延遲計算方法，下面介紹下更完整的請求延遲指標：平均延遲、P99延遲、P95延遲、P90延遲、P50延遲、最大延遲以及最小延遲。
*| select approx_percentile(serviceLatency, 0.99) as p99_latency, approx_percentile(serviceLatency, 0.95) as p95_latency, approx_percentile(serviceLatency, 0.90) as p90_latency, approx_percentile(serviceLatency, 0.50) as p50_latency, min(serviceLatency) as min_latency, min(serviceLatency) as max_latency, avg(serviceLatency) as avg_latency, (__time__ - __time__ % 60) as ts from log group by ts order by ts limit 1000000
錯誤碼分佈
*| select count(1) as cnt, statusCode, (__time__ - __time__ % 60) as ts from log group by statusCode, ts order by ts limit 1000000
請求/響應大小
*| select approx_percentile(requestSize, 0.99) as p99_req_size, approx_percentile(requestSize, 0.95) as p95_req_size, approx_percentile(requestSize, 0.90) as p90_req_size, approx_percentile(requestSize, 0.50) as p50_req_size, min(requestSize) as min_req_size, min(requestSize) as max_req_size, avg(requestSize) as avg_req_size, approx_percentile(responseSize, 0.99) as p99_resp_size, approx_percentile(responseSize, 0.95) as p95_resp_size, approx_percentile(responseSize, 0.90) as p90_resp_size, approx_percentile(responseSize, 0.50) as p50_resp_size, min(responseSize) as min_resp_size, min(responseSize) as max_resp_size, avg(responseSize) as avg_resp_size, (__time__ - __time__ % 60) as ts from log group by ts order by ts limit 1000000
地域分佈
* | select region, count(1) as cnt , (__time__ - __time__ % 60) as ts from log group by region, ts order by ts
定時任務
可以看到，日誌服務強大的查詢分析能力允許用戶多網關日誌進行多種查詢分析，得到期望的結果。如果需要把上一小節計算的定時保存下來，就要用到定時任務。下面介紹如何將上一小節中計算的請求/響應大小指標，定時保存到時序庫中，從而可以快速獲取指標。
創建時序庫
點擊左側邊欄的時序存儲按鈕，在時序庫管理界面點擊+號，填入名稱即可創建一個時序庫，用來存儲希望保存的時序指標。
保存定時任務
創建好時序庫，就可以創建任務定時保存分析結果，以供實時查看。下面簡單介紹下定時任務配置步驟，詳情可以參考官方文檔。
點擊創建任務
在查詢分析界面點擊定時保存分析結果，即可彈出任務創建窗口。
選擇存儲格式
在彈出窗口中選擇日誌庫導入時序庫，確定數據存儲格式。
確定存儲指標
在sql配置中選擇期望保存的指標列，以及指標對應的時間列，即完成了指標配置。
配置任務調度
點擊下一步，調度間隔選擇15分鐘，開始時間選擇當前時間， SQL時間窗口同樣選擇15分鐘即完成了調度配置。當然，用戶也可以根據自己的場景自行選擇。最後點擊確認完成任務配置。
查看結果指標
點擊剛剛創建的時序存儲，在Metrics一行點擊刷新，即可查看該時序存儲包含的所有指標。選擇max_resp_size，點擊預覽，即可查看該指標，無需編寫查詢分析語句。
添加報表
有了指標，就可以使用這些指標構建監控大盤，查看整體指標，構建自己的專屬監控大盤。在指標查詢界面點擊添加到儀表盤，在彈出窗中選擇新建儀表盤，填入名稱點擊確認，即完成了儀表盤的創建。
點開儀表盤，即可看到剛剛創建的圖標。
結語
API網關是服務的入口，通過網關日誌可以計算出豐富的服務監控指標。本文以部分常用指標爲例，介紹了從數據接入到定時任務創建的整個流程，供用戶參考。可以看出，日誌服務提供了及其簡便的日誌採集入口，豐富的查詢分析功能，簡便的定時任務，幫助用戶簡單快速的建立起一個完整的日誌採集、指標分析、大盤查看系統，減輕了運維負擔。
原文鏈接：https://click.aliyun.com/m/1000364087/
本文爲阿里雲原創內容，未經允許不得轉載。