AWS ALB 流量與存取次數統計小記

AWS ALB 流量與存取次數統計小記

今天來紀錄一下, 在 AWS 統計 ALB 的流量與存取次數的作法.

先說緣由

• 企業會使用不同的 AWS 專案來提供不同的服務, 但是如何權衡或是取得輔助資訊來確認業務與雲端專案的關聯性？

• 除了分析的專案, 如果是提供服務的專案, 可能就會以存取次數或是流量來進行相關參考

• 存取次數

• 對外服務大多是透過 ALB 來提供服務, 這個時候可以透過 CloudWatch 的 Metrics / ApplicationELB/Per AppELB Metrics / RequestCount 來確認客戶端對 ALB 請求的量

• 流量

• 剛開始的想法

• 不額外花費狀況下, 取得 VPC inbound / outbound 的流量, 來判斷相關的資訊, 這個部份在 GCP 是不需要費用與可以簡單設定的.

• 結論: 必須啟用 VPC 流量日誌才能取得 in/out 流量資訊 (暫不採用)

• 目前的方案

• 使用  CloudWatch 的 Metrics / ApplicationELB/Per AppELB Metrics / ProcessedBytes 為資料參考內容

• ProcessedBytes 主要是基於請求雙向 (req + res) 的 HTTP header 及 payload 流量，可以理解為 ALB 在七層轉發的處理總量, 也就是 in + out 總量

• 這個部份也要以業務的實務來考量相關數據, 例如如果是抓圖服務, 那就出現存取次數比較少, 但是流量是大的狀況.

接下來紀錄, 如何設定相關的 Metric

需求:  統計 2024/3 月份的 存取次數與流量統計

登入 AWS Console, 到 CloudWatch 首頁

點選 Metrics -- > All metrics -- > ApplicationELB -- > Per AppELB Metrics

勾選要監控 ALB 的 RequestCount 與 ProcessedBytes

 

調整上方的時間區間

這邊我使用 Local timezone 與設定 Absolute 的 Start date / End date

2024/03/01 00:00:00 到 2024/04/01 23:59:59

將預設的 LINE 呈現方式改為 Number

接下來點選 Graphed metrics 分頁

這個時候可以觀察到, 預設是使用 Average 的方式來進行統計

因為我們是要統計 3 月份的總量, 所以接下來針對統計方式來進行改變

將統計方式改為 Sum, 統計區間改為 30 days

這個時候其實已經算是完成初步的任務了

觀察我們取得的資訊

• 這邊可以看到, 我們有取得兩個點資料

• 2024-03-01 00:00 Local

• 以 2024/3/1 為起算點, 計算 30 天, RequestCount 為 518,979

• 2024-03-31 00:00 Local

• 以 2024/3/31 為起算點, 計算 30 天, RequestCount 為 503,907

• 這邊要注意的是, 雖然剛剛我們的時間區間是到 2024/04/01 23:59:59 但是不是指資料只能截止於 2024/4/1, 也就是說, 還是會從 2024/3/31 往後推 30 天的資料量來進行加總, 這點要特別注意

剛剛的介面, 區間的部份只有 30 days, 但是實務上, 月份的天數有 28 / 29 / 30 / 31 這 4 種狀況

如果要更進一步精細的確認區間還如何呢？

切換到 source 分頁

• 這邊可以觀察到有 period 的設定, 這邊的數字是 2,592,000 他的單位為秒

• 2,592,000 / 86,400 = 30 天 (一天是 86,400 秒)

• 31 天就是 2,678,400

• 29 天就是 2,505,600

• 28 天就是 2,419,200

我們的案例是 2024/3 月份, 天數為 31 天

修改 period 為 2678400, 點選 update

這個時候可以再次觀察數據

• 2024-03-01 00:00 Local

• 以 2024/3/1 為起算點, 計算 31 天, RequestCount 原為 518,979, 修正為 525,404

• 2024-04-01 00:00 Local

• 以 2024/4/1 為起算點, 計算 31 天, RequestCount 原為 503,907, 修正為 497,484

• 然後重點是 圖案上面的 497 k 其實是顯示最接近的點的數值

得到這樣的結果, 以及知道選取的區間不會影響統計的 source period, 我們再次調整選取的時間區間

• 選取的區間就剛好選取 31 天

• 如果少於 31 天, 發現系統會往前幫你推 start date

結果如下

這次跟 AWS Cloud Support Engineer 討論, 獲益匪淺

先紀錄下來

~ enjoy it

Reference

• AWS CSE