问题
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：每个分片中的平均延迟。
您可以通过更改索引的分片数来验证上述结论，然后查看它如何更改。