日志越写越贵却查不出东西：字段规范和分级留存从哪里下手

日志越写越贵却查不出东西：字段规范和分级留存从哪里下手

账单逐月上涨，排障时却还是只能靠猜

存储账单逐月上涨，真正排障时却还是靠猜——日志出问题，通常不是采得不够多，而是字段从来没定过。很多团队的第一反应很直接：磁盘不够就加盘，检索变慢就加节点，成本压不住就全线降采样。这一整套动作背后藏着同一个前提，即"日志本身是有价值的，只是装不下"。但真实情况常常恰好相反：堆在系统里的，是一批字段不统一、口径不一致、谁也说不清哪些能删的行文本，它们吃掉绝大部分存储与检索资源，而排障时真正能被用上的可能只占很小一部分。于是就出现了那种很别扭的局面——钱花得越来越多，能回答的问题却没变多。

把这件事拆开看，变量其实只有两个：采了多少，以及采进来的东西能不能被用。前者是成本项，后者是能力项。采集量的增长是线性可控的，字段混乱带来的损失却是乘数级的。同一个服务在两条日志里把耗时写成 cost、latency、rt 三种名字，聚合函数就没法落笔；同一个错误码在 A 服务里是字符串、在 B 服务里是数字，过滤条件就会漏掉一半；时间戳有的带时区有的不带，跨服务排序就只能靠人肉推测。这些问题的解法都不是"多采一点"或"多加几台机器"，而是先把口径定下来，让机器能稳定地读懂每一行。

本篇只想回答一个问题：日志量一直在涨、账单一直在涨，排障却还是靠猜，问题到底出在采集量还是字段规范？结论偏向后者的比例，比大多数人以为的高得多。日志的可用性主要由字段规范与分级留存决定，而不是采集量；先固定少数关键字段、按用途划分留存与检索层级，再谈索引和查询优化，顺序反了只会越花越多。下面按用途、字段、结构化程度、留存、采样这条顺序往下拆——这个顺序本身就是结论的一部分。

四类用途，四类几乎互相冲突的硬要求

日志从来不是一种东西。同样是"写一行记录"，为了实时排障写的、为了审计留痕写的、为了业务分析写的、为了安全取证写的，要求几乎互相冲突。把它们混进同一个池子、用同一套策略管理，是后面所有麻烦的起点。常见的情况是：一套保留策略同时服务四类用途，结果对排障来说太长、对合规来说太短、对分析来说字段太脏、对取证来说又被采样掉了关键几条。四类用途不分家，任何一项单独优化都会牵动另外三项。

实时排障要的是快，以及能关联。出事的那几分钟里，工程师要的是按请求 ID 把一次调用在所有服务里的记录全捞出来，按时间排好序，看清楚卡在哪一步、哪个下游先慢下来。它对字段完整性要求不高，对检索延迟和关联性要求极高，保留期却可以很短——绝大多数线上问题不会等到下周才查，热层覆盖最近数天往往已经够用，更早的部分转冷层按需回捞即可。把排障日志按合规周期去留，是纯粹的成本浪费。

审计留痕的要求正好掉过来。它不追求秒级检索，但要求完整、要求事后不可被随意改动：谁在什么时间、对什么资源、做了什么操作、结果如何。这类记录的价值在于可追溯与可举证的完整性，保留期由合规要求与内部制度共同决定，往常以年为单位计，而且写入之后就不该再被裁剪或重写。把它和排障日志放进同一个可变存储里、允许任何人批量删除，是审计场景最容易踩的坑——不是技术坑，是治理坑。

业务分析要的是字段稳定。同一个含义的字段不能今天叫 order_id、明天叫 orderId、后天叫 oid，否则基于它跑出来的看板和报表会静默出错：不是报错，是数字悄悄变了，这比报错难发现得多。业务分析类日志通常体量最大、查询频次最低但对聚合能力要求最高，很多团队会把它从检索型存储里挪出去，落到列式存储或者预聚合表里，只保留汇总结果。这里的关键不是存多久，而是字段改名时有没有过渡期和映射表。

安全取证要的是保真，以及够久。入侵和滥用往往在发生很久之后才被发现，回溯时需要的是原始、未被裁剪、带有完整上下文的记录。它对字段规范的要求是另一套：来源地址、身份类别标识、操作对象、结果状态，这些要素要能还原出一条完整事件链。而且它绝不能被采样——恰好被采掉的那一条，很可能就是唯一能证明发生了什么的那一条。安全取证与审计留痕的共同点是都要久，区别在于取证需要的是上下文的完整，审计需要的是结论的不可否认。

