OpenTelemetry .NET 不自动捕获文件操作，因 FileStream 等不触发 DiagnosticSource；需手动创建 Activity 并显式传播 ParentId，避免孤立 trace，按语义粒度（非每块读取）创建 span，慎用细粒度埋点。
OpenTelemetry 在 C# 文件操作中不自动捕获 FileStream 或 File.Read 调用
OpenTelemetry .NET SDK 默认不会对 System.IO 中的底层文件操作做自动插桩——哪怕你启用了 AspNetCoreInstrumentation 或 HttpClientInstrumentation，File.Copy、new FileStream()、StreamReader.ReadToEnd() 这些调用依然静默无痕。
根本原因在于：.NET 的 IO 类型（如 FileStream）不走 DiagnosticSource 事件管道，而 OpenTelemetry 的自动埋点全依赖它。没有事件，就没有 span。
- 别指望
AddAspNetCoreInstrumentation()或AddOtlpExporter()单独启用就能看到文件读写 span - 第三方库如
OpenTelemetry.Instrumentation.SqlClient那套“开箱即用”逻辑，在文件 IO 上完全不适用 - 若你在分布式 trace 中看到某个服务耗时很长但 span 里只有 HTTP 和 DB，大概率就是文件 IO 漏掉了
手动创建 Activity 包裹关键文件操作是最可靠的方式
你需要显式开启、命名、标注并结束 span，尤其在跨服务场景下，必须继承上游 trace context（比如从 HTTP header 解析 traceparent），否则文件操作会变成孤立 trace。
示例：读取上传的配置文件并触发下游服务调用
using var activity = source.StartActivity("File.Read.Config", ActivityKind.Internal);
activity?.SetTag("file.path", "/app/config/tenant.json");
activity?.SetTag("file.size.bytes", fileInfo.Length);
<p>// 手动传播 context（如果上游有）
if (Activity.Current?.ParentId is not null)
{
activity?.ParentId = Activity.Current.ParentId;
}</p><p>var content = await File.ReadAllTextAsync(path); // 实际 IO</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill2795" title="C#"><img
src="https://img.php.cn/upload/skill/000/000/081/178936933912641.jpg" alt="C#" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill2795" title="C#">C#</a>
<p>"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"</p>
</div>
<a href="/xiazai/skill2795" title="C#" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><p>activity?.Stop();-
ActivityKind.Internal是最常用选择；避免用Client或Server，文件 IO 不是网络请求 - 务必调用
activity?.Stop()，否则 span 不会上报；using语句仅保证 dispose，不等于 stop - 不要依赖
Activity.Current自动继承——.NET 的异步执行流可能切断 context，显式设ParentId更稳
跨服务时，FileStream 本身不携带 trace context，需靠业务层透传
假设服务 A 把文件路径发给服务 B 处理，B 打开 FileStream 时，Activity.Current 是空的——因为消息队列、HTTP body、gRPC payload 都不会自动注入 trace context 到文件系统调用中。
你必须在协议层做两件事：一是在发送方把当前 trace id 注入 payload；二是在接收方用它重建 Activity。
- HTTP 场景：用
W3CBaggagePropagator+TraceContextPropagator从HttpRequest.Headers提取traceparent，再调用ActivitySource.StartActivity(..., parentId: ...) - 消息队列（如 RabbitMQ/Kafka）：把
traceparent写进 message headers，而非 body；消费者解析后调用Activity.SetParentId() - 切忌把 trace id 塞进文件名或文件内容里——这属于污染数据，且无法被 OpenTelemetry 自动识别
性能敏感路径慎用高频率 Activity 创建（如逐块读大文件）
每次 StartActivity 都涉及时间戳采集、ID 生成、字典分配等开销。对单次 GB 级文件读取，1 个 span 足够；但若你在 while (stream.Read(buffer) > 0) 循环里每块都起 span，trace 数据量会爆炸，还拖慢吞吐。
- 建议按语义粒度建 span：一次
File.Copy、一次ZipArchive.ExtractToDirectory、一次完整XmlSerializer.Deserialize各一个 span - 如需观测内部细节（比如某次 read block 特别慢），改用
Activity.AddEvent()记录关键点，而非新建 span - 生产环境可加开关：只在
IsDiagnosticMode为 true 时启用细粒度文件 span，避免常驻开销
真正难的不是怎么加 trace，而是判断哪些文件操作值得 trace——临时缓存文件、日志轮转、临时解压目录，往往比主业务文件更易出问题，却最容易被忽略。
