一、从服务器报警到迷茫的排查之路
1.1 之前的排查痛点
很多开发者遇到线上报警，第一反应是翻日志、查监控，找时间点对应问题，但日志散在不同服务器上，监控的数字跳变也没明确的时间关联，经常要花一两个小时找问题，特别是晚上被叫醒时脑子不清醒，更觉得着急。
1.2 实际遇到的场景
上个月我做的电商小项目，运营早上发消息说商品详情页打不开，前端返回502 Bad Gateway，我刚到公司就收到PagerDuty的报警邮件，说api-server-01服务不可用。换做以前我会先看服务监控的CPU、内存，再查数据库连接状态，发现数据库连接池满了，但不知道为什么突然满了，前后折腾了快20分钟才找到：是运维前一天手动修改了数据库的最大连接数，忘了通知开发。
二、什么是PagerDuty事件时间线
2.1 生活化理解
简单说，PagerDuty是帮大家处理线上告警的工具，它的事件时间线就像你点外卖时看到的“订单轨迹”，从商家接单、厨师做饭、骑手取餐、在路上，所有和订单相关的事件按时间排好，不用你一个个问商家或骑手。
2.2 核心作用
它把和这次故障相关的所有事件（比如服务启动、请求失败、配置修改、告警发送）都收集起来，按时间顺序整理成一条线，顺着这条线走，就能快速找到问题出在哪个时间点对应的操作或状态上。
三、用PagerDuty事件时间线排查问题的详细示例
3.1 示例背景
我们用一个简单的后端服务举例，模拟出现502错误的场景，看PagerDuty时间线怎么帮我们快速定位。
3.2 技术栈选择
本次示例使用单一技术栈：Node.js + Express + PagerDuty Events API，所有代码围绕这个栈展开，不混合其他技术。
3.3 代码实现
// 技术栈：Node.js + Express + PagerDuty Events API
const express = require('express');
const pagerduty = require('@pagerduty/pagerduty');
const app = express();
const PORT = 3000;
// 初始化PagerDuty客户端，这里填写PagerDuty后台生成的Integration Key（示例用占位符）
const pdClient = new pagerduty.EventsV2Client('your_pagerduty_integration_key_12345');
// 模拟数据库连接函数，故意设置为连接失败状态
function connectToDatabase() {
return new Promise((resolve, reject) => {
// 延迟1秒后返回连接失败，模拟数据库端口错误或服务未启动的情况
setTimeout(() => {
reject(new Error('数据库连接失败：目标地址拒绝连接，请检查端口和服务状态'));
}, 1000);
});
}
// 商品详情页接口，依赖数据库获取商品数据
app.get('/product/:id', async (req, res) => {
try {
// 尝试连接数据库
await connectToDatabase();
// 模拟获取商品数据
const product = { id: req.params.id, name: '示例商品', price: 99 };
res.status(200).json(product);
} catch (err) {
// 当连接失败时，触发PagerDuty告警
await pdClient.trigger({
routing_key: 'your_pagerduty_integration_key_12345',
event_action: 'trigger',
payload: {
summary: '商品详情页502错误，服务不可用',
source: 'api-server-01',
severity: 'critical'
}
});
// 返回502状态码给前端
res.status(502).send('服务暂时不可用，请稍后再试');
}
});
// 启动服务
app.listen(PORT, () => {
console.log(`后端服务已启动，监听端口：${PORT}`);
});
3.4 时间线排查过程
当启动服务并请求商品详情页时，触发502错误，PagerDuty收到告警，打开告警的事件时间线，会看到按时间排序的事件：
- 2024-05-25 09:30:00 后端服务api-server-01启动成功（来自Prometheus监控系统事件）
- 2024-05-25 09:35:12 用户请求商品详情页id=1001，返回502（来自API Gateway请求日志）
- 2024-05-25 09:35:13 后端服务尝试连接数据库失败，抛出错误（来自Node服务日志）
- 2024-05-25 09:35:14 PagerDuty收到告警并自动分配给开发者小李（来自PagerDuty系统事件）
- 2024-05-25 09:35:15 运维小张修改了数据库的最大连接数配置（来自运维操作审计日志，之前未加入PagerDuty，后来手动添加） 顺着时间线看，9:35分小李收到告警，同时运维修改了数据库配置，正好对应数据库连接失败的事件，立刻定位到是运维操作导致的问题。
四、应用场景、技术优缺点、注意事项
4.1 应用场景
4.1.1 分布式系统故障排查
现在很多公司把服务拆成用户服务、商品服务、订单服务等独立模块，当某个模块出问题时，时间线能看到每个服务的调用顺序，比如用户服务调用商品服务失败，就能快速找到商品服务的问题，不用逐个服务排查。
4.1.2 多团队协作排查
线上故障发生时，前端、后端、运维都要参与，每个人负责不同部分，时间线是统一的，大家能看到同一时间点的事件，不会出现前端说“10点报错”、后端说“10点半才告警”的矛盾，节省沟通时间。
4.1.3 定期任务告警排查
比如定时同步用户数据到其他系统，任务失败时，时间线能显示任务的开始时间、失败时间，以及失败前的配置修改，之前遇到过定时任务密钥过期，时间线里能看到密钥修改时间和任务失败时间对应，快速解决问题。
4.2 技术优缺点
4.2.1 优点
- 节省排查时间：不用翻几十个日志文件，不用自己整理监控时间点，时间线自动整合所有相关事件，能减少一半以上的排查时间。
- 避免遗漏环节：把所有和故障相关的事件（包括后台手动操作、监控异常）都整合，不会漏掉关键原因，比如之前的例子，若没把运维修改配置的事件加入，就找不到根本原因。
- 自定义灵活：可以自己添加事件，比如手动操作、第三方API调用、用户反馈事件，让时间线更全面，适合不同排查场景。
4.2.2 缺点
- 初始配置有成本：要把监控系统、日志系统、运维工具和PagerDuty集成，一开始要花时间设置规则，比如Prometheus告警和PagerDuty的对接，需要配置API Key和告警内容。
- 事件多会干扰：若时间线加了太多无关事件（比如所有用户登录事件），排查故障时会被无关信息干扰，需要学会筛选过滤事件。
- 依赖时间同步：所有服务器时间必须和标准时间一致，差几秒都会打乱时间线顺序，比如服务19:05失败，服务器时间差1分钟，时间线会跑到后面，找不到对应关系。
4.3 注意事项
4.3.1 接入所有相关事件
不要只把告警事件加入时间线，要把系统启动、配置修改、数据库状态、第三方服务调用都接入，比如运维改配置的操作，一定要手动加入时间线，不然根本原因可能被漏掉。
4.3.2 确保时间同步
所有服务器要用NTP时间同步，让时间和标准时间的差在1秒以内，每个月检查一次服务器时间，避免时间线顺序混乱。
4.3.3 控制权限
PagerDuty的时间线里有线上环境的故障信息，不要让无关人员查看，设置不同权限，比如开发只能看自己负责的服务时间线，运维可以看所有的。
4.3.4 聚焦故障相关事件
时间线是排查工具，不是记录所有事件的日志，加太多无关事件会减慢排查速度，只加和这次故障相关的，比如502错误，只加服务请求、数据库、告警的事件，不用加登录、注册这些不相关的。
五、总结
PagerDuty事件时间线是可观测性与运维里的实用工具，它把分散的事件按时间整理，让开发者不用在大量信息里找问题，特别是小团队人手少，故障发生时时间线能帮大家快速定位，减少线上故障处理时间，提升服务稳定性。掌握这个工具的使用，能让开发者遇到线上问题时更从容，不用像以前一样熬夜找半天原因。
评论
围绕“可观测性与运维里，PagerDuty事件时间线助力问题排查”参与讨论