关键字段清单：先钉死七八个，其余交给团队自己扩展

字段规范的起点不是列一张大表，而是承认一个事实：一个组织真正能强制统一的字段数量是有限的。经验上看，能管住的通常是七八个，超过这个数执行就会走形——要么各团队开始自行发挥，要么规范文档写完就没人再看。所以正确做法是先钉死最关键的几个，剩下的交给各团队在扩展命名空间里自己定义，只要不污染公共字段即可。

带时区的时间戳是第一个。这不是细枝末节，是跨服务排序和跨地域聚合的地基。建议统一到带偏移量的时间格式，在写入侧强制，不给"服务器本地时间"留任何口子。第二个是链路或请求 ID，它必须在入口生成后贯穿所有下游调用，包括异步任务和消息队列——大量链路断在这里，不是因为没埋点，而是因为异步环节、定时任务、消息消费这一侧没有把上下文传下去，导致排障时前半段有、后半段没了。

第三个是日志级别，并且级别的定义要写清楚：什么样算 ERROR、什么样算 WARN、什么样只是 INFO，不要让每个开发者自己判断。级别定义不统一，就会出现在高峰期把 WARNING 全量打开、把真正的错误淹没掉的场面。第四个是服务名与实例标识，用于从现象定位到具体进程和具体那一台。第五个是错误码，最好配一张统一码表，而不是把异常堆栈原文直接塞进来当字段用。第六个是耗时，字段名和单位都要统一，毫秒是常见选择。

第七类是少量上下文标识，比如租户、业务线、订单类别——注意是类别而不是身份本身。这类字段建议控制在三到五个以内，加进去之前先问一句：它会不会被用来做聚合或过滤？如果答案是"一年也用不上一次"，那就先别加。上下文字段是最容易失控的部分，因为每一条单独看都"以后可能有用"，累积起来却会成为存储和索引的主要负担，而且没人敢删。

命名口径与取值口径统一，比字段数量更关键

有了清单不等于有了规范。真正决定检索和聚合能不能跑通的，是命名口径与取值口径。命名口径指同一个含义在任何服务里都叫同一个名字、同一种大小写风格；取值口径指同一个字段的取值范围和数据类型保持一致。前者影响的是"能不能写查询"，后者影响的是"写出来对不对"。

取值口径更容易出问题，也更难被发现。耗时字段有的写整数毫秒、有的写带单位的字符串、有的在超时时填 -1；状态字段有的服务写 success 与 fail，有的写 0 与 1，还有的直接写 HTTP 状态码。这些差异在单条日志里完全看不出来，一旦要做"按服务统计耗时分布"就全线崩掉，而且崩的方式是静默的——图照样画得出来，只是数字不对。等到有人质疑数字时才去查，往往已经积累了好几个月的脏数据。

管住口径的办法不是靠文档自觉，而是靠写入侧校验。统一封装日志库、设字段白名单、做类型校验、对未知字段自动打标，这些措施在写入端做成本最低；等到数据已经落盘再去做归一化，成本会高一个量级，而且永远追不上新写入的部分。这也解释了为什么"先把字段定下来"这件事存在明确的时间窗口：越往后拖，存量越大，改动的代价越高，最后会被迫接受"新数据按新规范、老数据维持原样"的双轨状态，而双轨状态本身就是查询成本的一部分。

结构化程度的三个档位，混用才是真正的成本黑洞

结构化程度大致分三档。纯行文本是拼接出来的那一类，人读起来最顺，机器几乎无法聚合，只能靠正则去捞，正则稍微一改就要重扫全量。半结构化是 key=value 或类 JSON 但字段不固定的那一类，能解析，但字段时有时无、类型飘忽，查询时要写大量兜底逻辑。结构化是字段固定、类型固定的那一类，写入时约束多一点，检索和聚合时最省。

同一个系统内部混用多档，才是查询成本急剧上升的真正原因。一次排障要同时扫三种形态：对结构化日志走字段过滤，对行文本走正则匹配，对半结构化做条件判断和空值兜底，每一步都要付出解析开销，而且结果还可能对不齐——同一个含义在不同形态里取出来的值域不一样，时间也没法直接比较。很多团队以为是查询引擎不够快、索引建得不够多，实际是数据形态太杂，让引擎的绝大部分优化都落不了地。

