B2B 电子商务网站有着独特的可观测性特征。与面向消费者的店面相比，其流量很低，每天往往只有几百次会话，甚至更少。但每一次请求都事关重大：一份无法加载的报价、一次悄然出错的结账、一个短暂显示错误的价格。客户是与你有合作关系的已知企业，"我这边坏了"会通过他们的应收账款联系人反馈过来，而不是化作一条匿名评价。
这种组合改变了可观测性需要承担的任务。以下是我们在 B2B 电子商务项目上实际采用的方案，涵盖从"IIS 上的小型 ASP.NET Core 部署"到"多区域托管的 Sana Commerce"的各种场景。
你真正需要的三样东西
- 可检索的结构化日志。当客户报告问题时，你需要在几秒内找到与其会话相关的每一行日志，而不是去逐行翻看文件。
- 跨集成边界的分布式追踪。大多数 B2B 电子商务错误都出现在店面与 ERP 之间的衔接处。一条同时贯穿两端的追踪，决定了你是能直接得到答案，还是要经历一场漫长的调试。
- 销售运营团队能看懂的仪表盘。不只是给工程师看的。当运营副总裁问"我们这周是不是在流失订单"时，答案不应该需要一位工程师才能给出。
我们在 ASP.NET Core 项目上实际采用的方案
日志：带结构化属性的 Serilog
通过 Microsoft.Extensions.Logging 使用默认的 ILogger 并无不妥，但 Serilog 能以更少的繁琐为你带来更优的结构化日志。我们采用的配置如下：
- 控制台 sink（开发时在 Kestrel 终端中可见，生产环境中在 IIS stdout 中可见）
- App_Data/logs 中的滚动文件 sink（带保留策略，本地通常保留 14 天，并由一个作业将较旧的文件推送至持久存储）
- 针对 ClientIP、UserAgent、RequestId 以及（在已认证时）企业账户标识符的扩充器
那个不太显眼但很关键的扩充器是：客户/公司 ID。当你在排查"为什么 Acme Manufacturing 的结账坏了"时，你想直接根据他们的 ID 来检索，而不是先去查找你还得反查的会话 ID。
追踪：OpenTelemetry
在 2026 年，OpenTelemetry 是分布式追踪的正确答案。ASP.NET Core 对 OTel 提供一流的支持；配置只需几个 AddOpenTelemetry() 调用，再加上一个导出器（我们通常先用 OTLP 发送到收集器，再根据客户已有的环境转发至 Honeycomb / Jaeger / Application Insights 等）。
高价值的 span 包括：
- HTTP 服务器（每一次请求）
- 对 BuiltWith、AI 提供方、ERP、电子邮件服务发起的 HttpClient 调用
- SQLite / SQL Server 查询 span
- 围绕业务关键工作的自定义 span，例如“为客户 X 的 SKU Y 计算价格”、“将客户 N 同步到 ERP”
健康检查
ASP.NET Core 提供了一套简洁的健康检查 API。我们通过 /healthz 暴露以下检查项：文件系统写入权限（App_Data 可写）、SMTP 可达性，以及最重要的，店面所依赖的 ERP 连接或供应商 API。
部署流水线在每次部署后会带重试地轮询 /healthz；如果上线后状态仍处于降级，流水线会高调地报错失败。
真正重要的仪表盘
仪表盘的合理数量应当很少。我们通常构建三个：
- "网站现在正常吗？"一个单屏视图：HTTP 错误率（最近一小时）、p99 延迟、ERP 同步错误数、最后一次成功同步的时间戳。每 30 秒刷新一次。挂在办公室的墙上，或固定在某个 Slack 频道里。
- "订单在顺畅流转吗？"按渠道统计的每小时下单数量与金额。销售运营关心这个，应收账款也关心，发布月里 CEO 同样关心。
- "调查：客户名称"一个参数化仪表盘，输入客户 ID 即可打开。它会呈现该客户的用户在过去 30 天内的每一项操作、触及其账户的每一个错误、涉及其记录的每一次 ERP 同步。这正是当客户说“昨天出了点状况”时，你第一时间就会希望自己早已备好的仪表盘。
不会引发告警疲劳的告警
对于流量较低的 B2B 网站，逐错误告警会不断触发，因为单个错误在统计上看起来都很显著。我们转而针对以下模式进行调优：
- 10 分钟内持续的 HTTP 5xx 比率 > 2%（而非单次请求）
- 任何持续 > 1 分钟的失败健康检查
- ERP 同步在 > 30 分钟内未能成功（无声的杀手）
- 在本应有订单的时段内，> 30 分钟没有任何订单成功通过，以 30 天基线作为衡量标准
其余一切：记录下来、放进仪表盘，但不要为它告警。
那 Application Insights / Datadog 等怎么办？
用客户已经在用的就好。如果他们重度依赖 Azure，Application Insights 很出色。如果他们是多云架构，Datadog 很出色。Honeycomb 在追踪方面表现优异。平台本身没那么重要，重要的是认定一个并在其中保持日志/追踪的相互关联。最糟糕的模式是"日志在 IIS、追踪在 App Insights、错误在 Sentry、SQL 查询哪里都没有"，为排查一个 bug 你得在三个工具之间来回切换。
要点
B2B 可观测性并不光鲜，却极具撬动效应。实际工作量很小：几个小时配置 Serilog，再花几个小时配置 OTel，用一天做客户调查仪表盘。其回报，便是“客户昨天打来反映出了问题，而我们不知道发生了什么”与“这是追踪、这是原因、修复今天就上线”之间的天壤之别。
如果你的 B2B 平台已在生产环境运行，而你的调试手段还停留在“翻看 IIS 日志”，联系我们。我们会在第一周就把仪表盘搭好。