星期日, 4月 28, 2024

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

沒有留言: