日志、指标、Tracing 与 OTel

Category

operation / observability 子树。节点定位：可观测性是证据组织问题——日志/指标/Tracing 三种不可替代的证据类型、采样代价与 OTel 边界。observability 子树总纲。

Definition

谈论可观测性时，团队往往先陷入工具选型：用哪套日志系统、要不要上链路追踪、OTel 接到什么程度。但工具只是承载形式，可观测性真正要解决的是证据组织问题——线上出事时，团队能不能在有限时间里把零散的运行痕迹拼成一条可信的因果链。日志、指标和 Tracing 之所以被并称三根支柱，不是因为它们常被装进同一个平台，而是因为它们是三种性质不同、互相不可替代的证据类型。

Problem

三样工具都买了定位还是卡 6 小时，缺的是证据链不是工具：指标回答「哪里异常」、日志回答「发生了什么」、Tracing 回答「路径在哪一跳」。三者的采样代价在游戏高并发低延迟场景被放大——证据组织没设计，堆工具只堆成本。

三根支柱各自回答什么问题

三种证据的分工，通常可以概括为：

• 指标回答“整体状态怎么样”：趋势、水位、异常波动，适合持续观看和触发告警。
• 日志回答“当时具体发生了什么”：离散事件的细节、上下文字段、错误堆栈，适合事后深挖。
• Tracing 回答“这一次处理经过了哪里”：调用经过哪些服务、每一段花多久、在哪一环断掉或变慢。

这三种分工背后是数据形态的差异。指标是预先聚合的时间序列，单条成本极低但几乎不保留细节；日志是带上下文的离散事件，细节丰富但存储和检索都昂贵；追踪把一次处理的多个片段按因果关系串成结构，介于两者之间，却要求链路上每一环都配合埋点。形态不同，决定了它们适合的问题不同，也决定了成本曲线完全不同。

为什么指标适合站岗而日志适合解剖

指标最大的价值是便宜且连续。一秒一个点、保存几个月，成本仍然可控，所以它适合承担值守职责：锚定基线、发现偏离、触发告警。日志相反，单条成本高、检索按量计费，没有人能靠持续阅读日志来值守，它的价值在事后解剖——已经知道大概哪里有问题，再按条件捞取细节。

由此带来一个常见的建设判断：告警尽量挂在指标上，而不是挂在“出现某条错误日志”上。日志驱动的告警往往噪声大、口径漂移，而指标告警的阈值、持续时间和恢复条件都更容易管理。日志告警并非不能做，但通常要收敛到极少数确有代表性的错误模式上。

日志建设的几条基础判断

日志在三种证据里量最大、也最容易被滥用，几条常见判断值得提前确立：

• 结构化优先：统一字段命名，检索和跨服务关联才有基础。
• trace id 与玩家 ID 是最值得标配的两个字段，前者串起链路，后者串起玩家视角。
• 级别语义要稳定：警告留给可自动恢复的异常，错误留给需要人看的问题，级别通胀会让过滤彻底失效。
• 错误日志要做去重与限速：同一错误短时间只记一条并累加次数，防止异常循环演变成日志风暴。
• 日志量本身也应该被监控：增速的异常跳变，经常是外挂扫描、循环缺陷这类异常行为的第一信号。

这些判断单看都朴素，难处在于跨服务坚持。日志规范一旦松动，检索质量和成本会同时恶化，而且恶化是渐进的，往往到故障时才集中显现。

Tracing 在游戏后端为什么更难落地

Web 后端里“请求”是天然的追踪单位：进来一个调用，出去一个响应，中间的调用树清晰。游戏后端大部分流量不具备这种边界——玩家会话是长连接，状态同步是持续流，一次对局可能持续十几分钟，帧驱动和广播驱动的内部调用几乎没有“一次请求”的概念。

所以游戏后端做 Tracing，往往要先重新定义“什么算一次追踪”。常见的选择是把追踪单位落在更小、更明确的动作上：

• 一次玩家操作触发的完整处理路径。
• 一次跨服务的调用，例如匹配请求、结算请求、支付回调。
• 一条异步消息从发出到消费完成的生命周期。

单位选错了，trace 要么大到没有分析价值，要么碎到拼不出全貌。这是游戏后端引入追踪时最值得先想清楚的问题，它的重要性通常高于具体实现的选择。

