企业官网建设流程全解析

生产问题排查与性能瓶颈定位：日志、监控、链路追踪、压测与 Arthas

生产问题最怕的不是报错，而是没人知道从哪下手。

一个接口突然变慢，用户说提交订单失败，监控开始报警，日志里一堆异常，CPU 又有点高。这个时候如果只是凭感觉去猜，很容易越查越乱。

生产排障要有顺序：先确认影响范围，再拿日志、监控、链路追踪定位层级，然后用压测或复现缩小问题，必要时用 Arthas 进入 JVM 内部观察，最后修复、验证、复盘。

一、先把问题说清楚

遇到生产问题，第一步不是打开代码，而是把问题描述清楚。至少要回答这几个问题：

可以用这个流程先收口：

不要一上来就问"是不是数据库慢"。数据库当然可能慢，但也可能是线程池打满、缓存击穿、远程服务超时、锁竞争、GC 停顿、发布引入了死循环。

排障最重要的是用证据缩小范围。

二、一条通用排障主线

生产问题可以按"现象、范围、层级、原因、修复、验证"来推进。

这个顺序很笨，但很稳。它避免了一个常见问题：还没确认影响范围，就开始改代码；还没确认瓶颈层级，就开始加机器。

三、日志看什么

日志适合回答"发生了什么"。

排查生产问题时，先用时间范围和 traceId 收敛日志。

常见查询条件

日志里重点看几类信息

一个好的排障日志应该能回答

• 请求有没有进来。
• 请求在哪一步失败。
• 失败前后关键业务状态是什么。
• 下游调用是否成功，耗时多少。
• 异常是否集中在某个服务、某台机器、某类用户。

如果日志只能看到"操作失败"，看不到业务主键和调用耗时，那不是排障能力差，而是日志本身没设计好。

四、监控看什么

监控适合回答"系统状态是否异常"。

排查时不要只看 CPU。CPU 高只是现象，不一定是根因。

常见指标与可能问题

监控的核心

监控的核心不是看一个点，而是看趋势和关联。

例如接口变慢时，应该同时看：

• 如果 QPS 没变，CPU 没变，但数据库慢查询突然增加，很可能瓶颈在数据库。
• 如果 QPS 暴涨，线程池队列堆积，下游超时增多，问题可能是流量超过了服务承载能力。
• 如果响应时间呈周期性尖刺，同时 Full GC 频繁，就要重点看 JVM 内存。

五、链路追踪看什么

链路追踪适合回答"慢在哪里"。

一次请求经过多个服务时，单看日志很容易碎。链路追踪能把调用关系画出来，并显示每一段耗时。

看到这条链路，就不用猜了——主要耗时在优惠券服务。

链路追踪通常关注

常见工具有 SkyWalking、Zipkin、Jaeger、OpenTelemetry 体系。工具名字不重要，重要的是系统要能把日志、指标、调用链用同一个 traceId 关联起来。

有了这种关联，排查体验会完全不同。

六、压测用来验证瓶颈

压测不是为了跑一个漂亮数字，而是为了知道系统在哪个压力点开始撑不住。

注意：压测通常在上线前或压测环境做，用来验证容量和找潜在瓶颈；生产排障是在问题已经发生时，用日志、监控、链路追踪、线程栈、Arthas 等手段收集证据。不要为了定位线上问题，直接在生产环境随意压测，那很容易把故障扩大。

常见指标

响应时间和延迟不是完全一回事。在 JMeter 里，elapsed time 更接近一次请求从发送前到完整响应接收后的耗时；latency 更接近从发送前到收到响应第一部分的时间。实际分析时，响应时间更适合看用户整体等待，延迟更适合看服务开始响应的速度。

压测流程

压测时不要只看 JMeter 报告。客户端报告告诉你"请求表现如何"，服务端监控告诉你"为什么会这样"。

常见压测现象与瓶颈

压测结论要落到可执行动作上：扩容、调线程池、改 SQL、加缓存、拆热点、限流、降级、异步化，或者修代码。

七、Arthas 适合查什么

