关于Application Insights Log4Net Appender采样影响与日志可靠性的咨询

核心结论 #

完全可以通过精细化配置实现「WARN及以上级别日志100%可靠送达、INFO/DEBUG级日志按采样策略正常过滤」的目标，不需要因为采样风险回退到原有数据库/文件日志方案。

可落地的实现逻辑 #

• 采样规则的定向排除：Application Insights的采样机制（不管是自适应采样还是固定比例采样）本身支持基于遥测属性的排除逻辑，不需要全局关闭采样。你只需要在采样配置里增加判断规则：把所有严重性为Warning、Error、Critical的Trace遥测（也就是Log4Net Appender采集上来的日志）加入采样排除列表，这部分日志会绕过所有采样环节，100%全量上报。而INFO、DEBUG级别的日志完全可以保留原有采样规则，即使丢失也符合你们的预期。这套配置完全不会影响请求、依赖等自动遥测的原有采样逻辑，不会造成整体遥测量的异常飙升。
• Appender的原生容错能力：官方适配的Log4Net Appender内置了本地异步缓存队列，遇到网络瞬断、上传端点临时不可达的场景时，日志会先暂存在本地队列（支持自定义队列深度参数），等网络恢复后自动重试上传，不会因为短时网络波动直接丢日志，容错水准和你们现在用的数据库/文件Appender的可靠性要求是匹配的。
• 零风险平滑迁移：初期接入阶段，完全可以保留原有的数据库/文件Appender做双写配置，让Log4Net同时向原有可靠存储、Application Insights两个方向写入日志。运行一段时间核对两边WARN及以上级别日志的一致性、送达率达标后，再逐步停掉原有Appender的写入，整个迁移过程不会影响生产排障能力。

容易踩的配置坑 #

• 不要为了保日志可靠性直接全局开100%采样，高并发下的海量INFO级日志会直接打满Application Insights的摄入限额，产生不必要的云成本。
• 配置采样排除规则的时候，一定要限定规则的作用范围是Trace类型的日志，不要把排除逻辑套用到请求、依赖等其他遥测类型上，避免非必要的成本上涨。
• 记得把Log4Net Appender的初始化逻辑放到应用启动链路的最前端，不然应用启动阶段打出的早期ERROR、FATAL日志，会因为Appender还没完成初始化被直接漏掉。

内容的提问来源于stack exchange，提问作者Praveen Nayak