采样代价是游戏场景的核心约束

追踪的开销来自两头：运行时开销和存储成本。全量采集在低流量验证环境也许可行，到了生产规模几乎总要采样。常见的采样策略有几种取舍：

• 头部采样：在链路起点按比例决定是否记录，实现简单、开销确定，但可能正好丢掉出问题的那条。
• 尾部采样：先全量缓冲，事后保留错误的和慢的，信息价值高，但缓冲本身有成本，链路越长等待越久。
• 按特征采样：对特定玩家、特定玩法、特定错误类型提高采样率，往往性价比最好，但要求埋点时就把这些特征带进链路。

对游戏而言还有一层特殊约束：主链路是高频小操作，单条 trace 便宜，但乘上每秒几十万次操作后就是可观的成本。所以成熟做法通常不是追求全量，而是保住两条底线——错误和慢路径尽量留全，正常流量按比例抽样以维持基线对比能力。

三者关联起来才有定位能力

单独看，三根支柱各给出一块模糊的拼图：指标说某个服务延迟升高了，日志说那个时间段有很多超时，追踪说某类调用变慢了。只有当它们能互相关联——指标能下钻到对应时间段的日志，日志里带着 trace id 能拉出完整链路——定位才从拼凑猜测变成沿着证据走。

关联的基础是几个看似朴素的习惯：trace id 从入口生成后贯穿全链路，日志结构化并携带统一的字段命名，时间戳对齐到同一时钟。这些工作没有任何技术难度，难在跨团队坚持。很多团队三样工具都买了，关联却始终没建立，故障时依然是各看各的数据。

OTel 的真实价值与边界

OTel 这类统一采集标准的价值，主要在于降低碎片化：一套客户端库覆盖指标、日志、追踪，统一导出协议，后端存储可以替换而埋点不必重写。对于生命周期长、后端大概率换过好几轮存储的游戏项目，这种埋点资产可迁移的价值往往比功能本身更实在。

但它有两个常见误解。一是把接入标准当成方案本身：SDK 接好了，链路上什么算一个 span、关键字段叫什么名字、哪些事件值得记录，这些语义约定仍然要团队自己定义，标准不会替你回答。二是认为统一采集能自动覆盖游戏主链路：Tick 耗时、房间状态、匹配队列这些玩法层信号，本来就不在通用协议的默认语义里，还是得靠专项建设。

建设顺序上的常见判断

观测能力不适合一次性大而全地建设，更常见的路径是分阶段：

• 先把核心指标和关键业务日志立起来，保证出事能知道、能粗看。
• 再打通主链路追踪，重点覆盖跨服务的同步调用和高价值的异步流程。
• 最后按痛点补专项观测，例如慢查询归因、广播积压归因。

这个顺序背后的逻辑是投入产出比：指标和日志是定位的底座，缺了它们追踪也无从解读；而追踪的建设成本最高，放在主链路证据完整之后投入，才不会做成演示工程。

观测系统自身的成本治理

观测能力本身是一个持续消耗成本的子系统。日志量会随业务增长和异常循环膨胀，指标会随维度组合基数爆炸，存储会随保留策略悄悄翻倍。常见的治理手段包括分层保留（热数据短周期、错误数据长周期）、维度收敛（高基数标签进日志而不是进指标）、以及给日志写入加速率上限，防止异常循环把观测系统本身打垮。

更值得警惕的是反向情况：观测代码拖垮业务。同步写日志阻塞逻辑线程、每个请求全量上报、采样器在热点路径上加锁，这些都真实发生过。观测是旁路，旁路的任何代价都会转嫁到主链路上，接入时通常要按主链路代码的标准来审查。

指标口径与基线同样需要治理

指标不是采集完就一劳永逸。口径会漂移——同样是“延迟”，网关统计的可能是接入耗时，逻辑服统计的可能是处理耗时，两者画在同一张图上会互相污染。基线也会漂移——负载随版本和运营节奏变化，半年前定的阈值，今天可能天天误报或者从不触发。

常见的治理方式是给核心指标建立简单档案：口径定义、统计位置、负责人、阈值的依据。阈值不靠拍脑袋，而从历史分布推算并定期复核。这些动作的成本不高，缺了它们，指标越多反而越不可信。

