Serilog LogEntries sink已弃用 生产环境替代方案咨询

Serilog.Sinks.LogEntries 已被官方正式归档弃用，后续不再提供功能迭代、安全补丁和问题修复，生产环境持续使用存在运行时兼容性、安全合规两类潜在风险。针对多应用存量使用的场景，按改造成本从低到高给出可直接落地的处理路径：

• 短期兜底方案（零业务代码改动，1-2个工作日可完成全集群覆盖）
  这个sink的核心逻辑非常简单，就是通过TCP/TLS通道把结构化日志批量发送到对应日志平台的接入端点，代码本身已经稳定运行多年，如果你当前部署的版本在现有运行时环境下没有抛出异常、日志投递正常，完全不需要第一时间强行下线改造。优先做三个兜底动作即可：
  1. 把当前生产环境使用的对应版本sink源码拉取到企业内部代码仓库做私有归档，同时在内部NuGet源锁定该包版本，禁止后续CI/CD流程自动拉取第三方上传的同名未知包
  2. 在现有Serilog日志管道的最末端追加本地文件sink作为降级兜底，一旦LogEntries端点发送失败，所有日志全量落本地磁盘，从机制上避免日志断流
  3. 针对日志投递失败事件埋点告警，配置投递失败率超过1%即触发运维响应，第一时间感知连接异常
• 中期平滑迁移方案（单应用改造成本<1人日，无业务侵入）
  等兜底措施落地后，再逐步替换成持续维护的兼容组件，全程不需要改动业务侧的日志调用代码，也不需要调整日志平台侧的解析规则：
  1. 替换包引用：卸载已弃用的Serilog.Sinks.LogEntries包，替换为社区活跃维护、投递协议完全兼容的替代sink，配置参数和原有写法基本对齐，仅需要调整应用启动阶段的sink注册代码
  2. 灰度切流验证：先在10%流量的应用节点上启用新sink，对比新旧链路的日志投递延迟、字段完整性、丢包率，连续72小时无异常再逐步推全
  3. 配置对齐：迁移过程中保持原有的日志接入令牌、结构化输出模板、批量发送窗口、TLS版本配置和旧环境完全一致，避免日志平台侧出现字段解析失败、日志断流问题
• 长期架构优化方案（彻底解耦日志投递与业务逻辑）
  如果后续有统一可观测体系的建设规划，建议从架构层面彻底解决单厂商sink绑定的问题：
  1. 应用侧只保留标准控制台输出sink，所有结构化日志直接输出到标准输出，由部署在节点上的日志采集Agent负责日志的批量缓存、重试、加密、多目的地投递，业务应用完全不需要感知后端日志平台的对接逻辑
  2. 后续不管是切换日志服务商、新增本地日志存储、新增日志字段脱敏规则，都只需要调整采集Agent的配置，不需要逐个业务应用修改代码、重新发布版本

避坑提醒：不建议直接fork原归档仓库自行长期维护。日志sink涉及TLS连接管理、失败重试、内存队列管控等逻辑，后续.NET版本迭代、TLS协议升级、日志平台接口变更都需要持续投入人力适配，长期维护成本远高于替换为活跃维护的社区组件，或是切换到Agent采集架构。

内容的提问来源于stack exchange，提问作者Mike Wasson