SkyAPM-dotnet: Auto-Instrumentation for ASP.NET Core

SkyAPM-dotnet Targets Instrumented .NET Services

SkyAPM-dotnet addresses teams that want application telemetry from C# services without adding tracing calls throughout application code. It is an agent for the .NET ecosystem, with the README specifically naming ASP.NET Core and other .NET applications. Its outputs are distributed tracing data, application topology, and metrics, all sent to an Apache SkyWalking backend.

The intended architecture places SkyWalking at the center of the observability system. The agent instruments the .NET process, collects telemetry, and reports it over the sw8 protocol, also identified as v8 in the README. This makes the project a client-side component rather than a complete tracing storage system or user interface. Teams using it still need an Apache SkyWalking backend capable of accepting the reported data.

The project is community-maintained and independent. Its README explicitly states that it is not affiliated with or endorsed by the Apache Software Foundation. That distinction matters when an organization builds an adoption record: backend support belongs to Apache SkyWalking, while agent behavior, supported components, configuration, and troubleshooting belong to this repository and its linked documentation.

The scope is narrower than a universal .NET observability library. The quick start explicitly lists net8.0 and net10.0 as supported runtimes. The repository also includes samples for ASP.NET Core, generic hosts, logging, FreeSql, SmartSql, a backend, a frontend, and gRPC, but the README does not describe every sample's instrumentation behavior. These files indicate areas represented in the repository, not a blanket promise of production compatibility.

Two NuGet Packages Cover Web and Generic Hosts

The repository publishes two NuGet packages, each tied to a different .NET hosting model. `SkyAPM.Agent.AspNetCore` is intended for an ASP.NET Core application, while `SkyAPM.Agent.GeneralHost` serves applications using the general host model. The README links each package to its NuGet page and statistics page, but it does not provide a package matrix in this section. The linked configuration and getting-started documentation is identified as the place for supported components and complete installation details.

This packaging choice matters because .NET instrumentation is activated through the hosting environment, not through a conventional application entry-point edit in the quick start. For ASP.NET Core, the example adds the package, sets `ASPNETCORE_HOSTINGSTARTUPASSEMBLIES`, assigns a service name, and starts the application. The hosting startup assembly mechanism allows the agent to load as part of ASP.NET Core startup.

The repository's default branch is `main`, and its source is primarily C#. Its solution includes separate source, test, sample, build, documentation, and benchmark directories. That layout is consistent with a reusable agent plus component integration work, although the README does not enumerate the plugins currently built into a release.

For production decisions, the package list alone is not enough to establish coverage. The README points to a supported-component list and plugin documentation on the project site. An engineer should use those pages to confirm the exact frameworks, clients, database libraries, and hosting components involved in a service. The repository description mentions ASP.NET Core and .NET applications, but it does not state that every .NET library is instrumented.

ASP.NET Core Quick Start and Expected Activation

The documented quick start is appropriate for a first local run of an ASP.NET Core application on a supported runtime. It installs the web-host package, exposes the agent through a hosting startup assembly environment variable, assigns the service the name `my_service`, and launches the application. The service name gives SkyWalking a stable identifier in the backend instead of leaving the telemetry destination unnamed.

Use the following sequence in a shell environment where the application and SkyWalking backend are already available:

dotnet add package SkyApm.Agent.AspNetCore
export ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=SkyApm.Agent.AspNetCore
export SKYWALKING__SERVICENAME=my_service
dotnet run

The first command adds the ASP.NET Core agent package to the project. The next two commands prepare agent activation for the current shell and set the telemetry service name. The final command starts the application. According to the README, this is the supported quick-start path for `net8.0` and `net10.0`.

A successful launch alone does not prove that data reached SkyWalking. The README does not define a diagnostic command, health endpoint, expected console message, or validation procedure for this quick start. It directs readers to the full Getting Started guide and troubleshooting documentation instead. For the first real check, consult that documentation for backend connectivity and inspect the resulting service in the configured SkyWalking environment.

The spelling of the package in the install command is `SkyApm.Agent.AspNetCore`, while the NuGet table displays `SkyAPM.Agent.AspNetCore`. This difference in capitalization appears in the README and should be preserved when copying the documented command.

sw8 Transport Connects the Agent to SkyWalking

The central data flow is agent instrumentation inside the .NET process, telemetry generation for distributed traces, application topology, and metrics, then transmission to an Apache SkyWalking backend over sw8, also called v8. This transport boundary separates the agent from the backend's storage, querying, and visualization responsibilities. The agent produces and sends telemetry, but it is not the backend that receives, retains, or presents the data.

The project documentation identifies gRPC and Kafka as transport subjects. The repository includes a `sample/grpc` directory, which supports the presence of a gRPC-oriented example, but the README does not give a Kafka configuration example or state which transport the quick start selects by default. It would therefore be incorrect to infer a default transport from the directory names or from the existence of both documented transport options.

