星期日, 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
張貼者： 於 沒有留言:
標籤：

星期二, 3月 12, 2024

Duet AI 啟用小記


Duet AI 啟用小記


現在到 2024/5/11 前, 每個帳單帳戶可以有1個使用者使用 Duet AI 免費.


這篇小記就是來紀錄如何啟用 Duet AI


官網


價格的部份可以看這邊


測試之前我也有問一下 Bard aka Gemini



我們直接進入重點, 如何啟用 Duet AI


在 google console 左邊的選單列找 Duet AI Admin



右邊會出現相關說明

點選 GET STARTED WITH DUET AI



Cost - Bard 果然誠不欺我 :) 

  • $19.00/month per license yearly subscription

  • $22.80/month per license monthly subscription

  • Licenses will renew with your subscriptions.



選取你要使用的 Billing account

點選 CONTINUE TO DUET AI ADMIN PAGE


不要緊張, 還沒有花到錢

只是進入 Subscriptions 頁面而已

目前上面沒有訂閱

點選 PURCHASE NEW SUBSCRIPTION



輸入 名稱

點選訂閱的區間 (Monthly or Yearly)

點選 要不要自動續約

點選 CONTINUE



確認相關細節

點選 COMPLETE PURCHASE 完成購買



確認已購買

並提供 quick start 文件

也可以回到剛剛的 Duet AI Admin 頁面觀察



那要如何驗證 Duet AI 可以使用呢？

  • 還是要在該專案啟用 Duet AI API


==== 場景 1 ====


觀察 Google Console 右上方的按鈕是否有作用


如果沒有啟用, 點選 Duet AI 的圖示會出現

  • Not enabled 

點選 ENABLE



如果是啟用的狀態, 就會看見 Start chatting



這個時候就可以輸入問題問 Duet AI


例如 



讓我驚喜的是



==== 場景 2 ====


另外一個我常常來的場景 Logs Explorer



點選 Explain this log entry




==== 場景 3 ====


vscode 安裝 Cloud code


點選左邊的 Duet AI 按鈕

點選 Select Duet AI Project



選取你已經有啟用 Duet AI 的專案


輸入要詢問的問題



中文測試



在程式或是 script 內容部份, 選取程式



可以請他解釋這段程式



大概是 3 個方向

  • 產生程式碼

  • 解釋程式碼

  • 產生 Unit Tests


程式碼的部份就是多利用

  • Ctrl + Enter

  • Tab


例如



先到這邊

又多前進一步


~ enjoy it



Reference
張貼者： 於 沒有留言:
標籤： ,
訂閱： 文章 (Atom)