“用户说下单慢”：从一句废话到根因的定位漏斗——traceId、ELK、链路追踪与排查方法论总纲
客服转来一句“下单好慢”，怎么在半小时内定位到具体机构、具体接口、具体那一行调用？本文用一个完整时间线讲 traceId 贯穿（MDC、网关、Dubbo、MQ、线程池的坑）、Kibana KQL 检索、SkyWalking 看 span 耗时，并总结排查先问的 5 个问题和“定位漏斗”。
微服务与中间件排查
Dubbo、Nacos、Elasticsearch、XXL-JOB 等中间件的线上问题。
配置改了线上不生效，服务下线了流量还在来：Nacos 配置与注册中心的两类“灵异事件”
两类高频“灵异事件”：Nacos 配置改了不生效（dataId/group/namespace 对不上、缺 @RefreshScope、@Value 与 @ConfigurationProperties 的差异、本地缓存），以及服务下线后仍有流量（心跳摘除延迟、消费者缓存、优雅停机顺序）。附 curl 查询配置与实例的排查清单。
一个慢接口引发的雪崩：Dubbo 超时 + 默认重试，把流量放大了 3 倍
下游一个慢接口，叠加 Dubbo 超时与默认 retries=2（最多调 3 次），流量被放大、provider 200 线程被占满并报 Thread pool is EXHAUSTED，故障从一个服务扩散到整条链路。附排查命令、超时分层、集群容错与限流降级的修法。
XXL-JOB 的三种“灵异现象”：重复执行、莫名不触发、执行器离线——一次讲透调度链路
同一个定时任务有时跑两遍、有时一遍都没跑、有时执行器在后台显示离线。沿着调度中心到执行器的链路，查注册地址、accessToken、路由与阻塞策略、misfire、执行超时，最后用幂等设计兜底。
ES 写入全线 403：磁盘刚到 95%，整个集群就“只读”了——水位线三兄弟与 read_only_allow_delete
日志写入突然全部失败，报 index read-only / allow delete (api)，集群还变了 yellow。顺着 _cluster/health、_cat/allocation、allocation/explain 一路查到磁盘水位线，讲清 85/90/95 三道线、解除只读的正确姿势，以及分片过多这个隐形推手。