什么时候值得加大投入

规模和架构是两个主要触发条件。单体小服务时代，日志加指标往往已经够用；服务拆分变多、故障开始在子系统之间传播时，追踪的收益会明显上升。另一个判断信号是恢复耗时：如果每次故障的定位时间远长于修复时间，说明证据链不足，加大观测投入通常比增加人力值班更有效。

判断投入方向的朴素方法，是回看最近几次故障：定位卡住的每一步，通常都对应一种缺失的证据形态。把这些卡点列出来，就是下一阶段观测建设的清单。

常见误区

• 三样工具都建设了，但彼此没有关联，故障时各看各的数据，结论互相矛盾。
• 追求全量采集，观测成本和噪声同步失控，关键信号反而被淹没。
• 把接入 OTel 当成可观测性方案本身，埋点通道统一了，语义约定却没人定义。
• 告警挂在日志匹配规则上，噪声大、口径漂移，值班很快疲劳。
• 观测代码不按主链路标准审查，采样和上报本身成为新的性能问题。

观测体系的目标从来不是记录得越多越好，而是在真正出事的那几分钟里，证据刚好够用、刚好能串起来。围绕这个目标做取舍，比围绕功能清单做选型更能避免返工。

实战案例：一次「三样工具都买了，定位还是卡了 6 小时」的证据链排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「三根支柱各自回答什么问题」「为什么指标适合站岗而日志适合解剖」「日志建设的几条基础判断」「三者关联起来才有定位能力」「指标口径与基线同样需要治理」「建设顺序上的常见判断」「什么时候值得加大投入」用到深水区：一次赛季结算夜的延迟故障，三样观测工具都在场，却没能拼出一条可信的因果链。

背景与现象：某长线项目赛季结算夜 20:10 起，玩家集中反馈对局内操作与结算变慢。值班打开三块面板各看各的：指标面板上网关 P99 从 45ms 抬到 420ms、逻辑服同刻 380ms，两条「延迟」曲线画在同一屏却对不上——一个记接入耗时（含排队）、一个只记处理耗时，差 40ms；告警面板 0 条触发——阈值 500ms 是半年前定的，此后没复核过，而日志告警倒响了 3 条规则，全是同一条错误循环刷出来的噪声；日志平台里 30 分钟窗口捞出 120 万条超时日志，无去重无限速；追踪平台里 8 个服务只有入口 2 个埋了 trace id，链路到第 3 跳断掉，事后核对还发现逻辑服与数据服的系统时钟差 40 秒。定位卡了 6 小时，而根因处置只花了 5 分钟——一个结算任务里未走索引的全量查询打满了连接池。

第一步：现象与口径——先分清「延迟在哪一段」和「证据属于谁」

口径统一：以「一次玩家操作触发的完整处理路径」为追踪单位，先把三条证据各自能回答的问题列清楚，记两笔：

• 口径：同一时刻网关 420ms、逻辑服 380ms，差 40ms 不是误差，是两个口径——一个含接入排队、一个只算处理
• 告警：指标告警 0 条（阈值 500ms 未到），日志告警 3 条全是同一错误循环的噪声——站岗的没站岗，解剖的全是噪声

两条曲线对不上不是数据坏了，是口径漂移：半年前定的阈值在漂移的基线上从来没机会触发，而真正在响的告警挂在日志匹配规则上。

第二步：分层归因——从延迟故障到证据链账本

指标账   阈值 500ms 半年未复核；网关 420 与逻辑服 380 同名「延迟」两个口径，差 40ms
日志账   30 分钟 120 万条超时日志（分钟均 4 万条），同一错误循环刷屏，去重限速 0
追踪账   8 个服务只有 2 个埋 trace id（覆盖 25%），链路第 3 跳断；逻辑服与数据服时钟差 40 秒
定位账   定位 6 小时（360 分钟）对修复 5 分钟 = 72 倍，证据链不足

账本收束：6 小时定位对 5 分钟修复的 72 倍，正是本页说的判断信号——「如果每次故障的定位时间远长于修复时间，说明证据链不足」；40ms 的口径差、40 秒的时钟差，各断掉一节因果链。

第三步：根因——三根支柱都在场，关联从来没建立

