你是不是也遇到过这种事儿？周末正嗨皮呢，手机突然跟抽风一样震动，一看，监控系统告警：“服务不可用！”。
然后你火急火燎打开电脑，一顿操作猛如虎，最后发现... 呃，只是数据库连接池满了重启了一下？或者更惨，是隔壁老王部署新服务把你端口给占了？
好，咱们今天不聊那些高大上的、复杂的运维平台，就聊聊咱们用FastAPI写的小破站，怎么给它配一个靠谱的“守夜人”，让它出问题能第一时间通知你，而不是让你从用户的骂声中后知后觉。这篇绝对是实战派，我自己踩过的坑，一个不落全抖出来！
读完这篇文章，你会明白：
1. 为什么你的服务器“死”了，你却是最后一个知道的；
2. 从零到一，给FastAPI项目添加告警的几种“土办法”和“洋办法”；
3. 每种方法的优缺点，以及我这个踩坑专业户的真心推荐。保证你看完就能动手，不用再看那些又臭又长的官方文档。
咱们写代码的，尤其是全栈，容易陷入一种迷之自信：“我代码写得这么稳，怎么可能崩？”
但现实是，服务器崩的原因千奇百怪，跟你代码关系不大。比如：内存爆了、磁盘满了、网络断了、上游API挂了，甚至机房空调坏了（别笑，这事真有）。
你可能会问：“我盯着日志不行吗？” 行，但你得24小时不眨眼地盯着。所以我们需要的，是一个能自动探测、自动判断、自动喊你起床的系统。
说白了，告警的本质就是“问”和“答”。
你的监控系统定期问一下你的服务：“嘿，哥们儿，还活着没？” 你的服务得回答：“活着呢，一切正常。” 如果问了几次都没回应，或者回应说“我快不行了”，监控系统就开始疯狂给你发消息。
方式一：躺平式（日志监控） —— 最原始，但最实用。
- 原理：通过ELK（Elasticsearch, Logstash, Kibana）或类似的日志系统，监控日志里的ERROR级别关键字，一旦出现，就触发告警。
- 优点：全面，不仅能发现服务挂了，还能发现业务异常（比如支付接口频繁报错）。
- 缺点：配置复杂，ELK全家桶部署和维护起来，够你喝一壶的。而且，如果服务直接起不来，连日志都打不出来，它就抓瞎了。
方式二：简单粗暴式（健康检查端点） —— FastAPI的亲儿子。
- 原理：在你的FastAPI应用里，加一个 /health 或 /ping 接口，它只负责返回200状态码和一个简单的JSON，比如 {"status": "ok"}。然后让外部监控系统（比如Uptime Robot，或者云服务商的负载均衡器）每隔一分钟去请求一下这个接口。
- 优点：轻量、简单、极易实现。只需要几行代码。是判断服务“死活”最直接的方式。
- 缺点：只能判断死活，无法判断好坏。比如数据库连不上了，你的/health接口可能还能返回200，因为它没连数据库，但业务已经废了。
方式三：全知全能式（三方APM/监控服务） —— 付费版，省心省力。
- 原理：使用如 Sentry（侧重错误追踪）、New Relic、Datadog 这类商业APM工具，它们会直接集成到你的FastAPI代码里，上报性能指标、错误堆栈、甚至数据库查询耗时，并内置了智能告警规则。
- 优点：省事、智能、信息丰富。不仅能告诉你服务挂了，还能告诉你挂的原因，甚至精确到是哪一行代码导致的。
- 缺点：要钱（但通常有免费额度），并且有一定侵入性，需要在代码里加SDK。
来，咱们先动手做一个最基础的，也是我个人最喜欢的“轻量级”方案：健康检查端点 + 外部监控。这里千万别学我当初偷懒，直接返回一个纯200就完事了，经验告诉我，得加点料。
from fastapi import FastAPI, status
import psutil
import time
app = FastAPI()
@app.get("/health")
async def health_check():
# 1. 检查数据库连接（假设你用了数据库）
try:
# 执行一个最简单的查询，比如 SELECT 1
# db.execute("SELECT 1")
db_status = "ok"
except Exception as e:
db_status = f"error: {str(e)}"
# 2. 检查内存使用率，别等到OOM了才发现
memory_usage = psutil.virtual_memory().percent
if memory_usage > 90:
memory_status = f"critical: {memory_usage}%"
else:
memory_status = f"ok: {memory_usage}%"
# 综合判断
if db_status == "ok" and memory_usage <= 90:
return {"status": "healthy", "db": db_status, "memory": memory_status}
else:
# 返回503，告诉外部监控，我虽然还活着，但没法好好工作
return {"status": "unhealthy", "db": db_status, "memory": memory_status}, status.HTTP_503_SERVICE_UNAVAILABLE看到没？这个 /health 接口就不是简单的“活着”，而是“活得怎么样”。然后你再去 Uptime Robot（一个免费的监控服务，良心推荐）上注册个账号，新建一个监控，填入你的 https://你的域名/health，设置好监控频率和通知方式（比如企业微信、邮件、短信）。完事儿！
再说个容易翻车的点。告警不是越多越好，是 越准越好。你要是设置个CPU超过10%就告警，那你的手机比振动棒还忙，你会很快“习惯性忽视”告警。所以，阈值要设得合理，比如CPU持续5分钟超过80%再告警。
是不是以为这样就完了？不不不，还有一步。如果你用了Docker或者K8s部署，事情就更微妙了。你的 /health 接口可能返回正常，但容器已经重启了三次了。这时候，你就需要 把容器的存活探针和就绪探针 也配置上。这个工具的选择，好比选螺丝刀，不是最贵的就好，而是适合你的场景。如果是单机部署，健康检查+Uptime Robot够用了；如果是微服务，那还是乖乖上APM工具吧。
最后啰嗦一句，告警系统本身也可能出问题。比如你依赖的监控服务挂了怎么办？所以，多几个“守夜人”总没错，比如云服务商自带的监控和Uptime Robot同时用，互相备份。
好了，今天关于FastAPI告警的分享就到这里。希望我踩过的坑能让你少走点弯路。如果你有更好的“守夜”妙招，或者也遇到过什么奇葩的告警经历，欢迎在评论区唠唠。独乐乐不如众乐乐嘛～ 觉得有用的话，别忘了点赞、收藏、关注三连，让更多小伙伴告别半夜被叫醒的噩梦！😴
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。