旋大爷的博客

Prompt工程07：排障上下文

从日志、指标、Trace到复现步骤和影响面，理解如何为模型提供有效的排障上下文。

字数 1058 阅读时长 ≈ 4 分钟 2026-7-25 2026-7-27
#AI #Prompt工程
Prompt工程07：排障上下文

排障上下文是让模型帮助定位和解决问题的关键。好的排障上下文能让模型快速理解问题现象、定位问题原因，输出有效的解决方案。

排障上下文的重要性

缺少排障上下文的问题

当模型没有足够的排障上下文时：

用户输入：

系统出问题了，帮我看看。

问题：

  • 模型不知道是什么系统
  • 不知道问题现象是什么
  • 不知道什么时候开始的
  • 不知道影响范围

有排障上下文的效果

用户输入：

[系统信息]
系统：电商平台
模块：订单服务
环境：生产环境

[问题现象]
订单创建接口响应慢，P99超过2秒
开始时间：2024-01-15 10:00:00
影响范围：所有用户

[日志信息]
ERROR 2024-01-15 10:00:05 OrderService.createOrder - 数据库连接超时
WARN 2024-01-15 10:00:06 OrderService.createOrder - Redis连接池满

[监控指标]
- CPU使用率：40%
- 内存使用率：60%
- 数据库连接数：200/200（已满）
- Redis连接数：100/100（已满）

[相关配置]
数据库连接池大小：200
Redis连接池大小：100

效果：模型可以快速定位问题（数据库和Redis连接池耗尽），输出解决方案（增加连接池大小、优化查询）。

排障上下文的组成

核心要素

要素内容作用
系统信息系统名称、模块、环境定位问题发生的系统
问题现象错误描述、表现形式理解问题是什么
时间信息开始时间、持续时间、频率了解问题发生的时间规律
影响范围受影响用户、功能、地域判断问题严重程度
日志信息错误日志、警告日志、堆栈定位问题原因
指标信息CPU、内存、网络、数据库了解系统状态
Trace信息请求链路、调用耗时定位瓶颈位置
配置信息相关配置项、参数检查配置是否正确
复现步骤如何复现问题验证解决方案

排障上下文层次

层次1：问题定位
├── 系统信息（哪个系统、哪个模块）
├── 问题现象（什么问题、什么表现）
└── 时间信息（何时开始、持续多久）

层次2：影响评估
├── 影响范围（多少用户、哪些功能）
├── 严重程度（P0-P3）
└── 业务影响（收入、用户体验）

层次3：根因分析
├── 日志信息（错误、警告、堆栈）
├── 指标信息（CPU、内存、网络）
├── Trace信息（链路、耗时）
└── 配置信息（参数、开关）

如何提供排障上下文

系统信息

[系统信息]
系统名称：电商平台
模块名称：订单服务
服务名称：order-service
实例数量：5台
环境：生产环境（prod）
地域：北京、上海

问题现象

[问题现象]
问题描述：用户创建订单时提示"系统繁忙，请稍后重试"
错误码：ORDER_CREATE_FAILED
错误信息："数据库连接超时"
复现步骤：
1. 登录系统
2. 选择商品加入购物车
3. 点击结算
4. 提交订单
5. 出现错误提示

频率：持续出现，约50%的请求失败

时间信息

[时间信息]
开始时间：2024-01-15 10:00:00
持续时间：至今（已持续2小时）
发生频率：持续出现
上次正常时间：2024-01-15 09:59:59

影响范围

[影响范围]
受影响用户：全部用户（约10万活跃用户）
受影响功能：订单创建、订单查询
受影响地域：全部地域
业务影响：无法下单，预计每小时损失10万元
严重程度：P0（紧急）

日志信息

[日志信息]

ERROR 2024-01-15 10:00:05.123 [http-nio-8080-exec-1] OrderService.createOrder - 数据库连接超时
java.sql.SQLTimeoutException: Connection timed out
    at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:129)
    at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
    at OrderService.createOrder(OrderService.java:123)

WARN 2024-01-15 10:00:06.456 [http-nio-8080-exec-2] RedisConfig - Redis连接池已满，等待连接

指标信息

[指标信息]

资源使用：
- CPU使用率：40%（正常）
- 内存使用率：60%（正常）
- 磁盘使用率：30%（正常）

数据库：
- 连接数：200/200（已满）
- 查询耗时：平均500ms（正常100ms）
- 慢查询数：100个/分钟（正常<10）

Redis：
- 连接数：100/100（已满）
- 响应时间：平均50ms（正常<10ms）

应用：
- 请求量：1000QPS（平时500QPS）
- 错误率：50%（正常<1%）
- 响应时间P99：2000ms（正常<200ms）

Trace信息

[Trace信息]

