Apache SkyWalking 接入 Elasticsearch 存储的常见故障排查指南：429 写入拒绝与查询窗口问题

Apache SkyWalking 接入 Elasticsearch 存储的常见故障排查指南429 写入拒绝与查询窗口问题【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sky/skywalking导读本指南基于 Apache SkyWalking 官方 FAQ 文档docs/en/FAQ/ES-Server-FAQ.md系统讲解 SkyWalking OAP 以 Elasticsearch 为存储后端时最常见的两类故障HTTP 429 Too Many Requestses_rejected_execution_exception写入线程池拒绝与数据查询超窗/查不到最新数据。读完本文你将理解这两类问题的成因掌握在elasticsearch.yml中调整线程池队列与max_result_window的具体参数和取值依据并能结合 OAP 侧application.yml的存储配置bulkActions、concurrentRequests、resultWindowMaxSize等做整体调优让 SkyWalking 在高吞吐写入场景下稳定运行。背景SkyWalking 与 Elasticsearch 的协作方式SkyWalking OAP 通过 storage-elasticsearch-plugin 以REST API方式访问 Elasticsearch无需为不同 ES 服务端版本下载不同的二进制包客户端会自动适配服务端请求格式。OAP 侧默认使用以下索引存储各类遥测数据sw_management管理数据UI 面板设置、菜单、持续剖析策略等sw_metrics-all-${day-format}MAL/OAL 引擎产生的指标及服务/实例/端点元数据sw_segment-${day-format}原生 Trace 段sw_log-${day-format}、sw_browser_error_log-${day-format}日志数据sw_zipkin_span-${day-format}Zipkin Tracesw_records-all-${day-format}采样记录慢 SQL、Agent 剖析、eBPF 剖析等。完整存储配置可参见 docs/en/setup/backend/storages/elasticsearch.md。正是由于 SkyWalking 会持续、批量地写入大量 Trace/指标数据Elasticsearch 服务端集群的写入线程池与查询窗口配置是否合理直接决定了系统稳定性。故障一HTTP 429 Too Many Requests写入被拒绝典型报错形态当 Elasticsearch 服务端写入线程池过载时SkyWalking OAP 日志中会出现形如下面的错误来自 FAQ 原文实际为 Elasticsearch 6.3.2 客户端Suppressed: org.elasticsearch.client.ResponseException: method [POST], host [http://127.0.0.1:9200], URI [/service_instance_inventory/type/6_tcc-app-gateway-77b98ff6ff-crblx.cards_0_0/_update?refreshtruetimeout1m], status line [HTTP/1.1 429 Too Many Requests] {error:{root_cause:[{type:remote_transport_exception,reason:[elasticsearch-0][10.16.9.130:9300][indices:data/write/update[s]]}],type:es_rejected_execution_exception,reason:rejected execution of org.elasticsearch.transport.TransportService$719a5cf02 on EsThreadPoolExecutor[name elasticsearch-0/write, queue capacity 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor389297ad[Running, pool size 2, active threads 2, queued tasks 200, completed tasks 147611]]},status:429} at org.elasticsearch.client.RestClient$SyncResponseListener.get(RestClient.java:705) ~[elasticsearch-rest-client-6.3.2.jar:6.3.2] ...报错含义解读拆解这段 JSON 错误信息可以定位到问题本质字段值含义typees_rejected_execution_exception写入请求被 Elasticsearch 线程池拒绝执行nameelasticsearch-0/write被拒绝的线程池是write写入线程池queue capacity200该线程池队列容量仅 200active threads/pool size2/2写入线程已全部处于活跃状态queued tasks200队列已排满 200 个待处理任务completed tasks147611此前已完成大量写入任务说明吞吐压力持续存在当 SkyWalking OAP 以高采样率持续写入海量 Trace/指标时ES 服务端write线程池的线程全部忙碌、队列被排满新到达的写入请求就会直接被拒绝返回 HTTP 429。这通常意味着服务端容量线程/队列小于客户端施加的写入压力是 SkyWalking 接入 ES 后最常见的性能瓶颈表现。FAQ 推荐的修复配置FAQ 原文给出如下修复方案在Elasticsearch 服务端的elasticsearch.yml中添加以下配置并按实际环境调整取值# 在追踪tracing场景下建议设置为比默认值更高的值。 thread_pool.index.queue_size: 1000 thread_pool.write.queue_size: 1000 # 当你在 Trace 页面遇到查询报错时记得检查这一项。 index.max_result_window: 1000000参数说明thread_pool.write.queue_sizewrite线程池的队列容量默认约 200。SkyWalking 会高频写入 Trace 段、指标、日志等数据建议提升到1000左右为写入请求提供更大的缓冲空间避免瞬时流量尖峰触发 429。取值需结合 JVM 堆大小与机器内存评估队列越长堆积时占用的内存也越多。thread_pool.index.queue_sizeindex线程池的队列容量同样建议提升到1000左右。index.max_result_window单次查询允许返回的最大from size默认 10000。见下文“故障二”。版本适配注意点结合仓库中 docs/en/setup/backend/storages/elasticsearch.mdRecommended ElasticSearch server-side configurations 一节的补充说明以上配置存在版本差异thread_pool.index.queue_size: 1000——仅适用于 ElasticSearch 6thread_pool.write.queue_size: 1000——适用于 ElasticSearch 6 与 7在 Elasticsearch 8.x 中节点级线程池配置的语义和默认值已有变化请以对应版本官方文档为准SkyWalking 官方支持并测试过 Elasticsearch 7.x、8.x 与 OpenSearch 1.xOpenSearch 1.1.0/1.3.10、2.4.0/2.8.0Elasticsearch 6 因已官宣 EOL 而“可用但不再承诺维护”。为什么 429 常与“最新数据查不到”同时出现FAQ 开篇指出新用户常遇到两个问题一是“ES 性能不如预期比如一段时间后最新数据无法访问”二是“ERROR CODE 429”。两者往往是同一根因的两面写入被拒 → 数据落库延迟 → 查询端看不到最新数据。因此在调优时应先确认写入路径是否稳定无 429再排查查询路径的窗口限制。故障二Trace 页查询报错与最大结果窗口max_result_window成因from size超过窗口上限Elasticsearch 的搜索请求使用from size进行分页。当from size超过索引的index.max_result_window默认 10000时服务端会直接拒绝查询。SkyWalking 的 Trace 查询实现TraceQueryEsDAO.java使用search.size(limit).from(from)组织分页查询因此当用户在 Trace 页面翻页过深或一次查询命中的文档数超过 10000 时就会触发该错误。FAQ 的解决方案是在elasticsearch.yml中调高窗口# 当你在 Trace 页面遇到查询报错时记得检查这一项。 index.max_result_window: 1000000将上限从默认的 10000 提升到1000000即可覆盖绝大多数深翻页与大数据量查询场景。OAP 侧对应配置resultWindowMaxSizeOAP 侧同样有一个查询窗口配置项用于控制客户端一次最多请求的窗口大小。在 StorageModuleElasticsearchConfig.java 中定义private int resultWindowMaxSize 10000;对应application.yml中的配置为server-starter/application.ymlstorage: selector: ${SW_STORAGE:elasticsearch} elasticsearch: resultWindowMaxSize: ${SW_STORAGE_ES_QUERY_MAX_WINDOW_SIZE:10000}该值会被查询 DAO 用于限制单次查询窗口例如 NetworkAddressAliasEsDAO.java 中通过Math.min(resultWindowMaxSize, scrollingBatchSize)约束批量查询大小。调优要点OAP 侧resultWindowMaxSize与 ES 服务端index.max_result_window需要配套调整。如果只调大服务端窗口、不调大客户端窗口客户端仍会被自身 10000 的上限截断反之亦然。建议两端设置为一致的值如 1000000并注意服务端窗口过大会显著增加深分页查询的内存与 CPU 开销。大数据量场景的替代方案Scroll / 分批查询对于超大结果集如全量元数据、eBPF 剖析数据SkyWalking 提供了滚动分批查询机制。从源码配置可见metadataQueryMaxSize默认 5000元数据查询单次最大条数scrollingBatchSize默认 5000当metadataQueryMaxSize大于服务端最大结果窗口时用于 Scroll 分批取回全部结果StorageModuleElasticsearchConfig.javaprofileDataQueryScrollBatchSize默认 100eBPF 剖析数据体量极大单独指定更小的滚动批次默认 100避免单次响应内容过大。纵深OAP 写入路径与 ES 线程池压力的联动调优OAP 侧批量写入参数429 问题的根源是“写得太快、太多”。除了调大 ES 服务端队列还可以从 OAP 侧控制写入节奏。OAP 通过BatchProcessEsDAOBatchProcessEsDAO.java创建BulkProcessor进行批量写入核心参数定义于 StorageModuleElasticsearchConfig.javaOAP 配置项默认值说明bulkActions5000application.yml中示例为 1000每累计多少个请求执行一次异步批量写入flushInterval5 秒application.yml中示例为 10无论是否达到bulkActions每隔该周期强制 flush 一次concurrentRequests2允许的并发批量请求数batchOfBytes10 MB单批数据体积上限达到即触发写入对应的 YAML 配置storage: elasticsearch: bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:1000} # 每 1000 个请求批量提交一次 flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:10} # 每 10 秒强制 flush concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:2} # 并发批量请求数底层BulkProcessorBulkProcessor.java使用Semaphore限制并发数、用ArrayBlockingQueue缓存待处理请求其构建器对参数有明确校验——bulkActions必须为正数、concurrentRequests必须大于等于 0BulkProcessorBuilder.java。联动调优思路ES 端扩容缓冲将thread_pool.write.queue_size提升至 1000或更高吸收瞬时写入尖峰OAP 端节流若 ES 节点资源有限可适当调小concurrentRequests如 12或调大flushInterval降低写入压力峰值批量粒度在磁盘与内存允许的前提下适度调大bulkActions用更大的批量换取更少的请求往返监控验证调优后观察 ES 监控中的thread_pool.write.rejected指标是否归零以及 OAP 日志中是否仍出现 429。索引分片与副本对写入性能的影响写入压力也与索引分片/副本数直接相关。SkyWalking 默认indexShardsNumber: 1、indexReplicasNumber: 1并为超大数据集Trace 段、日志、Zipkin Span、浏览器错误日志提供独立参数superDatasetIndexShardsFactor默认 5与superDatasetIndexReplicasNumber默认 0使这类索引的分片数 indexShardsNumber × superDatasetIndexShardsFactor详见 docs/en/setup/backend/storages/elasticsearch.md 的 Index Settings 小节。分片越多写入可并行度越高但分片过多也会增加集群管理开销需按数据规模平衡。排查与验证步骤汇总确认 429 是否持续出现在 OAP 日志中检索429与es_rejected_execution_exception若只是偶发可先观察再调优。检查写入线程池状态访问 ES 的_cat/thread_pool/write?v或通过监控大盘查看rejected计数确认队列是否长期打满。调整服务端配置在elasticsearch.yml中按 FAQ 建议设置thread_pool.index.queue_size、thread_pool.write.queue_size与index.max_result_window重启 ES 节点生效注意版本差异index.queue_size仅限 ES 6write.queue_size适用于 ES 6/7。同步调整 OAP 侧配置在application.yml的storage.elasticsearch段调整bulkActions、flushInterval、concurrentRequests与resultWindowMaxSize重启 OAP 生效。验证查询窗口在 Trace 页面执行深翻页或大范围查询确认不再出现max_result_window相关报错必要时将 OAPresultWindowMaxSize与 ES 服务端index.max_result_window设为一致。回归验证数据可见性确认最新 Trace/指标能及时写入并查询到429 消失且写入延迟恢复正常。小结SkyWalking 接入 Elasticsearch 后的“最新数据不可见”与“HTTP 429”两大高频问题本质分别是写入线程池队列打满与查询窗口from size超限。官方 FAQ 给出的三行配置——thread_pool.index.queue_size、thread_pool.write.queue_size、index.max_result_window——是解决这两类问题的第一手药方在此基础上配合 OAP 侧bulkActions/concurrentRequests/flushInterval的写入节奏控制与resultWindowMaxSize的查询窗口对齐即可在 SkyWalking 与 Elasticsearch 之间建立起稳定、可扩展的数据管道。更多细节可进一步阅读 docs/en/setup/backend/storages/elasticsearch.md 与 docs/en/FAQ/ES-Server-FAQ.md。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sky/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考