所以结构化改造的优先级不是"把所有系统一次性改完"，而是"先让每一个系统内部统一到同一档"。一个系统内部全用结构化，哪怕字段少一点，也远好过一半结构化、一半行文本。跨系统之间的档位差异可以慢慢收敛，系统内部的混用要优先解决——因为排障恰恰是跨系统的，而跨系统查询只有在各方形态一致时才可能走通。改造顺序建议按故障频次排，先动最常被查的那几个服务。

用途对照表：从这张表开始定策略

把四类用途加上合规留存这一项摊开来看，各自的字段要求、保留期依据和可接受的处理方式差别非常清楚。这张表的价值不在于罗列，而在于它给出了一个判断顺序：先确定一条日志属于哪一类用途，再决定它必须带哪些字段、能留多久、能不能采样。绝大多数关于"这条日志该不该删"的争论，本质上都是因为没有人先回答它属于哪一类。

这张表还可以反过来用：如果一条日志填不进任何一行，或者填进去之后"必须包含的字段"一列大部分为空，那它大概率是被写进来充数的。这类日志通常有一个共同特征——写的人说不出谁会在什么场景下查它。对它们最经济的处理不是归档，而是从源头停掉；把写入关掉之后如果一两周内没人来问，就说明判断是对的。给每一条新增日志都要求填一次这张表，比任何事后治理都有效。

热温冷留存怎么分级：依据是用途与合规，不是"先留一年"

"先留一年再说"是最贵的做法，也是最省事的做法。它的逻辑是：留着总比删了强，万一以后要查呢。问题是这个"万一"从来没有变成具体场景，而存储、索引和备份的成本却是每个周期都在发生的。分级留存的判断依据只有两个：用途和合规要求。用途决定它需要被多快查到、以什么形式被查；合规决定它至少得留多久。除此之外的任何理由，都不构成保留的依据。

热层供实时检索，覆盖的是排障窗口内的数据，要求是低延迟、字段可过滤、能按链路 ID 精确召回，因此体量必须被严格控制——热层放的东西越多，单位检索成本越高。温层承接的是过了排障窗口但仍可能被偶尔回捞的部分，检索慢一些可以接受，通常保留字段完整的原始数据。冷层供追溯与合规，追求的是单位存储成本和长期可靠性，检索能力可以让步，按需回捞即可，甚至可以先打包归档、查的时候再恢复。

判断一条日志该落在哪一层，可以问三个具体问题：它在多久之后还会被查？被查时是需要看明细还是只看聚合结果？删掉它会不会违反什么规定或合同约定？三个问题都答不上来的，说明它本来就不该被采集进来。这三个问题不需要开评审会，写在日志登记表的备注栏里就够了——真正的门槛不是流程复杂度，而是有没有人愿意在写这条日志之前花三十秒想清楚。

还要区分两件容易被混为一谈的事：冷热分层与采样。分层改变的是存储位置和检索能力，数据本身还在，需要时能拿回来；采样改变的是数据总量，被丢弃的那部分永远回不来。因此分层的决策可以相对激进——把大量数据推向冷层，成本低、风险可控；采样的决策必须保守，尤其是错误、审计、资金相关事件。用分层替代采样来压成本，是更安全也更有效的一条路。而分层一旦落地，底层资源的需求形态也会跟着变：热层更看重检索节点的稳定与低延迟，冷层更看重大容量存储与长期可靠性，两部分的机型、磁盘组合与机房位置通常不该按同一套方案配置，资源怎么摆需要在规划阶段就一起算清楚，而不是等账单涨上来之后再补救。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

采样与丢弃的边界：哪些能砍，哪些一条都不能少

采样本身不是坏事，坏的是无差别采样。可以按比例砍的，通常是高频成功路径与调试级日志：一次成功的健康检查、一次正常的缓存命中、一次被完整走通的普通请求，这类记录数量巨大、信息重复度高，采百分之一甚至千分之一都足以反映整体状况。DEBUG 级别同理，它在排查特定问题时很有用，但不该长期全量开着，按服务、按时间段临时开启是更合理的做法。

不该采样的是审计、资金与错误事件。审计记录被采掉就意味着留痕不完整，留痕不完整的审计等于没有审计；资金相关的操作记录被采掉，事后对账就缺了依据；错误事件被采掉，等于把最需要保留的那部分删掉了——错误天然是低频的，低频数据采样的收益极小而风险极大。这几类应该走"全量写入 + 冷层归档"的路线，用分层而不是用采样来控制成本。

