AWS帳號認證開通 AWS OpenSearch (Elasticsearch) 叢集狀態變紅（Red Status）與未分配分片排查

一、先搞清楚：Red Status 到底代表什麼

AWS OpenSearch 與 Elasticsearch 的叢集健康狀態，通常會看到綠、黃、紅三種顏色。綠色代表主分片與副本分片都已正常分配；黃色代表主分片正常，但有部分副本分片尚未分配；紅色則更嚴重，表示至少有一個主分片無法分配。只要主分片缺席，對應索引就可能無法查詢、無法寫入，甚至整個應用看起來像是資料突然消失。

AWS帳號認證開通 很多人第一次碰到紅色狀態時，第一反應是懷疑服務掛了。其實不一定。紅色狀態只是結果，真正的原因通常藏在分片分配規則、節點資源、磁碟空間、索引設定或節點故障之中。排查的重點，不是急著重啟，而是先確認「是哪一些分片沒分配」與「為什麼系統不願意分配它們」。

如果你在 AWS OpenSearch Service 上操作，建議先從控制台的叢集健康、節點數量、磁碟使用率與 CloudWatch 指標看起，再進一步用 API 檢查未分配分片。這樣能避免在沒有方向的情況下反覆試錯。

二、排查前先看這四個訊號

1. 叢集健康狀態

先確認是整個叢集紅，還是只有部分索引受影響。最基本的查法如下：

GET _cluster/health

重點看幾個欄位：status、unassigned_shards、active_primary_shards、initializing_shards、relocating_shards。若 status 是 red，而且 unassigned_shards 大於零，代表至少有主分片失聯。若只是 yellow，通常是副本分片問題，服務仍可用，但容錯能力下降。

2. 未分配分片清單

接著看哪些分片沒被分到節點上：

GET _cat/shards?v

你會看到 index、shard、prirep、state、unassigned.reason 等欄位。先找 state 為 UNASSIGNED 的項目，再看它是主分片還是副本分片。主分片如果沒分配，優先級最高，因為這直接影響索引可用性。

3. 分配失敗原因

很多問題不是看狀態就能知道，還要問系統為什麼不分配。這時最有用的是 allocation explain：

GET _cluster/allocation/explain

如果你的環境支援帶入索引與分片資訊，更能直接查到某一片分片被拒絕的理由。常見回覆會提到磁碟水位、節點過濾條件、分片複本限制、節點角色不符、分片已損壞等。

4. 節點與磁碟資源

紅色狀態很常跟資源有關，尤其是磁碟。若節點磁碟快滿，OpenSearch 會為了避免資料風險而拒絕分配新分片。你應該同步查看：

• 節點是否掉線或重啟
• 磁碟使用率是否超過高水位
• JVM 記憶體是否長期偏高
• CPU 是否持續飆高
• 是否存在大量 pending tasks

這些訊號放在一起看，比單看紅燈更容易抓到根因。

三、最常見的幾種原因

1. 節點故障或節點數不足

如果某個承載主分片的節點掛了，而叢集裡又沒有足夠可用節點，分片就無法重新分配。這種情況在只有單一可用區、節點數太少、或故障後沒有自動恢復容量時特別容易發生。若索引的主分片本來就只有一份，節點一失聯，對應資料立即變成紅色。

AWS帳號認證開通 處理這類問題時，先確認節點是暫時重啟還是永久離線。若只是瞬斷，等節點回來後分片通常會自動恢復；若節點已經不可用，就要盡快補上容量或讓分片搬家到其他節點。

2. 磁碟空間不足

這是最常見，也最容易被忽略的原因。OpenSearch 會依據磁碟水位決定是否允許分配分片。當節點磁碟接近上限時，系統可能停止分配，甚至把某些分片遷移出去。若整個叢集都很滿，就會出現沒有任何地方能放分片的窘境。

特別是在 AWS OpenSearch Service，EBS 容量配置太保守、索引成長太快、日誌保留過長，都會讓磁碟壓力迅速上升。你可能原本只是在寫入高峰時看到黃色，過一陣子就變成紅色，因為主分片已經無法重新放置。

3. 分片數量或大小設計不合理

分片不是越多越好。太多小分片會增加管理成本，太大的分片則會讓恢復與搬移時間拉長，節點故障後更難快速重建。若索引分片規劃不合理，平常看起來沒事，一旦某個節點出問題，就容易因為恢復時間過長而把叢集拖進紅色狀態。

實務上，先思考資料量、保留週期、查詢模式與節點規模，再決定分片與副本數，不要照抄預設值。

AWS帳號認證開通 4. 分配條件限制過嚴

有些人會設定 allocation filtering、屬性標籤、區域感知、熱暖層分離，結果條件設得太嚴，最後沒有任何節點符合分配規則。這時分片不是不能分，而是系統找不到能放的位置。

如果你最近改過節點屬性、索引 routing、tier 設定或可用區策略，這一類問題尤其值得優先檢查。

5. 索引或分片損壞

少數情況下，問題不是資源，而是分片資料本身損壞。常見於節點異常中斷、磁碟錯誤、強制關機或底層儲存問題。這時 allocation explain 往往會看到與 shard corrupted、failed recovery、store exception 類似的訊息。

如果真的是分片損壞，通常不能只靠等待恢復，可能需要從快照還原，或視情況刪除壞索引後重建。

四、實際排查的順序，照這樣做最省時間

第一步：先找出受影響的索引

不要一開始就盯著整個叢集。先用 cat shards 找出哪些索引的主分片是 UNASSIGNED，再逐一確認是單一索引出問題，還是多個索引一起受影響。若只有某一個新建索引紅掉，常見是配置錯誤；若多個索引同時出事，通常是節點或磁碟層級的問題。

