通过我们简单的教程指南掌握调试无响应的 Elasticsearch 集群。对于有问题或不稳定的 Elasticsearch 设置，请尝试这种有效的解决方案。
Elasticsearch 是一个开源搜索引擎和分析商店，可供各种应用程序使用，从电子商务商店中的搜索到使用 ELK 堆栈（“Elasticsearch、Logstash、Kibana”的缩写）的内部日志管理工具。作为分布式数据库，您的数据被划分为“分片”，然后分配给一台或多台服务器。
由于这种分片，对 Elasticsearch 集群的读取或写入请求需要在多个节点之间进行协调，因为单个服务器上没有数据的“全局视图”。虽然这使得 Elasticsearch 具有高度可扩展性，但它的设置和调整也比其他流行数据库（例如 MongoDB 或 PostgresSQL）（可以在单个服务器上运行）复杂得多。
当出现可靠性问题时，如果您的 Elasticsearch 设置有问题或不稳定，救火可能会带来压力。您的事件可能会影响客户，从而对收入和您的商业声誉产生负面影响。快速修复步骤很重要，但在事件或中断期间花费大量时间在线研究解决方案对于大多数工程师来说并不是一件奢侈的事情。本指南旨在作为工程师运行的常见问题的备忘单，这些问题可能会导致 Elasticsearch 出现问题以及需要查找的内容。
作为通用工具，Elasticsearch 拥有数千种不同的配置，使其能够适应各种不同的工作负载。即使在线发布，适用于一家公司的数据模型或配置也可能不适合您的公司。让 Elasticsearch 扩展并没有灵丹妙药，需要勤奋的性能测试和反复试验。
Elasticsearch 集群无响应问题
集群稳定性问题是最难调试的问题，尤其是在数据量或代码库没有变化的情况下。
检查集群状态的大小
它有什么作用？
Elasticsearch 集群状态跟踪集群的全局状态，是控制流量和集群的核心。集群状态包括集群中节点的元数据、分片的状态以及它们如何映射到节点、索引映射（即架构）等。
集群状态通常不会经常改变。但是，某些操作（例如向索引映射添加新字段）可能会触发更新。
由于集群更新会广播到集群中的所有节点，因此它应该很小（<100MB）。
较大的集群状态很快就会使集群变得不稳定。发生这种情况的常见方式是通过映射爆炸（索引中的键太多）或索引太多。
要找什么
使用以下命令下载集群状态并查看返回的 JSON 的大小。
curl -XGET 'http://localhost:9200/_cluster/state'
特别是，查看哪些索引在集群状态中拥有最多字段，这可能是导致稳定性问题的违规索引。如果集群状态很大并且不断增加。您还可以通过查看单个索引或与索引模式的匹配来获得想法，如下所示：
curl -XGET 'http://localhost:9200/_cluster/state/_all/my_index-*'
您还可以使用以下命令查看有问题的索引的映射：
curl -XGET 'http://localhost:9200/my_index/_mapping'
怎么修
查看数据是如何索引的。发生映射爆炸的常见方式是使用高基数标识符作为 JSON 键。每次看到新的键（例如“4”和“5”）时，集群状态都会更新。例如，下面的 JSON 很快就会导致 Elasticsearch 出现稳定性问题，因为每个键都被添加到全局状态中。
{ "1": { "status": "ACTIVE" }, "2": { "status": "ACTIVE" }, "3": { "status": "DISABLED" } }要解决此问题，请将数据扁平化为 Elasticsearch 友好的内容：
{ [ { "id": "1", "status": "ACTIVE" }, { "id": "2", "status": "ACTIVE" }, { "id": "3", "status": "DISABLED" } ]}
检查Elasticsearch任务队列
它有什么作用？
当对elasticsearch发出请求（索引操作、查询操作等）时，它首先被插入到任务队列中，直到工作线程可以拾取它。
一旦工作池有空闲线程，它就会从任务队列中选取一个任务并处理它。
这些操作通常由您通过:9200和:9300端口上的 HTTP 请求进行，但它们也可以是内部操作，用于处理索引上的维护任务
在给定时间，可能有数百或数千个正在进行的操作，但应该很快完成（如微秒或毫秒）。
要找什么
运行以下命令并查找长时间运行（例如几分钟或几小时）的任务。
这意味着某些东西正在使集群挨饿并阻止其取得进展。
对于某些长时间运行的任务（例如移动索引）需要很长时间是可以的。但是，正常的查询和索引操作应该很快。
curl -XGET 'http://localhost:9200/_cat/tasks?detailed'
通过?detailed参数，您可以获得有关目标索引和查询的更多信息。
寻找任务始终位于列表顶部的模式。是同一个索引吗？是同一个节点吗？
如果是这样，则该索引的数据可能有问题或者节点过载。
怎么修
如果请求量高于正常情况，则考虑优化请求的方法（例如使用批量 API 或更高效的查询/写入）
如果体积没有变化并且看起来是随机的，则意味着其他因素正在减慢集群速度。任务的备份只是一个更大问题的症状。
如果您不知道请求来自何处，请将X-Opaque-Id标头添加到您的 Elasticsearch 客户端以识别哪些客户端正在触发查询。
检查 Elasticsearch 待处理任务
它有什么作用？
挂起任务是对集群状态的挂起更新，例如创建新索引或更新其映射。
与之前的任务队列不同，挂起的更新需要多步握手才能将更新广播到集群中的所有节点，这可能需要一些时间。
在给定时间内，正在进行的任务应该几乎为零。请记住，快照恢复等昂贵的操作可能会导致该值暂时飙升。
要找什么
运行命令并确保没有或很少有任务正在进行。
curl curl curl -XGET 'http://localhost:9200/_cat/pending_tasks'
如果它看起来是快速完成的持续的集群更新流，请查看可能触发它们的原因。是映射爆炸还是创建了太多索引？
如果只有几个，但它们似乎卡住了，请查看主节点的日志和指标，看看是否存在任何问题。例如，主节点是否遇到内存或网络问题，导致无法处理集群更新？
热门话题
它有什么作用？
热线程 API 是一个有价值的内置分析器，可以告诉您 Elasticsearch 在哪里花费了最多的时间。
这可以提供洞察，例如 Elasticsearch 是否在索引刷新或执行昂贵的查询上花费了太多时间。
要找什么
调用热线程 API。为了提高准确性，建议使用?snapshots参数捕获许多快照
curl -XGET 'http://localhost:9200/_nodes/hot_threads?snapshots=1000'
这将返回拍摄快照时看到的堆栈跟踪。
在许多不同的快照中寻找相同的堆栈。例如，您可能会看到文本5/10 snapshots sharing following 20 elements。这意味着线程在 5 个快照期间将时间花在代码的该区域中。
您还应该查看 CPU %。如果某个代码区域同时具有高快照共享和高 CPU %，则这是热代码路径。
通过查看代码模块，反汇编Elasticsearch在做什么。
如果您看到等待或停放状态，这通常没问题。
怎么修
如果大量 CPU 时间花费在索引刷新上，请尝试将刷新间隔增加到默认的 1 秒以上。
如果您看到缓存中有大量内容，则可能您的默认缓存设置不是最佳的并导致严重失误。
内存问题
检查 Elasticsearch 堆/垃圾收集
它有什么作用？
作为 JVM 进程，堆是存储大量 Elasticsearch 数据结构的内存区域，需要垃圾收集周期来修剪旧对象。
mlockall对于典型的生产设置，Elasticsearch 使用启动时锁定所有内存并禁用交换。如果你不这样做，现在就做。
如果某个节点的堆始终高于 85% 或 90%，则意味着我们即将耗尽内存。
要找什么
在 Elasticsearch 日志中搜索collecting in the last。如果存在这些，则意味着 Elasticsearch 在垃圾收集上花费了更高的开销（这会占用其他生产任务的时间）。
只要 Elasticsearch 不将大部分 CPU 周期花费在垃圾收集上（计算收集所花费的时间相对于所提供的总时间的百分比），偶尔执行一些操作就可以了。
花费 100% 时间进行垃圾收集的节点将陷入停滞，无法取得进展。
看似存在超时等网络问题的节点实际上可能是由于内存问题造成的。这是因为节点无法在垃圾收集周期期间响应传入请求。
怎么修
最简单的方法是添加更多节点以增加集群可用的堆。然而，Elasticsearch 将分片重新平衡到空节点需要时间。
如果只有一小部分节点具有较高的堆使用率，您可能需要更好地平衡您的客户。例如，如果您的分片大小差异很大或具有不同的查询/索引带宽，则您可能向同一组节点分配了太多热分片。要移动分片，请使用重新路由 API。只需调整分片感知灵敏度即可确保其不会被移回。
curl -XPOST -H "Content-Type: application/json" localhost:9200/_cluster/reroute -d '{"commands": [ { "move": { "index": "test", "shard": 0, "from_node": "node1", "to_node": "node2" } } ]}'如果您要向 Elasticsearch 发送大量请求，请尝试减小批处理大小，使每个批处理小于 100MB。虽然较大的批次有助于减少网络开销，但它们需要分配更多内存来缓冲请求，而这些内存在请求完成和下一个 GC 周期之前无法释放。
检查 Elasticsearch 旧内存压力
它有什么作用？
旧内存池包含在多个垃圾回收周期中幸存下来的对象，并且是长期存在的对象。
如果旧内存超过75%，你可能要注意了。当填充超过 85% 时，将会发生更多 GC 周期，但对象无法被清理。
要找什么
查看旧池已用/旧池最大。如果超过 85%，那就令人担忧了。
怎么修
您是否急于加载大量现场数据？这些都长期存在于记忆中。
您是否正在执行许多长时间运行的分析任务？某些任务应该卸载到专为 Map/Reduce 操作（例如 Apache Spark）而设计的分布式计算框架。
检查 Elasticsearch 字段数据大小
它有什么作用？
FieldData用于计算某个字段上的聚合，例如terms聚合
通常，直到第一次对其执行聚合时，字段的字段数据才会加载到内存中。
eager_load_ordinals但是，如果设置了，也可以在索引刷新时预先计算。
要找什么
查看一个索引或所有索引字段数据大小，如下所示：
curl -XGET 'http://localhost:9200/index_1/_stats/fielddata'
如果我们在错误类型的数据上使用索引，则索引可能具有非常大的字段数据结构。您是否对基数非常高的字段（例如 UUID 或跟踪 id）执行聚合？字段数据不适合基数非常高的字段，因为它们会创建大量字段数据结构。
您是否有很多字段已eager_load_ordinals设置或分配了大量字段数据缓存。这会导致在刷新时间与查询时间生成字段数据。虽然它可以加快聚合速度，但如果您在索引刷新时计算许多字段的字段数据并且从不在查询中使用它，那么它并不是最佳选择。
怎么修
对查询或映射进行调整，以免在基数非常高的键上聚合。
审核您的映射以减少设置为 true 的数量eager_load_ordinals。
Elasticsearch 网络问题
节点离开或节点断开
它有什么作用？
如果节点不响应请求，它最终将从集群中删除。
这允许将分片复制到其他节点以满足复制因子并确保高可用性，即使节点被删除也是如此。
要找什么
查看主节点日志。即使有多个主节点，您也应该查看当前选举的主节点。您可以使用节点 API 或 Cerebro 等工具来执行此操作。
查看是否存在超时或有问题的一致节点。pending nodes例如，您可以通过在主节点日志中查找该短语来查看哪些节点仍在等待集群更新。
如果您看到同一节点不断添加然后又被删除，则可能意味着该节点过载或无响应。
如果您无法从主节点访问该节点，则可能意味着存在网络问题。您还可能遇到 NIC 或 CPU 带宽限制
怎么修
将设置设置transport.compression为 true 进行测试这将压缩节点之间的流量（例如从摄取节点到数据节点），以牺牲 CPU 带宽为代价减少网络带宽。
注意：早期版本称为此设置transport.tcp.compression
如果您也有内存问题，请尝试增加内存。由于垃圾收集花费大量时间，节点可能会变得无响应。
主节点不足的问题
它有什么作用？
主节点和其他节点需要互相发现才能形成集群。
第一次启动时，您必须提供一组静态主节点，这样就不会出现脑裂问题。
只要主节点存在，其他节点就会自动发现集群。
要找什么
启用跟踪日志记录以查看与发现相关的活动。
curl -XPUT -H "Content-Type: application/json" localhost:9200/_cluster/_settings -d '{ "transient": {"logger.discovery.zen":"TRACE"}}'检查配置，例如minimum_master_nodes（如果早于 6.x）。
查看初始主节点列表中的所有主节点是否可以互相 ping 通。
检查您是否达到 法定人数，应该达到法定人数number of master nodes / 2 +1。如果少于法定人数，则不会更新集群状态以保护数据完整性。
怎么修
有时网络或 DNS 问题可能会导致原始主节点无法访问。
检查当前是否至少有number of master nodes / 2 +1主节点正在运行。
分片分配错误
Elasticsearch 处于黄色或红色状态（未分配的分片）
它有什么作用？
当节点重新启动或启动集群恢复时，分片不会立即可用。
恢复受到限制，以确保集群不会不堪重负。
黄色状态表示主索引已分配，但辅助（副本）分片尚未分配。虽然黄色索引既可读又可写，但可用性会降低。当集群复制分片时，黄色状态通常是可自我修复的。
红色索引表示主分片未分配。这可能是暂时的，例如在快照恢复操作期间，但也可能意味着重大问题，例如丢失数据。
要找什么
查看分配停止的原因。
curl -XGET 'http://localhost:9200/_cluster/allocation/explain'curl -XGET 'http://localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason'
获取红色指数列表，以了解哪些指数导致红色状态。只要至少有一个索引为红色，集群状态就会处于红色状态。
curl -XGET 'http:localhost:9200/_cat/indices' | grep red
有关单个索引的更多详细信息，您可以查看有问题的索引的恢复状态。
curl -XGET 'http:localhost:9200/index_1/_recovery'
怎么修
如果您看到 max_retries 超时（可能集群在分配期间很忙），您可以暂时增加断路器阈值（默认为 5）。一旦数量高于断路器，Elasticsearch 将开始初始化未分配的分片。
curl -XPUT -H "Content-Type: application/json" localhost:9200/index1,index2/_settings -d '{ "index.allocation.max_retries": 7}'
Elasticsearch 磁盘问题
索引是只读的
它有什么作用？
Elasticsearch 具有三个基于磁盘的水印，这些水印会影响分片分配。水印cluster.routing.allocation.disk.watermark.low可防止将新分片分配给磁盘已满的节点。默认情况下，这是已用磁盘的 85%。
水印cluster.routing.allocation.disk.watermark.high将强制集群开始将分片从节点移动到其他节点。默认情况下，这是 90%。这将开始移动数据，直到低于高水位线。如果 Elasticsearch 磁盘超过了洪水阶段水位线cluster.routing.allocation.disk.watermark.flood_stage，则表示磁盘已满，以至于在磁盘空间耗尽之前移动速度可能不够快。达到时，索引将置于只读状态以避免数据损坏。
要找什么
查看每个节点的磁盘空间。
查看节点日志中是否有如下消息：
high disk watermark [90%] exceeded on XXXXXXXX free: 5.9gb[9.5%], shards will be relocated away from this node
一旦达到洪水阶段，您将看到如下日志：
flood stage disk watermark [95%] exceeded on XXXXXXXX free: 1.6gb[2.6%], all indices on this node will be marked read-only
一旦发生这种情况，该节点上的索引就是只读的。
要进行确认，请查看哪些索引已read_only_allow_delete设置为 true。
curl -XGET 'http://localhost:9200/_all/_settings?pretty' | grep read_only
怎么修
首先，清理磁盘空间，例如删除本地日志或 tmp 文件。
要删除此只读块，请执行以下命令：
curl -XPUT -H "Content-Type: application/json" localhost:9200/_all/_settings -d '{ "index.blocks.read_only_allow_delete": null}'
结论
解决稳定性和性能问题可能具有挑战性。找到根本原因的最好方法是使用科学的假设方法并证明其正确或错误。使用这些工具和 Elasticsearch 管理 API，您可以深入了解 Elasticsearch 的执行情况以及可能出现问题的位置。文章来源：https://www.toymoban.com/diary/share/371.html
文章来源地址https://www.toymoban.com/diary/share/371.html
到此这篇关于如何调试无响应的 Elasticsearch 集群的文章就介绍到这了,更多相关内容可以在右上角搜索或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