采样的正确做法是"按用途采样"而不是"按比例采样"。前者先在写入侧判断这条日志属于哪一类，再决定采不采；后者对整条数据流施加统一比例，把不该采的一起采掉了。实现上差别不大——无非是在日志库里多一个分类标记——效果却完全不同。另外一个常被忽略的原则是：采样决策要在写入前做，不要写进去之后再删。写进去再删等于把写入、索引、备份的成本全付了一遍，只省下最后那点存储，是最不划算的一种节省。

日志、指标、链路各自负责什么，别互相顶替

把日志当指标用，是最隐蔽的一种浪费。想知道每分钟的订单成功率、想知道接口耗时的分布变化，这是指标的活；用日志去做，意味着每次查询都要扫全量文本、做一次聚合，成本高、延迟大，而且结果还不稳定——采样率一变，数字就跟着变。反过来，想搞清楚某一次具体请求为什么失败，这是日志的活；用指标去做，只能看到曲线抖了一下，看不到原因。两者顶替的结果通常是钱花了、问题没解决。

三者的分工可以这样记：指标回答"有多少、趋势如何"，链路回答"卡在哪一步、谁拖慢了谁"，日志回答"为什么会发生"。指标是预聚合的数值时间序列，量小、查询快、适合做告警和看板；链路以一次调用为组织单位，天生带上下文，适合定位瓶颈；日志是离散事件记录，信息最全、成本也最高，适合回答前两者回答不了的细节问题。同一个问题可能同时需要三者，但入口不同：先从指标发现异常，再用链路缩小范围，最后用日志确认原因。

把三者串起来的锚点是链路 ID。指标里带上服务与结果维度、链路里带上完整的调用树、日志里带上同一个请求 ID，排障时才能从"某个接口的失败率在上涨"一路走到"这一批请求都卡在了这个下游的这个错误码上"。这也是为什么链路 ID 必须被列为强制字段——它不是可选的增强项，而是三套数据能否互通的前提。缺了它，三套系统各自正确，合在一起却拼不出答案。

敏感字段不许进日志，也别指望事后清理

身份标识、联系方式、凭证信息，这三类是最常出现在日志里的敏感内容。它们的共同特点是：写的时候很自然——调试时打一下请求体、排障时把入参全量输出、为了定位把用户完整信息带上——事后却极难彻底清除。日志会被复制、被备份、被同步到分析系统、被导进本地文件，清除的时候要追所有这些副本，遗漏一个就等于没清。日志系统往往是组织内数据副本最多的系统之一，这既是它难治理的地方，也是敏感字段风险高的原因。

正确的处理位置是写入侧，而不是事后。做法上有几个层次：能不写就不写，这是第一选择，大多数时候把完整入参打出来只是因为方便，并不是真的需要；必须写的做脱敏，保留能定位问题的部分、去掉能识别到人的部分，比如保留用户类别而不保留具体联系方式；既不能去掉又确实需要的，用引用标识代替真值，通过受控接口按需反查，这样日志里留下的是 ID 而不是明文凭证。

还有一点容易被忽略：脱敏应该是结构化的，而不是靠正则去捞。字段固定、类型固定之后，敏感字段就是少数几个已知名字的字段，在日志库里直接拦截即可；如果日志还是一堆自由文本，就只能用正则全覆盖地扫，漏网是必然的。这又回到了字段规范——字段规范不只是为了查询方便，它同时也是安全治理能落地的条件。规范做得好的系统，敏感字段治理是配置工作；规范做得差的系统，它是一场永远打不完的仗。

把全量当可观测、把日志当指标：六个反复出现的误区

第一个误区是认为全量采集等于可观测。可观测性指的是能从外部输出推断内部状态的能力，前提是输出有意义且能被关联；一堆字段混乱、无法聚合、无法按请求串起来的全量记录，只提供了量，没有提供推断能力。全量采集反而会稀释注意力——真正有用的那几条，埋在几千万条无人查看的记录里，检索一次要等很久，久而久之大家就不查了。可观测性不是靠量堆出来的，是靠结构堆出来的。

