2025年9月12日·1 分钟
第1天监控的生产可观测性入门包
生产可观测性入门包：第1天应添加的最少日志、指标和追踪，以及针对“太慢”问题的简单分诊流程。
新应用上线后最先坏的是什么
一款新应用遇到真实用户时，最先坏的很少是整个应用。通常是某一步骤突然变得繁忙、某个在测试中没问题的查询开始成为瓶颈，或某个依赖开始超时。真实用户带来真实的多样性：更慢的手机、不稳定的网络、奇怪的输入，以及在不合时宜时段的流量激增。
当有人说“太慢”时，他们可能指完全不同的情况。页面加载太久、交互卡顿、某个 API 调用超时、后台任务堆积，或第三方服务拖慢了一切。
这就是为什么你在需要仪表盘之前就需要信号。在第 1 天，你不需要为每个端点做完美图表。你需要足够的日志、指标和追踪来快速回答一个问题：时间都花在哪儿？
过早过度埋点也有真实风险。事件太多会制造噪音、增加费用，甚至拖慢应用。更糟的是，团队会开始不信任遥测数据，因为感觉混乱且不一致。
一个现实的第 1 天目标很简单：当收到“太慢”报告时，你能在 15 分钟内找到慢的步骤。你应该能判断瓶颈是在客户端渲染、API 处理器及其依赖、数据库或缓存，还是后台 worker 或外部服务。
示例：新的结账流程感觉慢。即使没有大量工具，你仍然希望能够说“95% 的时间花在支付提供商调用上”或“购物车查询扫描了太多行”。如果你用像 Koder.ai 这样的工具快速构建应用，这个第 1 天的基线更重要，因为快速交付只有在你也能快速排错时才有意义。
用通俗语言解释：日志、指标与追踪的区别
一个好的生产可观测性入门包使用三种不同的“视角”来看同一个应用，因为每种视角回答不同的问题。
日志是故事。它告诉你某个请求、某个用户或某个后台任务发生了什么。一个日志行可以写“订单 123 支付失败”或“数据库在 2s 后超时”，并包含 request ID、user ID 和错误信息等细节。当有人报告奇怪的单次问题时，日志通常是最快确认它是否发生以及影响到谁的方式。
指标是记分板。它们是你可以趋势和告警的数字：请求率、错误率、延迟百分位、CPU、队列深度。指标告诉你某事是罕见还是普遍，以及是否在恶化。如果在 10:05 所有人延迟都上升，指标会显示出来。
追踪是地图。trace 跟随单个请求在系统中流转（web -> API -> database -> 第三方）。它显示每一步耗时情况。这很重要，因为“太慢”几乎从不是一个大谜团，而通常是某个慢跳点。
在事故期间，一个实用流程如下：
- 用指标确认影响（多少用户、情况有多糟、何时开始）。
- 用追踪找到最慢的步骤（一个可采取行动的瓶颈）。
- 用日志解释瓶颈（具体错误、输入或边缘情形）。
一个简单规则：如果几分钟后你还不能指出一个瓶颈，你不是需要更多告警，而是需要更好的追踪，以及能把 traces 和日志关联起来的一致 ID。
第1天的约定，避免后续混乱
大多数“找不到原因”的事故并不是因为数据缺失，而是因为同一件事在不同服务中记录方式不一致。在第 1 天就统一一些约定，会让日志、指标和追踪在你需要快速答案时能对齐。
先为每个可部署单元选择一个 service 名称并保持稳定。如果 “checkout-api” 在一半仪表盘里变成了 “checkout”，你会丢失历史并打破告警。环境标签也一样，选一小套比如 prod 和 staging，并在所有地方使用。
接着，让每个请求都易于追踪。在边缘（API 网关、web 服务器或第一个处理器）生成一个 request ID，并在 HTTP 调用、消息队列和后台任务中传递。如果某个支持单写了“10:42 太慢”，单个 ID 能让你无需猜测就拉到精确的日志和 trace。
一套在第 1 天就好用的约定示例：
- 身份信息：service name、environment、version（或 build SHA）
- 关联信息：跨服务和任务传播的 request ID
- 核心标签：route（或 handler）、method、status code，以及若是多租户则有 tenant/org ID
- 追踪操作：把操作命名为端点和后台任务（而非随机函数名）
- 一致性：一种命名风格和一种时间单位用于时长
尽早约定时间单位。选毫秒用于 API 延迟，长任务用秒，并坚持使用。混合单位会让图表看起来没问题，却在叙述上出错。
一个具体例子：如果每个 API 都记录 duration_ms、route、status 和 request_id，那么像“租户 418 的结账慢”这样的报告就能快速过滤出来，而不是争论从哪里开始。
第1天要添加的最少日志
如果只能做一件事，把日志做成易搜的。那从结构化日志（通常为 JSON）和每个服务一致的字段开始。纯文本日志对本地开发没问题，但一旦有真实流量、重试和多个实例，它们就会变成噪音。
一个好规则是：记录你在事故中实际会用到的东西。大多数团队需要回答：这是什么请求？是谁发起的？在哪儿失败的？触及了哪些依赖？如果某条日志不能帮助回答这些问题，大概率不应该存在。
第 1 天保持一组小而一致的字段，这样你可以跨服务过滤和关联事件：
- 时间戳、级别和服务身份（service name、version、environment）
- 请求关联（
request_id、若有则trace_id） - 谁/在哪（
user_id或session_id、route、method） - 结果（状态码、
duration_ms） - 部署上下文（region/instance、release 或 commit）
发生错误时只记录一次并带上下文。包含错误类型（或代码）、简短消息、服务器错误的堆栈追踪以及涉及的上游依赖（例如：postgres、payment provider、cache）。避免在每次重试时重复相同的堆栈追踪；相反附上 request_id 以便追踪链路。
示例：用户报告无法保存设置。一次按 request_id 搜索显示 PATCH /settings 返回 500，然后日志中显示到 Postgres 的下游超时并含 duration_ms。你不需要完整 payload，只要路由、用户/会话和依赖名即可。
隐私是日志的一部分，不是以后的任务。不要记录密码、令牌、认证头、完整请求体或敏感 PII。如果需要识别用户，记录稳定 ID（或哈希值）而不是邮箱或电话号码。
如果你在 Koder.ai 上构建应用（React、Go、Flutter），值得从一开始就在每个生成的服务中内置这些字段，这样你就不会在第一次事故时“修复日志”。
捕捉大多数生产问题的最少指标
从内置可观测性开始
在 Koder.ai 中构建应用时，从第一天起就内置 request IDs、日志、指标和追踪。
一个好的入门包从一小组指标开始，快速回答一个问题：系统现在是否健康，如果不健康，哪里在受苦？
黄金信号
大多数生产问题会表现为四个“黄金信号”之一：延迟（响应变慢）、流量（负载变化）、错误（失败）和饱和（共享资源被耗尽）。如果你能在应用的主要部分看到这四个信号，就能在大多数事故中不靠猜测就做分诊。
延迟应看百分位而非平均值。跟踪 p50、p95 和 p99，这样你能看到少部分用户是否体验很差。流量端以每秒请求数为主（或工作器以每分钟任务数）。错误拆分 4xx 与 5xx：4xx 上升常指客户端行为或校验变更；5xx 上升指向你的应用或其依赖。饱和是“我们快耗尽某资源”的信号（CPU、内存、DB 连接、队列积压）。
按组件的指标清单
覆盖大多数应用的最小集合：
- HTTP/API：请求/秒、p50/p95/p99 延迟、4xx 率、5xx 率
- 数据库：查询延迟（至少 p95）、连接池使用（in-use vs max）、超时、慢查询计数
- 工作器/队列：队列深度、任务运行时 p95、重试数、死信/失败数
- 资源：CPU%、内存使用、磁盘使用（以及 I/O）、容器重启
- 部署健康：当前版本、部署后的错误率、重启循环（通常是坏发布的早期征兆）
一个具体例子：如果用户报告“太慢”且 API 的 p95 延迟激增但流量平稳，接着检查饱和度。如果 DB 连接池使用接近最大并且超时上升，你找到可能瓶颈；若 DB 看起来正常但队列深度快速增长，后台作业可能在抢占共享资源。
如果你在 Koder.ai 上构建应用，把这份清单作为第 1 天完成定义的一部分。应用小的时候添加这些指标比在第一次真实事故时补更容易。
让“太慢”可调试的最少追踪
当用户说“太慢”时，日志通常告诉你发生了什么，指标告诉你它发生的频率。追踪告诉你单个请求内部时间去了哪里。那条时间线能把模糊的抱怨变成明确的修复方向。
从服务器端开始。对进入应用的请求在边缘（第一个接收请求的处理器）做埋点，这样每个请求都能产生 trace。客户端追踪可以后面再加。
一个好的日一 trace 的 spans 应该映射到通常导致慢的部分：
- 请求处理器的 span（整个请求）
- 每个数据库调用或事务的 span
- 使用缓存时的 get/set span
- 每个外部 HTTP 调用的 span
- 当请求入队后台工作时的 span
为了让 traces 可以搜索和比较，捕获几个关键属性并在服务间保持一致。
对于入站请求的 span，记录路由（用模板形式如 /orders/:id，而不是完整 URL）、HTTP 方法、状态码和延迟。对于数据库 span，记录 DB 系统（PostgreSQL、MySQL）、操作类型（select、update）以及如果容易添加的表名。对于外部调用，记录依赖名（payments、email、maps）、目标主机和状态。
第 1 天采样很重要，否则成本与噪音会迅速增长。使用简单的 head-based 规则：对错误和慢请求采样 100%（若 SDK 支持），对普通流量采样较低比例（如 1–10%）。在流量低时起始采样率可以更高，然后随着使用量增长再降低。
“好”的样子是：一个 trace 能自上而下读出故事。示例：GET /checkout 花了 2.4s，DB 花了 120ms，缓存 10ms，外部支付调用花了 2.1s 并有重试。现在你知道问题在依赖而非代码。这就是生产可观测性入门包的核心。
针对“太慢”报告的简单分诊流程
当有人说“太慢”时，最快的胜利是把那种模糊的感觉变成几条具体问题。这个入门包的分诊流程即使在应用刚起步时也能用。
5 步分诊法
先缩小问题范围，然后按证据顺序推进。不要一上来就直奔数据库。
- 确认范围。是单个用户、一个客户账户、某个地区，还是所有人？还要问：是在 Wi‑Fi 和移动网络、以及多种浏览器/设备上都出现吗？
- 先看变化。是请求量激增、错误率上升，还是只有延迟上升？流量激增通常导致排队；错误上升通常指向依赖故障。
- 按路由/操作拆分慢点。查看各端点的 p95 延迟并找最差者。若只有一个路由慢，就从那儿入手；若所有路由都慢，考虑共享依赖或容量问题。
- 打开慢路径的 trace。抓一个慢请求的 trace 并按 span 时长排序。目标是一句结论：“大部分时间都在 X 上。”
- 验证依赖并决定是否回滚。检查数据库饱和、慢查询、缓存命中率和第三方响应时间；若问题在部署或配置变更后开始，回滚往往是最安全的第一步。
稳定后，做一项小改进：写下发生了什么并添加一个缺失的信号。例如：如果无法判断慢是否只在某地区出现，就为延迟指标加 region 标签；如果看到长时间的数据库 span 但不知道是哪个查询，小心地添加查询标签或“query name”字段。
快速例子：如果 checkout 的 p95 从 400 ms 跳到 3 s，trace 显示一个支付调用占了 2.4 s，你就能停止争论应用代码，把注意力放在提供商、重试和超时设置上。
能在5分钟内做的快速检查
使用最小化仪表盘
设定一个简单的事故主页视图目标：流量、p95 延迟、错误和一个饱和度指标。
当有人说“太慢”时，你可能会在弄清他们到底指什么上浪费一小时。入门包只有在能帮你快速缩小问题时才有用。
先问三个澄清问题：
- 谁受影响（单用户、某客户段、还是所有人）？
- 哪个确切操作慢（页面加载、搜索、结账、登录）？
- 从什么时候开始的（几分钟前、部署后、还是今天早上）？
然后看几组通常能指明方向的指标。别找完美仪表盘，只要“比正常差”的信号：
- 当前错误率（错误突增常被用户感觉为“慢”）
- 受影响端点的 p95 延迟（不是平均值）
- 饱和度：CPU、内存、DB 连接或队列深度（选最可能先被打满的）
如果 p95 升高但错误平稳，打开过去 15 分钟内该路由的一个慢 trace。单个 trace 常能显示时间是花在数据库、外部 API 还是等待锁上。
然后做一次日志搜索。如果有具体用户报告，用他们的 request_id（或关联 ID）搜并读时间线；如果没有，搜索相同时段内最常见的错误消息，看看是否与延迟同步出现。
最后决定是立即缓解还是深入调查。若用户被阻塞且饱和度高，临时缓解（扩容、回滚或禁用非必要特性）能争取时间；若影响小且系统稳定，则用 trace 与慢查询日志继续调查。
示例：在不猜测的情况下诊断慢结账
发布数小时后，支持开始收到票证：“结账需要 20 到 30 秒。”没人能在本地复现，猜测开始蔓延。这时入门包就派上用场了。
首先查看指标确认症状。HTTP 请求的 p95 图显示明显峰值，但仅在 POST /checkout 上，其他路由正常且错误率平稳。范围被缩小为“发布后某一路变慢”。
接着打开一个慢 POST /checkout 的 trace，瀑布图把元凶显现出来。两种常见结果：
PaymentProvider.chargespan 花了 18 秒，大部分时间在等待。DB: insert orderspan 很慢，显示在查询返回前有长时间等待。
用 trace 中的 request_id 在日志里验证。该请求的日志会显示类似“payment timeout reached”或“context deadline exceeded”的重复警告，以及新发布中加入的重试；若是数据库路径，日志可能显示锁等待或超过阈值记录的慢查询语句。
当三条信号一致时，修复很直接：
- 回滚到上一个发布以终止影响。
- 为支付调用加显式超时并限制重试。
- 为依赖添加指标，例如 p95 payment provider duration 和 p95 DB query duration。
关键是：你不是在盲猜。指标指向端点，追踪指向慢步骤，日志用具体请求确认失败模式。
在事故中最浪费时间的常见错误
更快构建与监控
把聊天规格转换为可快速监控和调试的 React、Go 和 Postgres 应用。
大多数事故时间都被可避免的缺陷吞噬：数据存在但太吵、太贵或缺少能把症状和原因连起来的关键细节。入门包只有在压力下仍可用才有价值。
一个常见陷阱是记录过多，尤其是原始请求体。一开始听起来很有用，但很快你会为大量存储买单、搜索变慢，并可能意外记录密码、令牌或个人敏感数据。优先结构化字段（route、status code、latency、request_id），且仅记录经明确允许的小片输入。
另一个耗时的是看起来详细但无法聚合的指标。高基数标签（完整用户 ID、邮箱、订单号）会让指标序列爆炸并使仪表盘不可靠。把用户级别信息放在日志中，指标用粗粒度标签（route 名称、HTTP 方法、状态类别、依赖名）。
重复阻碍快速诊断的问题有：
- 只看平均值。平均值会掩盖痛点；当用户说“太慢”时看 p95/p99。
- 没有上下文的 trace。若 spans 没有路由名和依赖名，trace 就像一张无标签图。
- 没有发布标记。看不到版本变更，你只能猜测是否是部署导致的问题。
- 没有负责人告警。告警触发但没人知道下一步做什么，久而久之就被忽视。
- 日志不可搜索。自由文本日志没有一致键，每次事故都变成手工搜索。
一个小例子：若 checkout 的 p95 从 800ms 跳到 4s，你希望在几分钟内回答：它是否在发布后开始，以及时间是否花在你系统内或外部依赖（数据库、支付、缓存）。有百分位、发布标签和带路由与依赖名的 trace，你能迅速得出结论；没有这些，你会在事故窗口里浪费时间争论猜测。
下一步：让每个新应用都可复用
真正的收益来自一致性。入门包只有在每个新服务都带着相同的基础、统一命名并在故障时容易找到时才有用。
把第 1 天的选择做成团队可复用的简短模板。保持精简但具体。
- 对每个入站请求生成 request ID，并在日志与追踪中携带。
- 记录那些你始终需要的事件：请求开始/结束、错误（带明确类型）、以及超过阈值的慢请求。
- 跟踪几项黄金指标：流量、错误率、延迟（p50 与 p95）和一项饱和度指标（CPU、内存、DB 池或队列深度）。
- 为关键路由和主要依赖（数据库与一个外部 API）添加基本追踪。
- 在日志、指标与追踪中附加 release/version 标签，这样你能回答：“这是在部署后开始的吗？”
创建一个“主视图”，任何人在事故时都能打开。一屏应显示每分钟请求数、错误率、p95 延迟和你的主要饱和度指标，并支持按环境与版本过滤。
告警初期保持最小化。两个告警能覆盖很多场景：关键路由的错误率突增与同一路由的 p95 延迟突增。如果添加更多告警，确保每个告警都有明确的操作步骤。
最后，设定每月复盘。移除噪音告警、收紧命名并补充一个在上次事故中会节省时间的缺失信号。
要把这嵌入构建流程，在发布检查清单中加入“可观测性门槛”：无 request IDs、无版本标签、无主视图或无两个基准告警则不可部署。如果你用 Koder.ai 部署，可以在发布前在 planning 模式中定义这些日一信号，然后使用快照与回滚在需要快速调整时安全迭代。
常见问题
真实用户访问新应用时通常先坏的是什么？
从用户进入系统的第一个地方开始：web 服务器、API 网关或第一个处理器。
- 添加
request_id并在所有内部调用中传递。 - 为每个请求记录
route、method、status和duration_ms。 - 按路由追踪 p95 延迟和 5xx 率。
单凭这些通常能让你快速定位到具体端点和时间窗口。
现实的第1天可观测性目标是什么？
设定一个现实的默认目标：你能在 15 分钟内 找出慢的步骤。
第 1 天你不需要完美的仪表盘，但需要足够的信号来回答：
- 是客户端、API、数据库/缓存、后台任务还是外部依赖？
- 哪个路由或任务类型受影响？
- 是在部署或配置变更后开始的吗？
何时使用日志、指标与追踪？
三者配合使用，每种工具回答不同的问题：
- 指标（Metrics）： “这是不是广泛发生并在变坏？”（速率、百分位、饱和度）
- 追踪（Traces）： “这个请求内部时间花在哪儿？”（慢的跳点）
- 日志（Logs）： “这个用户/请求到底发生了什么？”（错误、输入、上下文）
在事故中：用指标确认影响，用追踪找到瓶颈，用日志解释细节。
哪些命名与打标签的约定能防止后续混乱？
选一小套约定并在所有地方统一使用：
- 稳定的
service_name、environment（如prod/staging）和version - 在边缘生成并传播的
request_id - 一致的标签：
route、method、status_code和tenant_id（若多租户） - 统一时间单位（例如
duration_ms）
目标是同一个过滤条件能跨服务工作，而不是每次都从头开始。
第1天我应该添加哪些最小日志？
默认使用结构化日志（通常为 JSON），并在所有服务中保持相同键。
立即有用的最小字段：
timestamp、level、service_name、environment、versionrequest_id（若有则trace_id）route、method、status_code、duration_msuser_id或session_id（稳定 ID，而不是邮箱）
错误只记录一次并带上下文（错误类型/代码 + 消息 + 依赖名）。避免在每次重试时重复相同的堆栈追踪。
哪些最小指标能捕捉大多数生产问题？
从每个主要组件的四个“黄金信号”开始：
- 延迟（Latency）： p50/p95/p99（避免用平均值）
- 流量（Traffic）： 请求/秒（或任务/分钟）
- 错误（Errors）： 4xx 与 5xx 率
- 饱和度（Saturation）： 某个资源达上限（CPU、内存、DB 连接、队列积压）
按组件的最小清单示例：
- HTTP/API：请求/秒、p50/p95/p99 延迟、4xx 率、5xx 率
- 数据库：查询延迟（至少 p95）、连接池使用（in-use vs max）、超时、慢查询数
- 工作器/队列：队列深度、任务运行时 p95、重试、死信数
- 资源：CPU%、内存使用、磁盘使用（以及 I/O）和容器重启
- 部署健康：当前版本、部署后的错误率、重启循环
这些指标能在大多数情况下让你快速判断系统健康并定位受影响区域。
使“太慢”可调试的最小追踪设置是什么？
先从服务器端开始。对进入应用的请求在最外层（第一个处理器）做埋点，这样每个请求都能生成 trace。客户端追踪可以后置。
一个有用的日一 trace 应包含映射到常见慢点的 span：
- 请求处理器的整体 span
- 每个数据库调用的 span
- 缓存的 get/set span
- 每个外部 HTTP 调用的 span
- 将工作入队的 span
为了便于搜索和对比，给 span 捕获一些一致的属性：路由（模板形式 /orders/:id）、HTTP 方法、状态码和延迟；数据库 span 标注 DB 类型、操作类型和表名（如果容易添加）；外部调用标注依赖名（payments、email 等）、目标主机和状态。
采样在日一很重要：避免成本和噪音失控。简单规则：对错误和慢请求采样 100%（如果 SDK 支持），对正常流量采样 1–10%。流量低时可以先采更高比例，然后随使用量增长降低。
“好”的表现是：一个 trace 能自上而下讲清楚故事。例：GET /checkout 花了 2.4s，DB 花 120ms，缓存 10ms，外部支付调用花了 2.1s 并有重试。这样你就知道问题在依赖而非自己的代码。
当有人说“太慢”时，我应该怎么分诊？
把模糊的“太慢”转成几条具体的问题然后按证据推进。这个日一分诊流程适用于刚起步的应用。
步骤：
- 确认范围：是单个用户、单个客户账户、某一地区还是全部用户？是否在 Wi‑Fi 和蜂窝网络、不同浏览器/设备上都出现？
- 先看变化：是请求量突增、错误率上升，还是只有延迟上升？流量激增常导致排队；错误上升常指向某个依赖坏了。
- 按路由/操作拆分慢点：看各端点的 p95 延迟，找最差者。若只有一个路由慢，就集中处理；若全部变慢，考虑共享依赖或容量问题。
- 打开一个慢请求的 trace：按时长排序 spans，目标是一句话总结：“大部分时间在 X 上”。
- 验证依赖并决定是否回滚：检查 DB 饱和、慢查询、缓存命中率和第三方响应时间；若发生在部署后，回滚通常是最安全的第一步。
稳定后，做一项小改进：记录发生了什么并补一个缺失的信号。例如：如果无法判断是否只在某地区慢，给延迟指标加上 region 标签；若发现长时间的 DB span 但不知道哪个查询，谨慎地添加 query name 字段或查询标签。
有哪些可以在5分钟内做的快速检查？
当有人说“太慢”时，你可能会浪费一个小时只是弄清楚他们到底指什么。有效的生产可观测性入门包必须能让你在短时间内缩小问题范围。
先问三个澄清问题：
- 受影响的是谁（单用户、某客户群、还是所有人）？
- 哪个具体动作慢（页面加载、搜索、结账、登录）？
- 何时开始的（几分钟前、部署后、还是今天早上）？
然后看几组通常能指明方向的数字：不要找完美的仪表盘，只要“比正常差”。
- 当前错误率（错误突增看起来常像慢）
- 受影响端点的 p95 延迟（不要看平均值）
- 饱和度：CPU、内存、DB 连接或队列深度（选最可能先被打满的）
若 p95 上升但错误平稳，打开最近 15 分钟内该路由的一个慢 trace。单个 trace 常能显示时间是花在数据库、外部 API 还是等待锁上。
再做一次日志搜索：有特定用户报告就按他们的 request_id（或相关 ID）搜并读时间线；没有就搜相同时间窗口内最常见的错误消息，看看是否与延迟同步出现。
最后决定是立即缓解还是深入排查。若用户被阻塞且饱和度高，临时扩容、回滚或关闭非必要功能旗帜能争取时间；若影响小且系统稳定，就用 trace 与慢查询日志继续调查。
能否举例说明如何在不猜测的情况下诊断慢的结账？
发布几个小时后，支持收到“结账需要 20–30 秒”的票证。没人本地能复现，这时猜测开始。可观测性入门包的价值就体现出来了。
首先去看指标确认症状。HTTP 请求的 p95 图表显示清晰峰值，但仅在 POST /checkout 上，其他路由正常且错误率平稳。这把范围从“整个站点慢”缩小为“一个端点在发布后变慢”。
接着打开一个慢 POST /checkout 的 trace，瀑布图立刻暴露元凶。两类常见结果：
PaymentProvider.chargespan 花了 18 秒，大部分时间在等待。DB: insert orderspan 很慢，显示查询返回前有长时间等待。
用 trace 中的同一 request_id（或存日志中的 trace_id）在日志里验证。在该请求的日志里，你会看到类似“payment timeout reached”或“context deadline exceeded”的重复警告，以及新发布中加入的重试记录；若是数据库问题，日志可能显示锁等待或超过阈值的慢查询语句。
当三条信号一致时，修复很直接：
- 回滚到上一个发布以停止客户受影响。
- 为支付调用加显式超时并限制重试次数。
- 添加依赖时延的指标，例如 p95 payment provider duration 和 p95 DB query duration。
关键是你不用盲猜：指标指向端点，追踪指向慢步骤，日志用确切请求说明失败模式。
在事故中最浪费时间的常见可观测性错误有哪些？
大多数事故时间浪费都来自可避免的缺口：数据存在但噪音太多、风险太高或缺少某个关键细节，导致症状和原因无法连接。入门包只有在压力下依然可用才有用。
常见陷阱是记录过多原始请求体。开始听起来有用，但很快你会为大量存储付费、搜索变慢，甚至意外记录到密码、令牌或敏感个人信息。优先结构化字段（route、status code、latency、request_id），只记录经过明确允许的小片输入。
另一个时间陷阱是看起来详细但无法聚合的指标。高基数标签（完整用户 ID、邮箱、唯一订单号）会让指标序列爆炸，仪表盘变得不可靠。把用户相关信息保留在日志中而非指标，指标用粗粒度标签（route 名称、HTTP 方法、状态类别、依赖名）。
重复阻碍快速诊断的错误：
- 只看平均值。平均值掩盖痛点；用户说“慢”时看 p95/p99。
- 缺乏上下文的追踪。若 span 没有路由名和依赖名，trace 就像无标签的图片。
- 没有发布标记。看不到版本何时变更，你就会猜测是否是 deploy 导致的问题。
- 无负责人告警。告警触发却没人知道下一步做什么，会变成噪音并被忽视。
- 无法搜索的日志。自由文本日志没有一致键，每次事故都变成手工 grep。
一个小例子：若 checkout p95 从 800ms 跳到 4s，你希望在几分钟内回答两个问题：它是否在发布后开始，以及时间是否花在你代码里还是依赖（数据库、支付、缓存）。有百分位、发布标签和带路由与依赖名的追踪，你可以迅速得出结论；没有它们，你会在事故窗口里浪费时间争论猜测。