Arthas 是 Java 线上诊断工具，适合在不重启应用的情况下观察 JVM 内部状态。

常用场景

常用命令

dashboard

查看 JVM、线程、内存、GC 等实时概览。

thread

查看 Java 线程信息。CPU 高时经常用它找热点线程。

thread-n5

查看最忙的几个线程。

jad

jad com.example.OrderService

反编译 JVM 里实际加载的类，确认线上运行的代码是不是你以为的版本。

trace

trace com.example.OrderService createOrder

跟踪方法内部调用耗时，适合定位慢在哪个子调用。

watch

watchcom.example.OrderService createOrder"{params, returnObj, throwExp}"-x3

观察方法入参、返回值和异常。

使用注意事项

Arthas 很强，但不能乱用。trace、watch这类命令会对目标类做字节码增强，生产环境使用时要精确指定类和方法，避免范围过大。用完要及时reset或stop。

八、远程调试要谨慎

远程 debug 很好用，但它不适合随便用在生产环境。原因很简单：断点可能让线程挂起，业务请求会被卡住；如果断在锁、事务、连接池相关位置，影响会被放大。更麻烦的是，生产数据是真实用户数据，调试过程还有权限和安全风险。

合理边界

生产环境更推荐用日志、监控、链路追踪、Arthas、线程栈、堆转储、慢查询等方式拿证据。

如果极端情况下必须在生产环境打开诊断能力，也要满足几个条件：审批明确、范围极小、时间极短、有人值守、随时可回滚。能不用断点，就不用断点。

九、常见问题怎么定位

接口突然变慢

• 如果慢点在数据库，就查慢 SQL、索引、锁等待、连接池。
• 如果慢点在下游接口，就查下游错误率、超时配置、重试策略。
• 如果慢点在本服务，就查线程池、锁、CPU、GC、热点方法。

CPU 飙高

可以用 Arthas 的thread -n 5看热点线程，也可以用系统命令配合线程栈。关键是找到具体线程正在执行的代码，而不是只说"CPU 高"。

内存持续上涨

内存问题要区分：

数据库慢

很多线上数据库问题不是 SQL 写错这么简单，而是流量上来后索引选择变差、事务持有时间过长、热点行竞争、连接池配置过小，或者应用重试把数据库打得更狠。

消息堆积

消息堆积时不要只扩消费者。要先确认消费者是不是因为下游慢、数据库慢、代码异常导致消费失败。如果根因不解决，扩容只会把压力更快打到下游。

十、项目难点怎么表达

很多技术面试会问"项目中遇到过什么难点"。这个问题不能回答成"我用了 Redis、MQ、ELK、Arthas"，工具名不是难点。

一个好的表达结构

可以按这个模板讲：

当时订单服务在活动期间出现响应时间升高，主要表现是下单接口 P95 从 200ms 涨到 1.5s，错误率也有抬升。

我先通过监控确认不是全站故障，而是订单链路变慢；再用 traceId 查日志和链路追踪，发现耗时主要集中在库存扣减和优惠券锁定；随后结合数据库慢查询和连接池监控，确认优惠券服务存在慢 SQL，并且失败重试放大了数据库压力。

处理上，我们先临时降级非核心优惠券规则，降低活动期间的下游压力；随后优化 SQL 和索引，调整连接池与超时重试策略，并补充了慢调用告警。

最终下单接口 P95 恢复到 300ms 以内，错误率回落，后续活动期间没有再出现同类故障。

这段话有几个关键点：

1. 有业务背景。
2. 有明确指标。
3. 有排查路径。
4. 有根因。
5. 有解决动作。
6. 有结果验证。

这才像真实做过项目的人讲出来的。

十一、一套生产排障清单

具体动作可以按优先级来：

总结

生产排障的关键，不是会背多少工具，而是能不能沿着证据链把问题一步步压缩。

• 从"用户说慢"压缩到"某个接口慢"。
• 从"某个接口慢"压缩到"某个服务慢"。
• 从"某个服务慢"压缩到"某个方法、某条 SQL、某个下游调用慢"。
• 再从这个点拿出修复方案和验证结果。

这就是排障能力。