簡體   English   中英

如果您只有 1 個實例,則 Elastic Beanstalk NetworkOut 自動縮放

[英]Elastic Beanstalk NetworkOut auto scaling if you have only 1 instance

我們有一個 Elastic Beanstalk 環境,幾個星期以來,幾乎每天早上 8 點 10 分/8 點 20 分,我們都會收到一條通知 (SNS),“環境健康狀況已從良好轉變為退化”,2 分鍾后我們又收到一條消息,“環境健康狀況已從“降級”轉變為“正常”。

發生這種情況時,正在運行的 EC2 實例將被終止並啟動一個新實例。

我通過下載剛剛終止的實例的日志並通過控制所有 CloudWatch 參數進行了調查,我唯一發現的是在實例終止前大約 10 分鍾開始出現 CloudWatch NetworkOut < 2000000 警報。

所以我想問題是實例的流量很低。 我也對此表示懷疑,因為我們有針對 2 個國家(.it、.ch)運行的 2 個環境,即使它們在各個方面都相同,但 .it 也有這個問題。

但是,如果問題是自動縮放會觸發縮減一個低使用率的實例,那么如果您只有 1 個實例正在運行並且您只設置了 1 種實例類型 (T3.micro) 將被使用,那么如何處理自動縮放縮減,並避免這唯一的實例被終止?

我們是否應該更改自動縮減規模的指標? 實際上,似乎每個指標都可能存在相同的問題。

原來是一場誤會。 我可以刪除這個問題,但它可能對遇到同樣問題的人有用。

所以這就是發生的事情,我以 2003 年 21 月 21 日真正發生的事情為例。

來自 EB 事件:

3 月 21 日星期一 14:01:12 UTC 2022 EB 環境運行狀況從“正常”轉變為“警告”

2022 年 3 月 21 日星期一 14:02:18 向您的環境添加了實例 [i-...ba4]

2022 年 3 月 21 日星期一 14:10:18 UTC 環境運行狀況已從“良好”轉變為“退化”。 2 個實例中有 1 個沒有收到數據。

2022 年 3 月 21 日星期一 14:11:18 UTC 從您的環境中刪除了實例 [i-...a37]。

來自 EB email 通知:

2022 年 3 月 21 日星期一 14:10:18 消息:環境運行狀況已從良好轉變為退化。 2 個實例中有 1 個未收到數據。

2022 年 3 月 21 日星期一 14:12:18 消息:環境運行狀況已從“降級”轉變為“良好”。

所以:

  • 在 14.01,應用程序的 NetworkOut 指標達到峰值,觸發自動縮放(NetworkOut > 6.000.000)
  • 在 14.02 [i-...ba4] 實例通過自動縮放啟動(現在有 2 個實例)
  • 在 14.10,因為即使是 2 個實例也不足以達到 NetworkOut 峰值,我得到了一個 email 的降級環境
  • 在 14.11 NetworkOut 峰值結束,之前的 [i-...a37] 實例被自動縮放刪除
  • 在 14.12 我收到第二個 email 通知,環境健康恢復正常
  • 在 14.12 之后,該應用程序仍未被用戶使用,因此當我檢查 CloudWatch 時,我看到警報 NetworkOut < 2.000.000(默認 EB 配置 NetworkOut 指標值)

關鍵是,由於 Autoscaling 的觸發不是由於用戶數量的增加,而是來自單個用戶的大數據下載,因此新實例的啟動無濟於事,環境仍然保持不變降級了幾分鍾,所以我從 EB 收到了健康通知 email。 但是當我過一會兒檢查 CloudWatch 時,我看到的警報是 NetworkOut < 2.000.000。

然后,在 EB 事件中看到一個實例被殺死,一個新實例被 AutoScaling 啟動,我誤以為這個通知是由於低流量警報,而不是之前的數據傳輸高峰。

而且由於這個峰值不是由於用戶的增加而是由於單個用戶的大數據下載,所以從日志中了解發生了什么也不容易。

但是最后查看EB監控NetworkIn參數的時候就清楚了,因為下載的數據是從RDS過來的,所以對應NetworkOut峰值我也看到了一個NetworkIn峰值。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM