没有托管的 APM，生产环境没有链路追踪，也没有需要记着去打开的仪表板。唯一额外花钱的是日志归档，每月大约 2 美元。下面是完整清单，以及我弃用或不再信任的东西，其中一样让我追了好几天一个根本没有用户碰到过的故障。

我说的监控是什么，以及规模有多小

#

我说的 DevOps 监控指两件事：在别人告诉我之前就发现东西坏了，以及不靠猜就能查出原因。下面每个工具都按这两条来评价。

去年我写过一篇搭建开发者真正会用的监控，那时主要考虑的是团队：小团队用云厂商自带的监控，服务上百个了再上托管的 APM。这篇是同一个思路里最小的那一端。两个产品都是 Django，跑在 Fly 的 shared-cpu-1x 机器上，我当前的技术栈里写过，而且两边的开发者都只有我一个。如果说监控是一个产品、开发者是它的用户，那我这套监控的用户就只有一个人。九月我从 Fly 的指标里拉了一次基线，交易平台的 API 平均 CPU 占用是 1%。这不是企业级的技术栈，我也不打算把它包装成那样。

指标、日志、链路这三根支柱，我有两根。两个产品都没有分布式追踪：各自就是一套 Django 代码加一个数据库，没有服务边界让链路去跨。我平时看的链路只有一种，就是我工作站上反向代理的链路。

清单

#

表里没写“两个应用”的，都只说交易平台。估价应用的东西更少：Fly 的健康检查、日志和指标，iOS 上的应用分析，再加一个每天把数据库导出成 Parquet、我用 DuckDB 查询的任务。它没有崩溃报告，也没有告警频道，这是这篇里最大的缺口。（关于更新服务那一行要说明一下：做这个服务的公司付钱请我给他们的博客写文章。）

错误：把日志发到聊天频道的 logging handler

#

九月之前，未处理的 500、发送失败的推送通知、坏掉的 WebSocket 帧，唯一会出现的地方是 flyctl logs，而那条流没人会主动去读。现在由一个日志 handler 把 ERROR 及以上的每条记录都发到聊天频道，不管来自 API、WebSocket 服务器还是后台 worker。WARNING 故意不告警。

handler 在后台线程里发送，所以绝不会拖慢请求。它内部不写任何日志，所以不会递归。同一个错误最多每十分钟发一次，每小时上限 30 条，所以出故障时你读到的是一条消息，而不是一千条。

这个频道里还有我想拿来和错误对照着看的东西：部署在开始、上线成功和失败的地方都会发消息，带上 commit 和执行人，OTA 更新和 Web 发布也一样。某个账号短时间内集中输错登录验证码，也会记成 ERROR，所以有人在乱猜的话，会和故障出现在同一个地方。

十月来过一条告警，任何日志里都找不到对应的行。从那以后，每条告警都带上一个短的随机 id、主机名和进程的启动命令，同一行也写进那个进程自己的日志。找不到 id，就说明它来自一个不往那里写日志的进程，比如一个 SSH shell。频道里的所有消息也会进一条信息流，和我一起干活的编程 agent 可以读，所以在改代码的 agent 和我同时看到这些错误。

日志：用 Fly 的 log shipper 存到 S3，用 DuckDB 查询

#

Fly 自己的缓冲只有几分钟的输出，大概最后一百行，盯部署够用，查昨天的事就没用了。所以第三个 Fly 应用跑着 Fly 的日志转发器，就是订阅了组织日志流的 Vector，我只改了它的 S3 sink：

[sinks.aws_s3]
  type = "aws_s3"
  bucket = "myapp-logs"
  compression = "gzip"
  key_prefix = "logs/{{fly.app.name}}/%F/"   # one folder per app per day
  batch.timeout_secs = 300                  # a quiet app still lands its lines

交易平台各个应用的每一行日志，都以 gzip 压缩的 JSON 落进一个兼容 S3 的 bucket。转发器是一台 256 MB 的 shared-cpu-1x 机器，每月大约 2 美元，存储费可以忽略。DuckDB 用一个宏直接就地读取这些文件，一天的数据一秒左右就出来：

CREATE MACRO logs(app, day := '*') AS TABLE
  SELECT * FROM read_json_auto('s3://myapp-logs/logs/' || app || '/' || day || '/*.log.gz',
                               union_by_name := true);

SELECT timestamp, message FROM logs('myapp-api', '2026-09-06') WHERE message LIKE '% 500 %';

我在缩容到零那篇里测冷启动，用的就是这个宏：启动脚本每个阶段都会打一行，每行都带着机器 id，剩下的就是一个 GROUP BY。

所以同一条日志流按读者分成三层：归档保留 INFO 及以上（这也是生产环境的应用用 INFO 级别打日志的原因），实时查看脚本只显示警告和错误，聊天频道收 ERROR。不过三者都不知道是谁发的请求。访问日志里没有客户端 IP，也没有 user agent，这个得去 Cloudflare 查。

指标：Fly 自带的 Prometheus

#

Fly 给每个组织跑一个托管的 Prometheus，所以我自己不维护任何指标系统。有问题时直接查它的 API：每台机器的内存、CPU 和突发额度（共享 CPU 上 fly_instance_cpu_balance 很要紧），每个应用的响应数和并发数。有两件事我希望早点知道。用 fly tokens create 创建的 token 要以 Authorization: FlyV1 <token> 传入；Bearer 只对 flyctl auth token 给出的个人 token 有效，而只读 token 会返回 “something went wrong resolving organization”。另外数据大约只保留两周（Fly 的说法是 15 天左右）。

它在九月真正派上了用场。那时日志里一天好几次出现 “Could not open a database connection”，看上去完全就是应用的 bug。托管 Postgres 集群也在同一个 Prometheus 里，每次出现这个错误的那一分钟，主库的抓取耗时都从 80 毫秒左右跳到一到十秒，副本一切正常，Postgres 的启动时间也没变。Postgres 没重启过，是它底下的宿主机卡住了。我把时间戳发给了 Fly 的支持团队；十月初一次维护重启把主库挪到另一台宿主机之后，每天的卡顿就没了。

崩溃报告：指向我自己 API 的 Sentry SDK

#

以前应用在手机上崩了，我能看到的地方一点痕迹都没有。最直接的答案是 Sentry，我只用了它的一半：应用里装的是 Sentry 的开源 SDK，但 DSN 指向我自己 Django API 里的一个接口，这个接口接收 Sentry 的 envelope 格式，把崩溃归类，再通过同一个聊天 handler 告警。链路追踪、会话和回放都关掉了，只收错误。

没注册 sentry.io，是因为一天就几条报告，为此多一家掌握用户数据的厂商、隐私政策里多一行、再多一张账单，不值得。代价是符号化（symbolication），这块我还没补上。堆栈要么是压缩过的 JavaScript，要么是原始的 native 地址，所以一个 issue 能告诉我崩的是什么、哪个版本、哪台设备、用户崩之前做了什么，但说不出是源码的哪一行。

唯一的仪表板是一条消息

#

两个应用我都没做仪表板。去年那篇里写过一个检验标准：没人主动打开的仪表板，就是没证明自己的价值。自己送上门的消息不用打开，所以我最接近仪表板的东西，是每天早上发到团队聊天里的一条汇总。

开头是过去 24 小时的生产错误，从日志归档里读，而不是从聊天频道里读，因为告警限了频率，说不出一件事到底发生了多少次。数字、id 和地址先打码再归类，所以同一个失败出现一百次也只是一行加个计数，邮箱地址也不会流进频道。

接着是失败的健康检查、昨天的使用量和上周同一天的对比（周日永远不会像周一），最近一周的搜索流量、等着回复的聊天、任务看板，还有开销。哪一部分加载不出来就照实写，汇总照样发出去。

通过 API 读应用分析数据，会让你对这些数字多一点怀疑。八月份，阿塞拜疆来了 121 次 Android 首次打开，随后是 119 次卸载。那个月的 Android 总数，我是扣掉这些来看的。

发布有自己的界面。以前 OTA 更新从我自己的服务器发的时候，我看一次发布的方式就是后台里一个带 “is active” 复选框的列表，根本不知道有多少台手机真的装上了。现在这个服务的仪表板能看到设备实际在跑哪个版本、安装情况如何，坏掉的 bundle 崩溃、SDK 退回上一个版本时还会显示这次崩溃回滚。迁移到托管更新服务的经过我另外写过。

弃用的，或者不再相信的

#

这里面没有一样是付费工具。大多是我一直当成信号、其实不是信号的东西，还有一个放错了地方的任务。

按 user agent 分组之前的 Cloudflare 504 比例

#

九月，Cloudflare 面板上显示一天里有 22% 的请求以 504 失败，集中在应用每 30 秒轮询一次的那几个接口上，而健康检查全是绿的，应用自己的日志也说这些请求很快。我在上面花了好几天，发现机器冷启动要 25 到 33 秒、一天要冷启动 92 次，修好了，然后在缩容到零那篇里把它写成了原因。

第二天早上，我把同样的 504 按 user agent 分组。9 月 5 日到 9 日之间的 7,344 个 504，全部来自 Cloudflare 自家的 Early Hints 缓存查询（user agent 是 bastion early hints 和 nginx-ssl early hints），它们根本不会到达源站：这些行里的 504 记录的是一次缓存未命中，而不是超时。它们照搬真实请求的路径，所以都落在最忙的接口上，看起来和用户请求失败一模一样。应用、浏览器、curl 和搜索引擎爬虫一个 504 都没有。源站当时不发 Link 头，Early Hints 什么作用都没起，于是我先把它关了，后来才让它真正生效。

冷启动的优化并没有白做，部署和唤醒都因此变快了，但我以为自己在修的那个故障，从来没有落到任何用户身上。

所以我最想分享的一条规则是：相信 CDN 的错误率之前，先按 user agent 分组，确认那不是 CDN 自己的机制产生的。在 Cloudflare 的免费套餐上，就是对 httpRequestsAdaptiveGroups 发 GraphQL 查询，一次查一天。下一次虚惊也是靠同一个查询解决的：有个轮询接口从每天 70 到 260 次请求涨到了 2,880 次。不是爬虫，是我自己的 Mac，测试完把应用开在 iOS 模拟器里忘了关。

一路绿灯的健康检查

#

Fly 每 30 秒检查一次两个应用的 /api/health/，用结果决定哪些机器接流量，这件事它做得很好。但健康检查跑在已经起来的机器上，看不到机器起来之前发生的事：冷启动、代理前面的排队、根本没到达的请求。现在我只指望它做路由。

部署时改用探测脚本，它在整个部署过程中持续打源站，只要有一次失败就以退出码 1 结束。它抓到过一次普通的 flyctl deploy 留下了 7.3 秒的空档；换成先唤醒一台备用机器的部署脚本之后，2,514 个请求里一个失败都没有。

健康检查自己还造成过两次故障。七月，Django 的 SECURE_SSL_REDIRECT 给 Fly 的明文 HTTP 探测回了 301，所有机器检查失败，所有人都收到了 503。八月，我把健康检查视图里的 except Exception 收窄了，结果 “connection already closed” 错误以 500 漏了出去，Fly 把机器摘掉了，而视图里的重试恰恰就是为这种情况准备的。现在这个检查只问一件事：这个进程能不能处理请求。数据库卡住时，两个应用也不会再被一起摘出路由。

早间汇总在计数上也学到了同样的教训。交易平台会把空闲机器挂起，被请求唤醒的机器在启动后几百毫秒时第一次检查会失败，下一次就通过了。把这些都算上，每天早上的汇总读起来都像出了故障。所以现在一分钟内重新通过的失败会单独列出，标注为机器唤醒和部署。

CI 上的定时任务

#

早间汇总一开始是一个按 cron 定时跑的 CI workflow，不到一天就挪走了。它要读应用分析和搜索数据之后，需要的密钥就成了分析项目的服务账号密钥，这个密钥在那个项目里什么都能干，我不想把它放进 CI 的 secrets。现在由我 Mac 上的定时调度程序每 20 分钟运行一次，只在奥克兰时间早上八点以后、而且当天还没发过的时候才发，所以八点时在睡眠的 Mac 会在醒来时补发。workflow 留着当手动备用，只是不带应用分析和搜索那两部分。

如果从头再来

#

我会在第一个用户到来之前、而不是第一次故障之后，先搭好三样东西：把错误发到团队本来就在看的聊天频道，并且限流；一个能用 SQL 查询的对象存储日志归档；以及平台本来就在收集的指标。每月花几美元而已。应用上手机的那一周加上崩溃报告，不然手机上的崩溃谁也不会知道。等要查看的地方多到我干脆一个都不看了，再加早间汇总。

链路追踪，我会等到出现第二个服务、请求真的要跨服务时再上；托管的 APM，等到有一个需要共享仪表板、值班轮换、也有预算替别人付账单的团队时再说。去年那篇里提到的工具，是从那时候开始才回本的。在那之前，最有用的习惯不花钱：一个数字看起来很吓人时，先搞清楚是什么产生了它，再判断是什么坏了。这篇里的好几次虚惊，都出在监控本身，而不是产品。

“在我机器上能跑"和"在生产环境能跑"之间有一道鸿沟，监控本该把它填上。可大多数时候填不上，因为监控往往被当成运维工具来建，而不是开发者出事时会伸手去拿的东西。

我最近开始以自由职业身份做 DevOps 和基础设施的活儿，每到一个新环境，最先看的东西之一就是监控配置——它比 README 更能说明一个团队的真实状态。失败的方式几乎千篇一律：工具都在，但和开发者的实际工作方式是脱节的。有人在一个 bug 上耗了三小时，其实能看生产日志的话五分钟就完事；故障不是靠告警发现的，是靠客服工单；或者反过来，一天 200 条告警，绝大部分是噪音，于是所有人干脆全部无视，每次出事的前半小时都花在搞清"到底坏了什么"上，而不是修它。

这篇讲的是通用做法。我现在给两个产品实际在用的工具，另外写了一篇。

指标、日志、链路：打通了才有用

#

指标告诉你出问题了（错误率飙升、延迟突增），日志告诉你发生了什么（堆栈、请求内容、报错信息），链路告诉你问题在哪（哪个服务、哪个接口、哪次数据库调用）。这些都是常识。关键在于三者有没有打通：告警一响，你应该能从指标一路点到相关日志，再点到链路。如果开发者还得在三个工具之间手动比对时间戳，那不管每个工具单看多漂亮，这套方案就是失败的。

仪表板也用同一条标准检验。CPU、内存、磁盘 I/O 对容量规划很重要，但对排查一个 500 错误毫无帮助。大家会主动打开的仪表板，上面放的是：技术指标旁边摆着业务指标（错误率旁边是每小时注册数）、时间轴上叠加的最近部署、最近一小时的前五个错误（带日志链接），以及延迟百分位——p50、p95、p99——而不只是平均值。一个没人主动打开的仪表板，就是没有证明自己的价值。

告警同理。每条告警都该回答两个问题：坏了什么？从哪开始查？

坏告警：“web-server-3 CPU 高”

好告警：“14:32 起 /api/payments 错误率 > 5%。最近部署：14:15，@sarah。[查看日志] [查看链路]”

往第二种靠拢有几个办法：按基线偏离告警，而不是按拍脑袋定的阈值；按归属路由（支付的错误发给支付团队，别全组织广播）；相关错误合并成一条 Slack 消息，别发 50 条。反馈环也要收紧——从"出事了"到"开发者知道了"应该在一分钟以内，这意味着实时日志流而不是五分钟一批、每个仪表板都有部署标记、以及跨服务边界不断链的分布式追踪。

为用它的人而建

#

运维团队最大的错误，是给自己建监控。解决办法一点也不高深：在开发者调试的时候坐到旁边，看他们在哪卡住；问问事故当中大家在问什么——“哪个服务？““什么变了？““请求长什么样？"；再搞清楚对产品真正要紧的指标是什么。基本不会是 CPU，多半是结账完成率、上传成功率这类东西。

然后是消除阻力。给新服务接监控要花一整天的话，没人会做。要提供能自动接入你们在用框架（Django、Express、Spring）的库、可以直接复制的仪表板和告警模板，以及不用提工单就能自己加指标的自助工具。整套东西还要当代码来管：配置进版本控制，告警规则要测试（该响的时候真的会响），要做多区域的话一开始就规划进去。

建好之后，还得靠同样的习惯让它活下去。埋点代码和其他生产代码一样走代码评审，自定义指标要配测试。每次复盘都要问一句"什么样的监控能让我们更早发现”，答案当周就落到仪表板和告警里，而不是只留在复盘报告中。另外我一年会清理几次，把没人打开的东西删掉，因为一条没人处理的告警，只会教大家忽略下一条。