Trace ID: abc123456789
请求路径：POST /api/orders

调用链：
1. Gateway (10ms)
2. OrderController (5ms)
3. OrderService.createOrder (1900ms)
   ├── UserService.getUser (50ms)
   ├── ProductService.checkStock (300ms)
   ├── OrderRepository.save (1500ms) ← 瓶颈
   └── RedisCache.set (50ms)
4. 总耗时：1980ms

配置信息

[配置信息]

数据库配置：
spring.datasource.hikari.maximum-pool-size=200
spring.datasource.hikari.connection-timeout=3000
spring.datasource.hikari.idle-timeout=60000

Redis配置：
spring.redis.jedis.pool.max-active=100
spring.redis.jedis.pool.max-wait=3000

应用配置：
server.tomcat.max-threads=200

排障上下文的格式

结构化排障上下文

[系统信息]
系统：电商平台
模块：订单服务
环境：生产环境

[问题现象]
描述：订单创建接口50%请求失败，提示"系统繁忙"
错误码：ORDER_CREATE_FAILED

[时间信息]
开始：2024-01-15 10:00:00
持续：2小时

[影响范围]
用户：全部10万活跃用户
业务：无法下单，每小时损失10万
严重程度：P0

[日志]
ERROR: 数据库连接超时
WARN: Redis连接池已满

[指标]
DB连接：200/200（满）
Redis连接：100/100（满）
QPS：1000（平时500）

[Trace]
OrderRepository.save 耗时1500ms（瓶颈）

[配置]
Hikari连接池：200
Jedis连接池：100

排障上下文组织原则

原则说明示例
先现象后原因先描述问题，再给分析数据先给问题现象，再给日志指标
关键信息优先最重要的信息放在前面错误日志放在最前面
时间顺序按时间顺序组织信息按问题发生时间排列
标注重点对关键部分进行标注使用箭头或加粗标注瓶颈

排障上下文的常见问题

问题1：信息不全

表现：缺少关键信息，模型无法定位问题

解决方案：

  • 检查是否遗漏了日志、指标、Trace
  • 补充系统信息和环境信息
  • 提供复现步骤

问题2：信息冗余

表现：提供了大量无关信息，占用 Token

解决方案：

  • 只提供相关的日志和指标
  • 使用摘要代替完整信息
  • 过滤掉正常的日志

问题3：信息混乱

表现：信息没有组织，杂乱无章

解决方案：

  • 使用结构化格式
  • 按类别组织信息
  • 使用标题分隔

问题4：信息过时

表现：提供的信息是过去的，不是当前状态

解决方案：

  • 使用实时监控数据
  • 提供最新的日志
  • 注明信息时间

排障上下文的工具支持

监控工具

工具功能适用场景
Prometheus指标采集和存储系统监控
Grafana指标可视化监控面板
ELK日志收集和分析日志查询
Jaeger分布式链路追踪链路分析

排障工具

工具功能适用场景
curl测试 HTTP 接口API 测试
ping/telnet网络连通性测试网络问题
jstackJava 线程分析线程问题
jmapJava 内存分析内存问题

排障上下文的最佳实践

生产环境排障

[紧急排障]
系统：支付网关
问题：支付接口超时，P99>5s
严重程度：P0

[实时信息]
时间：当前
指标：CPU 90%, DB连接满, Redis连接满
日志：连接超时错误
Trace：DB查询耗时4s

[立即行动]
1. 扩容连接池（临时）
2. 暂停非核心功能（限流）
3. 排查慢查询（根因）

开发环境排障

[开发排障]
系统：用户服务
问题：单元测试失败
环境：开发环境

[详细信息]
测试方法：UserServiceTest.testCreateUser
错误信息：NullPointerException
堆栈：UserService.createUser:45

[代码上下文]
UserService.java 第45行
当前代码片段

[复现步骤]
1. 运行 mvn test
2. 查看失败测试

性能问题排查

[性能排障]
系统：搜索服务
问题：搜索接口响应慢，P99>3s

[性能分析]
指标：CPU 80%, 内存 70%
Trace：ES查询耗时2.5s
慢查询：复杂聚合查询

[优化方向]
1. 添加索引
2. 简化查询
3. 添加缓存

项目判断清单

  • 模型无法定位问题 → 补充系统信息和问题现象
  • 模型找不到根因 → 提供日志、指标和 Trace
  • 需要快速止血 → 先提供当前状态和紧急措施
  • 需要长期排查 → 提供完整的上下文和历史数据
  • Token 预算有限 → 使用摘要，重点突出
  • 问题间歇性出现 → 提供时间规律和触发条件
  • 问题影响范围大 → 先评估影响再分析原因
  • 需要多人协作 → 结构化上下文，便于分享