因此，碰巧我們在SaaS版本的LogSentinel上遇到了生產(chǎn)問題–我們的Elasticsearch停止了對新數(shù)據(jù)編制索引。 由于Elasticsearch只是輔助存儲，因此沒有數(shù)據(jù)丟失，但這給我們的客戶帶來了一些問題（他們無法在其儀表板上看到實時數(shù)據(jù)）。 以下是事后分析–發(fā)生了什么事情，發(fā)生了什么原因，我們?nèi)绾翁幚硭约叭绾畏乐顾?

讓我從系統(tǒng)如何運行的背景開始–我們通過RESTful API（或syslog）接受審核跟蹤條目（日志），并將其推送到Kafka主題。 然后使用Kafka主題將數(shù)據(jù)存儲在主存儲（Cassandra）中并對其進行索引，以便在Elasticsearch中更好地進行可視化和分析。 選擇托管的AWS Elasticsearch服務(wù)是因為它節(jié)省了集群管理的所有開銷，并且作為一家啟動公司，我們希望最大程度地減少基礎(chǔ)架構(gòu)管理工作。 就像下面將要看到的那樣，這是一種祝福和詛咒。

我們在許多元素上啟用了警報，包括Elasticsearch存儲空間和日志文件中的應(yīng)用程序錯誤數(shù)。 這使我們能夠快速響應(yīng)問題。 因此觸發(fā)了“大量應(yīng)用程序錯誤”警報。 索引由于FORBIDDEN/8/index write而被阻止。 我們有一個啟用它的系統(tǒng)調(diào)用，因此我嘗試運行它，但是不到一分鐘后，它再次被阻止。 這意味著我們的Kafka使用者無法處理消息，這很好，因為我們在Kafka中有足夠的消息保留期限，因此不會丟失任何數(shù)據(jù)。

我調(diào)查了這種阻止的可能原因。 根據(jù)Amazon的說法，其中有兩個 -JVM內(nèi)存壓力增加和磁盤空間不足。 我檢查了指標，一切看起來都很好– JVM內(nèi)存壓力幾乎沒有達到70％（閾值是75％），并且有超過200GiB的免費存儲。 Elasticsearch應(yīng)用程序日志中只有一個WARN（這是“節(jié)點故障”，但此后未報告任何問題）

這個問題還有另一個奇怪的方面–節(jié)點的數(shù)量是配置的兩倍。 這通常在升級期間發(fā)生，因為AWS正在為Elasticsearch使用藍色/綠色部署，但是我們最近沒有進行任何升級。 這些額外的節(jié)點通常會在很短的一段時間后消失（在重新部署/升級準備就緒之后），但是在這種情況下它們不會消失。

無法通過SSH連接到實際機器，無法通過Elasticsearch手段取消阻止索引，無法關(guān)閉或重新啟動節(jié)點，我提出了支持請求。 經(jīng)過我們幾次和幾次交流后，問題已經(jīng)明確并得到解決。

此問題的主要原因是2倍。 首先，我們有一個無法反映集群狀態(tài)的配置–我們假設(shè)有更多的節(jié)點，而共享和副本配置意味著我們沒有分配副本（ 此處和此處的 碎片和副本更多 ）。 最佳實踐是使節(jié)點>副本數(shù)，以便每個節(jié)點獲得一個副本（加上主分片）。 擁有未分配的分片副本本身并不壞，并且有合理的理由。 我們可能被認為是配置錯誤，但不是立即造成負面影響的一種。 我們之所以選擇這些設(shè)置，部分原因是創(chuàng)建集群后無法在AWS中更改某些設(shè)置。 并且不支持打開和關(guān)閉索引。

第二個問題是AWS Elasticsearch邏輯，用于計算其斷路器中阻止索引編制的可用存儲。 因此，即使每個現(xiàn)有節(jié)點上都有200+ GiB可用空間，AWS Elasticsearch仍認為我們空間不足并阻止了索引編制。 我們無法看到這一點，因為我們只能看到可用的存儲，而沒有看到AWS認為可用的存儲。 因此，計算將獲得分片+副本的總數(shù)，然后將其乘以每個共享存儲。 這意味著未分配副本不會占用實際空間，就好像它們已占用空間一樣。 這種邏輯是違反直覺的（如果不是完全錯誤的話），幾乎沒有辦法預(yù)測它。