AWS 上的小团队？先用 CloudWatch

#

不到 50 个工程师、又跑在 AWS 上的话，CloudWatch 就是正确起点，第一天就想买更高级工具的冲动最好忍住。EC2、Lambda、RDS、ECS 全都自动上报 CloudWatch，不写一行埋点代码就有了可见性；小团队每月 10~50 美元，没有固定平台费；指标、日志、链路（走 X-Ray）、告警都在一个地方。像样的告警和仪表板，一个下午就能搭出来，用不了几周。

最被低估的是 CloudWatch Logs Insights——不用架 Elasticsearch 就能查日志：

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)

其他几点：

• 复合告警能压噪音：错误率高"且"响应时间劣化时才告警，别每个条件单独响。
• 真正的价值在自定义指标。用 CloudWatch SDK 把业务指标（注册、交易、功能使用）和基础设施指标放在一起。
• CloudWatch Synthetics 能按计划跑金丝雀测试，模拟真实用户路径，让你赶在用户之前发现结账坏了。
• X-Ray 用极少的配置就能拿到分布式追踪，对大多数微服务架构够用了。

什么时候 CloudWatch 不够用了，也很好判断：要上多云了、想要正经的异常检测了、仪表板定制开始难受了，或者团队过了 50 人、需要真正的协作功能了。

团队大了：Datadog

#

Datadog 很贵——大组织一年 2 万到 10 万美元以上很正常——但到了规模就值回票价。AWS、Azure、GCP、本地机房、容器、Serverless、数据库、前端，一个视图全看到。Watchdog 不用手动调阈值就能标记异常模式，这点很关键，因为几千个服务是不可能靠人盯的。它还补上了 CloudWatch 缺的协作层：团队仪表板、RBAC、共享调查笔记本、PagerDuty/Opsgenie 集成、多条件告警、阈值突破预测、维护窗口，以及能下钻到代码级性能分析的 APM 和自动生成的服务拓扑图。

推行顺序我大致会这么排：先给关键服务接入，第一天就按团队和环境把标签打全；指标命名规范、仪表板模板、告警级别、SLO 定义要趁早定好——事后补标准是苦役；接入 CI/CD 部署标记、事件管理和 Slack；给培训留出时间，Datadog 强归强，不是看看就会的；最后盯紧账单：过滤噪音指标、大流量服务对链路采样、定期盘点到底在为哪些功能付费。

签约之前值得比较一下：New Relic（定位类似，大流量追踪有时更便宜）、Dynatrace（AIOps 很强，金融行业常见）、Splunk（日志分析顶级，安全团队已经在用的话更合适）、Grafana Cloud（已经在用 Prometheus/Loki 的话是自然归宿）。

实践中很多团队最后落在混合方案上：AWS 原生服务交给自动又便宜的 CloudWatch，应用层交给 Datadog，再让 Datadog 采集 CloudWatch 指标拼出统一视图。不花哨，但好使。

CloudWatch 和 Datadog 对比

#

从零开始：监控系统搭建顺序

#

我的顺序是：

1. 先找开发者聊，问清事故当中什么最痛。
2. 给要紧的流程定义 SLO：对登录、结账、搜索来说，“正常"到底是什么意思。
3. 从这条关键路径开始埋点。
4. 接着加分布式追踪，在微服务架构里它的排障回报率最高。
5. 告警挂在这些流程上，而不是挂在 CPU 上，每条告警发给负责的团队。
6. 给每条告警配一份运维手册，让凌晨三点的自己知道该查什么。
7. 在日历上排一个季度回顾，删掉过期告警、修正漂移的阈值、确认仪表板还对得上现在的架构。

再列几个我反复把团队从里面捞出来的坑：工具太多（能配合的 3 个胜过各自为战的 6 个）；图表没有基线（500 rps 是正常水位还是十倍突增？）；监控了用户根本感知不到的东西（无状态容器的磁盘 I/O）；还有监控系统本身没有冗余——告警系统在事故中间挂掉，你就在最不能瞎的时候瞎了。

这些没有一件需要最花哨的工具。需要的只是：让开发者在他们真正会看的地方，快速拿到需要的信息。