第二个误区是把日志当指标做聚合，前面已经说过，代价是查询成本和结果不稳定。第三个误区是把敏感字段写进日志，代价是合规风险和事后清不干净的长期负担。第四个误区是只加日志不删日志：每遇一次故障就补几条日志，没人复盘这些日志后来有没有被用过，几年下来写入量只增不减。日志和代码一样需要维护，加了不用就应该下线，这不是洁癖，是成本控制的一部分。

第五个误区是以为索引建够了就能查得快。索引能加速的是已经结构化的字段，对自由文本和取值不统一的字段帮助有限，而且索引本身也是成本——建得越多，写入越慢、存储越大。第六个误区是把字段规范当成文档工作，写一份规范发下去就算完成。规范只有落进日志库、写进 CI 校验、在写入侧强制，才算真正生效；停留在文档里的规范，和没有规范的区别只是心理安慰。这六个误区背后是同一个根因：把日志当成写出去就结束的事，而不是当成一份需要设计的数据资产。

落地清单：从下周就能开始的那几步

第一步是做一张字段登记表，把七八个强制字段、每个字段的类型与取值口径、允许的单位和空值约定写清楚，然后封装进统一的日志库。这一步的成果不是文档，而是一个所有新服务默认引入的依赖包——只要引了包，字段就自动带上、类型自动校验。存量服务按故障频次排序逐步接入，先动最常被查的几个。登记表要标明版本，字段变更走版本号而不是直接改，避免新旧数据混在一起无法区分。

第二步是给每条日志流打用途标记：实时排障、审计留痕、业务分析、安全取证、合规留存，五类里选一个，选不出来的就默认不采集。有了标记之后，第三步的留存分级和采样策略才有依据——热层只放热，冷层按合规期限留，采样只对标记为高频成功路径与调试级的流生效，审计、资金、错误事件默认不采。这三步做完，账单上最容易降下来的部分通常就已经降下来了。

第四步是建立日志的退出机制：每半年做一次复盘，把过去一个周期内零查询、或只被某个已下线看板引用的日志流找出来，走停用流程。停用之前先在写入侧关闭一周，观察有没有人来问；没人问就正式下线，有人问就补登记用途标记再恢复。退出机制和写入规范同等重要——只进不出的系统，规模只会单调增长，任何一次性的成本优化都不可能长期有效。

验收标准也不要定得太虚，用三个可检查的指标就够：跨服务按链路 ID 召回一次完整调用的成功率、核心聚合查询的字段缺失率、以及热层数据量占全部日志写入量的比例。第一个指标反映字段规范是否真的落地，第二个反映取值口径是否统一，第三个反映留存分级是否生效。这三个数字按月看趋势，比任何"日志平台建设完成度"之类的说法都更能说明问题，也能在成本上涨时快速定位是哪一环松了。

先把字段定下来，再谈采集多少

回到最初的那个问题：日志量一直在涨、账单一直在涨，排障却还是靠猜，问题到底出在采集量还是字段规范？答案已经很清楚了——绝大多数情况下出在字段规范与留存分级，而不是采得不够多。采集量只是一个放大器：字段规范做得好，采集量增加带来的是能力增加；字段规范没做，采集量增加带来的只是成本增加。所以用采集量的手段去解决字段的问题，方向从一开始就反了，越投入越贵，越贵越不敢动，最后变成谁都不愿意碰的遗留系统。

正确的顺序是：先固定少数关键字段并统一命名与取值口径，让同一个系统内部结构化程度收敛到同一档；再按用途划分留存与检索层级，让热层只承担排障、冷层承担追溯与合规；在这个基础上，才轮到索引设计、查询优化和存储选型。前三步几乎没有硬件投入，主要成本是工程时间和跨团队的口径协商；跳过它们直接做后三步，等于用钱去补偿设计的欠账，而且这笔钱会一直付下去。先把字段定下来，再谈采集多少——这句话听起来像常识，实践中却是最常被跳过的那一步。

一万网络在日志平台建设里能提供的支持

日志平台的底层是实打实的基础设施：热层要的是稳定的随机读写与低延迟检索，冷层要的是大容量、可靠的长期存放与按需回捞，两者对机型、磁盘组合与网络接入的要求并不相同，混在一套配置里做通常两头都不讨好。把热层的检索节点与冷层的归档节点分开规划，按实际写入量与保留周期倒推容量与带宽，再决定自建还是托管、放在哪个区域，这些问题需要与业务增长节奏一起算，而不是拍一个"先上十台"的数字。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。