13.2、场景1 API响应慢
场景 1：API 响应慢
欢迎回到第 13 章的学习。在上一节，我们学习了故障排查方法论。现在我们要通过实际场景学习故障排查方法。
本节将学习场景 1：API 响应慢。这是一个常见的性能问题，我们将学习如何系统化地排查和解决。
发现 Metrics 异常
发现 Metrics 异常的作用是什么？ 通过 Metrics 发现性能异常，确认问题的存在和严重程度。
如何发现 Metrics 异常？ 查看 Grafana Dashboard，关注以下指标：
- API 响应时间（P95、P99）
- 错误率
- 请求量
- 服务器资源使用率
异常指标示例：
- P95 响应时间从 100ms 增加到 500ms
- 错误率从 0.1% 增加到 1%
- CPU 使用率达到 90%
PromQL 查询示例：
# 查询 P95 响应时间 histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, endpoint)) # 查询错误率 sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) # 查询 CPU 使用率 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
查看相关 Traces
查看相关 Traces 的作用是什么？ 使用 Trace 定位问题发生的位置，查看请求链路中的性能瓶颈。
如何查看相关 Traces？ 在 Grafana Tempo 中使用 TraceQL 查询慢请求的 Trace。
TraceQL 查询示例：
# Query response time > 500ms ofthe Trace {duration > 500ms} # Querying a specific endpoint's Trace {http.route="/api/orders"} && {duration > 500ms} # Search for a specific time period Trace {service.name="order-service"} && {duration > 500ms} && {timestamp > now() - 1h}
分析 Span 延迟
分析 Span 延迟的作用是什么？ 分析各个 Span 的执行时间，识别最慢的 Span，定位性能瓶颈。
如何分析 Span 延迟？ 查看 Trace 视图，分析各个 Span 的执行时间分布：
- 前端 Span 执行时间
- API Gateway Span 执行时间
- 后端服务 Span 执行时间
- 数据库 Span 执行时间
常见瓶颈位置：
- 数据库查询慢
- 外部 API 调用慢
- 服务间调用慢
- 业务逻辑处理慢
Span 延迟分析示例：
查看相关 Logs
查看相关 Logs 的作用是什么？ 通过 Logs 分析问题的详细信息，找到问题的根本原因。
如何查看相关 Logs？ 使用 LogQL 查询相关的日志：
LogQL 查询示例：
# 查询错误日志 {level="error"} && {service="order-service"} # 查询慢查询日志 {db_query_duration > 100ms} # 查询异常日志 {exception!=""}
定位数据库慢查询
定位数据库慢查询的作用是什么？ 如果问题出在数据库，需要定位具体的慢查询。
如何定位数据库慢查询？ 查看数据库 Trace，分析慢查询：
- 查询执行时间
- 查询语句
- 查询参数
- 执行计划
数据库慢查询分析：
-- MySQL Slow query log analysis SELECT sql_text, exec_count, avg_timer_wait / 1000000000000 as avg_time_sec, max_timer_wait / 1000000000000 as max_time_sec FROM performance_schema.events_statements_summary_by_digest WHERE avg_timer_wait > 100000000000 -- > 100ms ORDER BY avg_timer_wait DESC LIMIT 10;
优化方案
优化方案的作用是什么？ 根据分析结果，实施优化方案，解决性能问题。
优化方案包括哪些呢？
第一个：数据库优化。 添加索引、优化查询语句、优化表结构。
第二个：缓存优化。 使用缓存减少数据库查询。
第三个：代码优化。 优化业务逻辑，减少不必要的处理。
第四个：资源扩展。 增加服务器资源，提升处理能力。
优化示例：
-- Adding an index ALTER TABLE orders ADD INDEX idx_user_id_status (user_id, status); -- Optimizing query statements -- Before optimization：SELECT * FROM orders WHERE user_id = ? AND status = ? -- After optimization: Use index queries
本节小结
在本节中，我们学习了场景 1：API 响应慢：
第一个是发现 Metrics 异常。 通过 Metrics 发现性能异常，确认问题的存在和严重程度。
第二个是查看相关 Traces。 使用 Trace 定位问题发生的位置，查看请求链路中的性能瓶颈。
第三个是分析 Span 延迟。 分析各个 Span 的执行时间，识别最慢的 Span，定位性能瓶颈。
第四个是查看相关 Logs。 通过 Logs 分析问题的详细信息，找到问题的根本原因。
第五个是定位数据库慢查询。 如果问题出在数据库，需要定位具体的慢查询。
第六个是优化方案。 根据分析结果，实施优化方案，解决性能问题。
故障排查流程： 发现 Metrics 异常 → 查看相关 Traces → 分析 Span 延迟 → 查看相关 Logs → 定位数据库慢查询 → 实施优化方案 → 验证修复效果。
这就是场景 1：API 响应慢。通过场景 1 的学习，我们掌握了 API 响应慢的排查方法。
在下一节，我们将学习场景 2：错误率突然上升。学习如何排查错误率问题。