在Python应用从开发环境走向生产部署之后，代码中的未捕获异常不再只是终端里的一行红色报错，而可能意味着订单丢失、数据错乱或者核心接口不可用。为了让运维和开发人员在故障发生的第一时间感知问题，我们需要一套可靠的异常告警实现方式。不同的业务规模、技术栈和合规要求，决定了告警方案在复杂度和有效性上的巨大分野。
基于进程内捕获的轻量级告警方案
最直观的Python异常告警思路，是在程序运行进程内部直接捕获异常并触发通知。Python标准库提供了sys.excepthook以及logging模块，可以拦截未处理异常和记录错误日志。我们可以在入口文件设置全局异常钩子，当任何线程抛出未被捕获的异常时，钩子函数被调用，此时可组装错误信息并通过邮件或HTTP请求发送出去。
例如使用smtplib发送邮件告警，适合初期没有搭建专门监控系统的团队。下面代码展示如何通过重写sys.excepthook将异常堆栈发送到指定邮箱：
import sys
import traceback
import smtplib
from email.mime.text import MIMEText
def send_mail(subject, body):
msg = MIMEText(body, 'plain', 'utf-8')
msg['Subject'] = subject
msg['From'] = 'alert@ipipp.com'
msg['To'] = 'dev@ipipp.com'
with smtplib.SMTP('smtp.ipipp.com') as server:
server.login('alert@ipipp.com', 'password')
server.send_message(msg)
def handle_exception(exc_type, exc_value, exc_traceback):
if issubclass(exc_type, KeyboardInterrupt):
sys.__excepthook__(exc_type, exc_value, exc_traceback)
return
text = ''.join(traceback.format_exception(exc_type, exc_value, exc_traceback))
send_mail('Python进程异常告警', text)
sys.excepthook = handle_exception
# 测试未捕获异常
raise ValueError('数据库连接失败')
这种进程内方案的优点是实现简单、零外部依赖，但缺点同样明显：如果进程直接崩溃（如段错误）或网络中断，告警本身也可能发不出去。另外频繁异常会造成邮件轰炸，需要自己在钩子里做频率限制。对于Web框架如Flask或Django，更推荐用框架自带的错误处理器结合logging异步队列来发送，避免阻塞请求线程。
另一个进程内常见做法是利用logging.handlers自定义Handler，在error级别以上日志产生时调用外部接口。这样既有日志落盘，又有实时通知，比单纯依赖excepthook覆盖更全面，因为有些异常被业务代码捕获后仅记录日志，同样需要告警。
借助消息队列与Webhook的异步解耦告警
当系统规模扩大，多个Python服务都需要告警能力时，在每一个进程里直连邮件服务器或第三方API就显得笨重且难维护。此时引入消息队列（如RabbitMQ、Redis Stream）或Webhook中转，可以实现告警生产者和消费者的解耦。Python程序只负责把异常事件序列化后推送到队列，独立的告警网关服务负责发送短信、钉钉或企业微信。
以Redis列表作为简易队列为例，业务服务用redis-py将异常信息lpush进去，告警消费者使用brpop阻塞读取并调用Webhook。这种方式即便告警网关短暂不可用，事件也不会丢失，重启后继续处理。下方示例展示生产者部分代码：
import redis
import json
import traceback
r = redis.Redis(host='127.0.0.1', port=6379, db=0)
def report_exception(exc_type, exc_value, exc_traceback):
payload = {
'service': 'order-api',
'stack': ''.join(traceback.format_exception(exc_type, exc_value, exc_traceback)),
'time': '2024-05-01T10:00:00'
}
r.lpush('alert_queue', json.dumps(payload))
# 在异常处调用
try:
1 / 0
except ZeroDivisionError:
report_exception(*sys.exc_info())
Webhook方案则更轻量，许多SaaS监控（如Sentry自建、Grafana）都提供HTTP端点。Python侧用requests.post把异常JSON发出去即可，但必须设置超时和重试，否则外网抖动会拖垮主流程。相较邮件，Webhook能和自然语言处理机器人结合，直接在群聊里@对应负责人，缩短响应链路。
从运维视角看，消息队列方案虽然增加组件，但带来了削峰、重试和统一格式化好处。我们应当在消费者侧做去重和阈值控制，比如同一类型异常五分钟内只通知一次，防止告警风暴。此外队列里的异常可能含用户手机号等PII数据，网关发送前必须脱敏，否则违反数据安全规范。
基于指标与APM平台的体系化异常监控
对于微服务架构，仅靠捕获异常文本远远不够，还需要从指标层面回答“错误率是否超过SLO”。Prometheus加Alertmanager是云原生场景的事实标准：Python服务通过prometheus_client暴露/metrics，用Counter统计异常次数，Alertmanager配置规则当每分钟异常数大于阈值就触发钉钉或邮件。
与之互补的是APM平台（如Sentry、SkyWalking）。Sentry提供官方Python SDK，在应用初始化时sentry_sdk.init之后，未捕获异常自动上报，并聚合相似堆栈、标记发布版本。它比自写邮件更专业，支持指纹分组、告警静默期和用户影响分析。示例初始化代码如下：
import sentry_sdk
sentry_sdk.init(
dsn='https://examplekey@o0.ingest.sentry.io/0',
traces_sample_rate=0.1,
environment='production'
)
# 后续任意未捕获异常都会自动推送
def process_order():
raise RuntimeError('支付网关返回未知状态')
采用APM平台的最大价值在于跨语言聚合和历史追溯。当Python调用Go服务出错时，Sentry能把分布式追踪串联起来。不过这类平台要么使用商业版要么自建消耗资源，小团队应权衡成本。指标方案（Prometheus）则要求开发者主动埋点，无法自动抓取第三方库内部异常，需配合日志导出器如promtail收集logging输出。
综合来看，选型应跟随业务阶段：单体脚本用excepthook加邮件足以；多服务用消息队列解耦；规模化后必须上指标与APM。无论哪种方式，告警内容都应包含服务名、环境、堆栈和发生时间，并配置升级策略——一级告警群通知，十分钟内无人确认则电话呼叫，才能真正实现异常可观测。