OpenTelemetry .NET 中 Npgsql 导致的内存泄漏问题分析

问题概述

在使用 OpenTelemetry .NET 库监控 ASP.NET Core Web API 应用时，发现了一个严重的内存泄漏问题。当应用运行一段时间后，内存消耗会持续增长，最终导致 Pod 因达到内存限制而被重启。

现象描述

在开发环境中，应用流量稳定在每秒4个请求左右（主要是健康检查请求），但内存使用量却呈现以下增长趋势：

• 初始内存：375MB
• 6小时后：506MB（增长35%）
• 16小时后：710MB（触发重启）

通过对比两个时间点的 GC 内存转储（gcdump），发现以下对象数量显著增加：

• Activity 对象：增加了106,078个
• DiagNode<KeyValuePair<String, Object>> 对象：增加了1,060,780个

技术分析

问题根源

经过排查，发现问题出在 OpenTelemetry 的 Npgsql 数据源配置上。在 Tracing 配置中，开发者添加了以下代码：

builder.AddSource("Npgsql")

当移除这行配置后，内存增长问题立即消失，应用内存使用变得稳定。

深层原因

Npgsql 是 .NET 的 PostgreSQL 数据库驱动。当通过 AddSource("Npgsql") 启用其 OpenTelemetry 支持时，系统会开始跟踪所有 Npgsql 相关的活动（Activity）。问题可能源于以下方面：

1. 活动未正确结束：Npgsql 可能创建了活动但没有正确调用 Dispose 或结束它们
2. 活动引用链：未结束的活动可能持有其他对象的引用，阻止GC回收
3. 诊断节点累积：DiagNode 对象的大量增加表明诊断信息未被清理

解决方案

临时解决方案

立即移除 AddSource("Npgsql") 配置可以解决内存泄漏问题，但这会失去对 PostgreSQL 操作的监控能力。

长期解决方案

1. 升级 Npgsql 驱动：检查是否有新版本修复了此问题
2. 限制活动收集：可以配置采样策略，减少收集的活动数量
3. 定期重启：在问题彻底解决前，可以设置更频繁的重启策略

最佳实践建议

1. 谨慎添加数据源：只添加真正需要监控的数据源
2. 监控内存变化：在生产环境部署前进行长时间的内存测试
3. 使用最新稳定版：保持 OpenTelemetry 和相关库的最新版本
4. 定期检查GC行为：通过内存分析工具定期检查应用的内存使用模式

总结

这个问题展示了在使用分布式追踪系统时可能出现的一个典型陷阱。虽然 OpenTelemetry 提供了强大的监控能力，但不正确的配置或底层库的问题可能导致严重的资源泄漏。开发者在使用时应充分测试内存行为，特别是在添加新的监控源时。对于 Npgsql 的特定问题，建议关注其官方仓库的更新，以获取永久性修复方案。