为什么 SkyWalking
官方 .NET Agent 不支持 .NET Framework?
目前(截至 SkyWalking v9.7),官方
skywalking-dotnetAgent 仅支持
.NET Core 3.1+和
.NET 5+,底层依赖
DiagnosticSource和
Activity的现代诊断基础设施。如果你项目还在用
.NET Framework 4.6.1+,直接装 NuGet 包会失败或无任何埋点效果。
可行路径只有两条:
升级到.NET 6/8(推荐,长期维护有保障) 改用手动 SDK 模式(
SkyApm.Agent.AspNetCore已停更,需回退到
SkyApm.DotNetv1.x 或改用社区维护分支)
在 ASP.NET Core 中启用自动埋点的最小配置
以
.NET 6+
SkyAPM.Agent.AspNetCore(v2.4.0)为例,自动捕获 HTTP 请求、DB 查询、HttpClient 调用的关键是正确初始化和配置环境变量。
必须设置的环境变量(非代码内硬编码):
ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=SkyAPM.Agent.AspNetCore
SKYWALKING__SERVICENAME=your-service-name
SKYWALKING__COLLECTOR__BACKENDGRPC__HOST=127.0.0.1
SKYWALKING__COLLECTOR__BACKENDGRPC__PORT=11800
注意:
SKYWALKING__前缀不能省略,且大小写敏感;
BACKENDGRPC是默认传输协议,若服务端启用了
oap-server的 HTTP 接收器,需换用
BACKENDHTTP配置项。
DiagnosticListener
和 Activity
是埋点核心,但别手动订阅
有人尝试用
DiagnosticListener.AllListeners.Subscribe(...)自己解析
Microsoft.AspNetCore或
SqlClient的事件,这不仅重复造轮子,还极易漏掉上下文传播逻辑(比如 TraceId 跨线程丢失)。官方 Agent 已封装好所有关键监听器:
Microsoft.AspNetCore.Hosting.HttpRequestIn→ HTTP 入口
Microsoft.Data.SqlClient.WriteCommandBefore→ SQL 执行前
System.Net.Http.HttpRequestOut→ HttpClient 出站调用
只要 Agent 加载成功且环境变量正确,这些监听器就自动生效;手动干预反而可能破坏
Activity.Current?.Context.TraceId的链路一致性。
自定义 Span 必须用 TracingContext.Instance.NewEntrySpan()
对非 HTTP/DB/HTTPClient 的逻辑(如消息队列消费、定时任务、内部计算),需要显式创建 Span。不要用
new Span(...)或直接操作
Activity,否则无法被 Collector 正确识别。
正确写法示例:
using SkyApm.Tracing;
<p>var span = TracingContext.Instance.NewEntrySpan("process-order", "/order/process");
try
{
span.Tag("order.id", orderId);
// your logic
}
catch (Exception ex)
{
span.Error(ex);
throw;
}
finally
{
span.End();
}重点:必须调用
span.End(),否则 Span 不会上报;
NewEntrySpan会自动继承上游 Context,无需手动传 TraceId。
最容易被忽略的是跨线程场景:比如
Task.Run(() => { /* 埋点代码 */ }) 中的 Span 不会自动延续。此时需显式使用 TracingContext.Instance.Continued(...)或改用
AsyncLocal<activity></activity>安全的异步上下文传递方式——这点在 Kafka 消费者或 Hangfire 任务里特别容易出错。