对照本页「三者关联起来才有定位能力」：关联的三件朴素习惯——trace id 从入口生成后贯穿全链路，日志结构化并携带统一的字段命名，时间戳对齐到同一时钟——一件都没做，8 个服务只埋了 2 个，「很多团队三样工具都买了，关联却始终没建立，故障时依然是各看各的数据」逐字应验。对照「为什么指标适合站岗而日志适合解剖」：告警挂在日志匹配规则上，响了 3 条全是噪声、阈值拍脑袋一次性给定，「日志驱动的告警往往噪声大、口径漂移」双向踩中。对照「日志建设的几条基础判断」：结构化、trace id 与玩家 ID 标配、级别语义、去重限速、日志量监控五条判断前四条全缺——120 万条日志里同一错误无限刷屏，正是「同一错误短时间只记一条并累加次数，防止异常循环演变成日志风暴」所防的现场。对照「指标口径与基线同样需要治理」：口径档案四件——口径定义、统计位置、负责人、阈值的依据——一件没有，「网关统计的可能是接入耗时，逻辑服统计的可能是处理耗时，两者画在同一张图上会互相污染」原样发生。本页「常见误区」五条里第一条与第四条原样命中。

第四步：处置与回填——先补证据关联，再按顺序补底座

修法分两段。应急：T+0 给结算任务的查询补索引并限流，连接池恢复，5 分钟止血；T+1 全服务时钟对齐，逻辑服与数据服 40 秒偏差归零，重放当晚日志按统一 trace id 串出完整链路，同一故障定位用时 25 分钟——从 360 分钟降到 25 分钟。制度三步：按本页「建设顺序上的常见判断」重排——第一步立指标与日志底座，先把核心指标和关键业务日志立起来，保证出事能知道、能粗看：告警全部迁到指标上（3 条日志告警全迁走），错误日志去重限速（同一错误 1 分钟只记 1 条并累加次数），trace id 与玩家 ID 进结构化必填字段；第二步打通主链路追踪：追踪单位落在「一次玩家操作」「一次跨服务调用」「一条异步消息从发出到消费完成的生命周期」三类动作上，8 个服务全量埋点，采样守两条底线——错误和慢路径尽量留全（100%），正常流量按 1% 抽样以维持基线对比能力；第三步建指标档案：核心 6 个指标逐个登记口径定义、统计位置、负责人、阈值的依据，阈值从近 30 天历史分布重推——P99 基线 210ms、告警线取 1.5 倍为 315ms，本例 420ms 会在抬升 2 分钟内触发而不是静默。复核：演练重放该故障，按新证据链定位 25 分钟、修复 5 分钟，定位倍数从 72 降到 5。

回填清单：

落点	动作	回填处
证据关联	trace id 入口生成贯穿全链路、结构化统一字段、时钟对齐	三者关联起来才有定位能力
告警与日志纪律	告警迁指标、错误日志去重限速、级别语义定档	日志建设的几条基础判断
追踪单位与采样	单位落三类动作、错误慢路径留全、正常按比例抽样	采样代价是游戏场景的核心约束
指标档案	六指标登记口径、位置、负责人、阈值并定期复核	指标口径与基线同样需要治理

案例的三个教训

1. 证据不关联等于没有证据——三样工具都在场，trace id 断在第 3 跳、时钟差 40 秒，每一样单看都真，拼不成一条因果链。
2. 定位远长于修复，就是证据链寄来的账单——6 小时对 5 分钟的 72 倍，比任何立项评审都更能说明该往哪加投入。
3. 口径与基线都会过期——半年前的 500ms 阈值、同屏差 40ms 的两条「延迟」，没有档案与复核，「观测体系的目标从来不是记录得越多越好，而是在真正出事的那几分钟里，证据刚好够用、刚好能串起来」就落不了地。

Used By

可观测体系建设（三支柱选型与采样策略）；OTel 接入的边界判断；观测系统自身的成本治理。

Related

关系链：证据组织 → 三支柱分工 → 采样代价 → 关联定位 → OTel 边界 → 建设顺序。上游：server 树（服务端运行的观测面）。下游：observability/02（游戏主链路自己的指标）。

Reference

本页为工程经验归纳；页内实战案例为教学示例（数字取整简化）。