問題

Elasticsearch提供了一個名為Marvel的便捷監控工具。 它很容易設定。 但是，當涉及到真正的監控時，您會發現儀表板中的那些指標非常混亂。 它們與發你送到群集的實際QPS不一致。 你真的不知道他們所指的是什麼。

解決

我用Google搜尋了一下。 但不幸的是沒有找到答案。 我唯一得到的是Marvel論壇上的帖子，其中有人和我一樣困惑。

然後我試著找到Marvel的原始碼。 但我找不到任何東西，因為它不是開源的。 我真的認為Marvel需要更多的改進。 他們真的應該開源。

                                                                              Average Search Latency

當我在搜尋效能上掙扎時，找到了答案。 我重新索引了所有資料，以嘗試它是否會影響效能。 令我驚訝的是，在我改為單個分片後，平均搜尋延遲從大約30ms降至7ms。 搜尋速率也降至10k / s左右，這正是我傳送給Elasticsearch叢集的請求的估計值。 所有的奧祕都消失了，一切都變得清晰。

                                                                                        Marvel Dashboard

首先是“Search Rate”。 當索引有10個分片時，它大約是實際請求的10倍。 當索引只有1個分片時，它幾乎與實際請求相同。

然後“Search Latency”。 當索引有10個分片時，大約是0.9ms，但端到端延遲大約是30ms。 當單個分片時，它上升到1.88ms，而端到端延遲僅為7ms。 這可能是因為每個分片的資料量因分片的減少而增加，因此每個分片中的搜尋時間更長。 但是不再需要合併結果。 在這裡，我們可以看到合併結果的嚴重程度如何影響搜尋效能。

“Index Rate”和“Indexing Latency”也是相同的原因。

總結

這些詞的含義如下：

• Search Rate：對於單個索引，它是每秒查詢次數*分片數。 對於多個索引，它是每個索引的搜尋速率的總和。
• Search Latency：每個分片中的平均延遲。
• Indexing Rate：對於單個索引，它是每秒索引的數量*分片數量。 對於多個索引，它是每個索引的索引速率的總和。
• Indexing Latency：每個分片中的平均延遲。

您可以通過更改索引的分片數來驗證上述結論，然後檢視它如何更改。