第二步：確認是不是主分片

主分片與副本分片的處理方式不同。副本沒分配，叢集仍可讀寫，只是容錯降低；主分片沒分配，索引的核心資料就不可用。實務上，遇到紅色，先鎖定主分片，不要被一堆副本訊息干擾。

第三步：看 allocation explain 的理由

分配說明是最有價值的線索。常見的理由包括：

• 節點磁碟不足
• 節點不符合分配規則
• 副本數設太高，導致分配無法滿足
• 節點角色不正確，無法承擔主分片
• 重建中的分片還沒完成

只要把理由看懂，後面通常就很明確了。

第四步：對症下藥，不要亂改設定

很多人急著把副本數改成零，雖然短時間能讓叢集從紅轉黃，但這只是止血，不是治本。若根因是節點不足或磁碟快滿，今天把副本拿掉，明天還是會出事。設定調整應該是為了恢復服務，不是為了掩蓋問題。

五、幾種常見場景怎麼修

場景一：磁碟已滿

先釋放空間或擴充容量。可先清理過期索引、縮短保留週期、刪除不必要的測試資料，必要時擴大 EBS 容量或升級節點規格。等磁碟壓力解除後，分片通常會自動重新分配。

若是 AWS OpenSearch Service，記得同步檢查 CloudWatch 的 FreeStorageSpace 與磁碟使用趨勢。不要等到最後一刻才處理，因為當剩餘空間太低時，恢復動作會變慢，甚至卡住。

場景二：節點已恢復，但分片還是不動

有時節點回來了，分片卻還是卡在 unassigned。這通常表示系統仍在等待恢復，或因為某些限制條件不允許分配。可以再次查看 allocation explain，確認是不是還有水位限制、分配過濾或未完成的 recovery 任務。若等待時間很長，則要懷疑恢復資料量過大，或節點資源不足導致重建緩慢。

場景三：主分片永久遺失

如果主分片真的找不回來，最可靠的做法通常是從快照恢復。這也是為什麼備份不能只寫在制度裡，還要真的定期驗證。沒有快照，資料修復會變得非常被動，很多時候只能承受資料遺失風險。對生產系統來說，這不是可接受的策略。

場景四：配置改錯

如果是 allocation filtering、索引模板、tier 或 zone awareness 設定錯誤，先把最近改動回退，再重新檢查節點標籤與索引條件。這類問題的特徵很明顯：節點明明健康、磁碟也不滿，但分片就是不肯分配。只要恢復正確條件，分片通常會立即開始搬移。

六、AWS OpenSearch 特別要注意的地方

1. 不要只看控制台顏色

AWS 控制台上的紅燈很直觀，但背後真正的原因還是得回到 API 與指標。控制台適合先判斷嚴重程度，不適合直接下結論。尤其在多節點、多可用區、快照還原或升級期間，表面上看起來像同一種紅色，實際原因可能完全不同。

2. 留意 Auto-Tune 與容量變化

如果環境有開啟自動調整或正在做容量擴縮，分片分配會受到短期影響。這段時間不要急著大動作改索引結構，先確認節點狀態穩定，再觀察分片是否回到正常分布。

3. 多可用區設計要和副本數對齊

若你啟用了多可用區，但副本或節點配置不合理，恢復時可能出現分片找不到符合條件的節點。設計高可用架構時，副本數、節點數與可用區數量要一起考慮，不能只看單一項。

4. 快照與監控要一起做

快照是最後一道防線，監控是第一道防線。只做快照不做告警，常常是等到紅了才發現；只做監控不做快照，出事後也不一定救得回來。真正穩定的做法，是把容量告警、節點存活、磁碟使用率、未分配分片數量一起納入監控。

AWS帳號認證開通 七、建立一套可重複使用的排查習慣

紅色狀態最怕的不是問題本身，而是每次都靠臨場反應。久了之後，團隊會陷入同樣的坑：先重啟、再觀察、再猜測，最後才回頭看根因。比較好的方式，是把排查流程固定下來。

• 先看 cluster health
• 再看 unassigned shards
• AWS帳號認證開通 接著用 allocation explain 找原因
• 最後依原因處理磁碟、節點、配置或快照

這套順序的好處很直接：能把情緒性的處理，變成結構化的判斷。你會更快知道是暫時故障、資源不足，還是設定錯誤，也更容易把經驗累積成團隊規範。

八、預防永遠比搶修便宜

叢集變紅之後再救，永遠比平常預防來得貴。真正成熟的做法，是把問題消滅在還是黃色、還是警告階段時。至少要做到以下幾件事：

• 定期檢查磁碟成長趨勢
• 為關鍵索引設定合理分片與副本
• 維持足夠的節點冗餘
• 定期驗證快照可還原
• 為未分配分片建立即時告警

如果你的資料量正在快速成長，最好每隔一段時間回頭檢視分片策略。很多叢集一開始很健康，後來出事，不是因為平台不穩，而是資料規模已經超過原本的設計假設。

九、結語

AWS OpenSearch 或 Elasticsearch 叢集出現紅色狀態，核心問題只有一句話：至少有一個主分片找不到可以安放的地方。後面所有的排查，其實都是在回答兩件事：為什麼找不到，以及怎樣讓它重新被安放。

只要你先從健康狀態、未分配分片與 allocation explain 下手，再往節點、磁碟、設定與快照檢查，通常都能在最短時間內找到方向。遇到紅燈時，別急著猜，也別急著亂動，先把事實看清楚，修復才會快，而且不容易留下後遺症。