Configuration is referenced through `SKYWALKING__SERVICENAME` in the quick start. The README links to a configuration reference for every option, but does not reproduce backend address, authentication, sampling, logging, or transport settings here. Those values are necessary for a complete deployment and are not safe to invent. The exact names and accepted values should come from the project's configuration reference.

Distributed context propagation is especially relevant for an agent-based system. The README confirms support for the sw8/v8 protocol, which is the basis for carrying trace context between instrumented components. It does not describe propagation for any individual plugin, so engineers should confirm coverage for their outbound HTTP calls, messaging systems, and supported client libraries rather than assume that all traffic will appear in one continuous trace.

Runtime and Component Coverage Constrain Adoption

The clearest limitation is the runtime boundary stated in the quick start: supported runtimes are `net8.0` and `net10.0`. The repository is described broadly as an agent for the .NET ecosystem, but the README does not claim support for older runtime targets such as net6.0 or net7.0. A service on an unlisted version should not be assumed to load or report correctly.

Component coverage is the second constraint. The README names ASP.NET Core and .NET applications as target categories and points to a supported-component list. It does not enumerate every instrumented framework or package in the repository root. Samples involving FreeSql, SmartSql, gRPC, logging, and generic hosting show that the repository has integration examples, but examples alone do not establish production support for every version or configuration of those technologies.

The activation model can also be a deployment concern. The quick start uses shell-level environment variables and a hosting startup assembly. Windows environments, container images, service managers, orchestrators, and CI runners may require different ways to inject those values, but the README does not document each deployment method. The linked installation and activation documentation is the correct source for those cases.

Finally, the project is an agent, so application startup and telemetry transport add an operational dependency. The README does not define behavior when the SkyWalking backend is unavailable, how much telemetry is buffered, or what happens under agent failure. It also does not document rollback. Those cases must be checked in the full documentation and the selected hosting configuration before the agent becomes mandatory in production.

Apache SkyWalking Versus Manual .NET Tracing

Apache SkyWalking is the telemetry backend named for this project, not a direct substitute for the agent. SkyAPM-dotnet handles instrumentation and telemetry submission. The README gives this division through its backend links and explicitly directs protocol, backend, or UI questions to the Apache SkyWalking project.

A real alternative is manual tracing in application code. Manual instrumentation gives the developer direct control over span creation, span attributes, transaction boundaries, and error recording. It does not require an auto-instrumentation agent, but every relevant call path must be updated consistently. That approach can fit codebases with highly customized telemetry semantics or where the deployment cannot load a hosting startup assembly.

SkyAPM-dotnet takes a different approach. Its value is coverage through agent integration with supported components, combined with SkyWalking topology and metrics. Its cost is dependence on runtime support, plugin compatibility, activation, configuration, and the availability of a compatible SkyWalking deployment. Manual tracing has its own cost: application changes and ongoing coordination whenever spans, endpoints, or dependency paths change.

Another backend option could be selected only if it supports the required SkyWalking protocol and telemetry model, but the README does not document such compatibility. It is therefore safer to compare SkyAPM-dotnet with SkyWalking against manual.NET tracing than to claim support for an unlisted observability backend.

Release Cadence, Apache-2.0, and Upgrade Work

The repository is not archived. Its last push was on 2026-08-01, and the release list includes `v2.3.0` dated 2026-06-28, `v2.3.0-rc1` dated 2026-06-28, and `v2.2.0` dated 2024-03-31. These dates show recent project activity and a substantial gap between the two stable releases shown. They do not establish a fixed support window for any .NET version.

The project uses the Apache-2.0 license. That permits use and modification under the license's stated conditions, while notices and license obligations remain part of distribution and compliance work. This review does not interpret legal requirements or provide legal advice. Repository consumers should review `LICENSE` and account for it when packaging the agent, distributing associated binaries, or embedding it in an application image.

An upgrade affects more than the package version. Because the agent participates in hosting startup and telemetry transmission, adoption should include checks for runtime support, changed configuration keys, supported-component changes, SkyWalking backend protocol compatibility, and differences in logging or troubleshooting behavior. The README does not provide an upgrade compatibility matrix, so the safest evidence would come from `CHANGELOG.md`, the release notes, and the linked configuration documentation.

The last push date is the available maintenance indicator. It does not answer how quickly individual issues are handled, whether a particular plugin receives fixes, or whether a new backend version remains compatible. Those questions require project-specific issue and release inspection rather than an inference from repository activity alone.

Editorial conclusion

Adopt SkyAPM-dotnet when a .NET service must report distributed traces, topology, and metrics to Apache SkyWalking and the deployment uses net8.0 or net10.0. Do not select it for an unlisted runtime or when SkyWalking is not acceptable as the telemetry destination. Verify the component support list, selected transport, configuration, and deployment activation method before rollout, especially in containers and generic hosts.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. SkyAPM/SkyAPM-dotnet on GitHub