接口耗时指标如果按订单号、用户 ID 或完整 URL 分组，会产生大量不同的时间序列。字段看起来有助于排查，却可能让指标存储和查询难以承受。指标与日志应承担不同职责。
先看标签值能增长到多大
服务名、操作类型通常有受控范围，订单号则会随业务不断增加。还要考虑多个标签组合后的规模，不只是每个标签单独有多少值。一次评审就应讨论字段的增长边界。
指标表达总体状态
错误率、耗时和队列规模适合用指标观察；单笔订单细节更适合受控日志或链路。需要从指标进入具体证据时，可以利用工具支持的关联机制，而不是把所有业务标识都加入标签。
对路径和错误做有限分类
动态资源 ID 应与路由模板区分，异常消息也不宜直接作为无限变化的标签。分类规则需要保留业务解释能力，不能把所有错误合并成一个值后失去分析意义。
验收增长与查询成本
在代表性流量下统计时间序列数量、数据量和查询响应，确认新增字段没有造成异常增长。监控配置变更也应评审，不把它当成没有运行成本的附属代码。
常见问题：日志里就可以无限记录业务 ID 吗？
也需要考虑隐私、访问和保留成本，只是其存储与查询模型不同，不能因此忽略治理。
技术参考：OpenTelemetry：指标。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。