發(fā)生藍/綠部署時，將觸發(fā)此邏輯–因此，在正常操作中，將檢查實際的剩余存儲空間，但是在升級期間，將觸發(fā)基于分片的檢查。 那已經(jīng)阻塞了整個集群。 但是，什么觸發(fā)了藍綠色部署過程？

我們有時需要訪問Kibana，并且由于嚴格的安全規(guī)則，默認情況下任何人都無法訪問它。 因此，我們臨時更改了訪問策略，以允許從我們的辦公室IP進行訪問。 預(yù)計此更改不會觸發(fā)新的部署，也永遠不會導(dǎo)致這種變化。 但是，AWS文檔指出：

在大多數(shù)情況下，以下操作不會導(dǎo)致藍綠色部署：更改訪問策略，更改自動快照時間，如果您的域具有專用主節(jié)點，則更改數(shù)據(jù)實例計數(shù)。
有一些例外。 例如，如果自啟動三個可用區(qū)支持以來您尚未重新配置域，則Amazon ES可能會執(zhí)行一次藍/綠部署，以在可用區(qū)中重新分配專用主節(jié)點。

顯然還有其他例外，其中之一發(fā)生在我們身上。 這就導(dǎo)致了藍色/綠色的部署，由于我們的配置有缺陷，這又觸發(fā)了基于奇數(shù)邏輯的索引塊，以假定未分配的副本占用了存儲空間。

我們?nèi)绾涡迯?fù)它-我們用更少的副本創(chuàng)建了索引，并開始了重新索引（它從主要來源獲取數(shù)據(jù)并成批索引）。 這減小了占用空間，AWS手動干預(yù)以“取消”藍/綠部署。 一旦知道了問題，修復(fù)就很容易了（由于其他索引配置的更改，我們?nèi)匀槐仨氈匦聞?chuàng)建索引）。 （再次）說一下在解決問題和溝通方面，AWS支持有多好。

正如我在開始時所說的，這并不意味著有數(shù)據(jù)丟失，因為我們讓Kafka將消息保留了足夠的時間。 但是，一旦索引可寫，我們就希望使用者從上一次成功發(fā)送的消息開始繼續(xù)-我們專門編寫了事務(wù)處理行為，該行為僅在成功存儲到主存儲中并成功建立索引之后才提交偏移量。 不幸的是，我們正在使用的kafka客戶端打開了我們忽略的自動提交功能。 因此，消費者跳過了失敗的消息。 它們?nèi)匀辉贙afka中，我們正在使用單獨的工具對其進行處理，但這向我們表明了我們的假設(shè)是錯誤的，并且代碼調(diào)用了“ commit”這一事實，但這實際上并不意味著什么。

因此，故事的寓意是：

• 監(jiān)視一切。 發(fā)生壞事，快速了解它們是一件好事。
• 檢查您的生產(chǎn)配置，并確保它足以滿足當前需求。 它是副本，JVM大小，磁盤空間，重試次數(shù)，自動縮放規(guī)則等。
• 請注意托管云服務(wù)。 他們節(jié)省了很多精力，但也使您失去了控制權(quán)。 他們可能遇到的問題是您唯一的選擇就是聯(lián)系支持部門。
• 如果提供托管服務(wù)，請確保顯示有關(guān)潛在邊緣情況的足夠信息。 錯誤控制臺，活動控制臺或諸如此類，使客戶可以了解發(fā)生了什么。
• 驗證關(guān)于庫默認設(shè)置的假設(shè)。 （理想情況下，如果您在當前的配置狀態(tài)下執(zhí)行了某些意外操作，則庫應(yīng)該警告您）
• 確保您的應(yīng)用程序是容錯的，即，一個組件中的故障不會停止整個世界，也不會導(dǎo)致數(shù)據(jù)丟失。

因此，總的來說，一個罕見的事件意外觸發(fā)了藍綠色部署，其中有缺陷的配置和有缺陷的可用空間計算的結(jié)合導(dǎo)致了不可寫的集群。 幸運的是，沒有數(shù)據(jù)丟失，至少我學到了一些東西。

翻譯自: https://www.javacodegeeks.com/2020/03/an-aws-elasticsearch-post-mortem.html

總結(jié)

以上是生活随笔為你收集整理的AWS Elasticsearch后模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。