What gets captured, and how
Nafas hooks into ASP.NET Core's own extension points — no code changes required to start capturing logs, traces, and metrics.
Nafas hooks into the same extension points ASP.NET Core and
Microsoft.Extensions.Logging/System.Diagnostics already expose — it
does not require replacing ILogger<T>, wrapping HttpClient, or adding
any [Trace]-style attributes to your code.
| Signal | Source | Notes |
|---|---|---|
| Logs | An ILoggerProvider registered alongside your existing providers | Every ILogger.Log* call in the app, correlated to the active Activity when there is one |
| Traces | A process-wide System.Diagnostics.ActivityListener | Listens to every ActivitySource, including ASP.NET Core's own built-in per-request activity — no manual span creation needed for basic request tracing |
| Metrics | A process-wide System.Diagnostics.Metrics.MeterListener | Listens to every Meter, including ASP.NET Core 8+'s built-in http.server.request.duration, from which request-rate is also derived |
| Resource usage | A native sampler (Process + GC.GetGCMemoryInfo(), with a Windows-API fallback — see Requirements) | CPU and memory usage of the running process, sampled on an interval |
No backpressure on your app
All of it is written through a bounded, non-blocking queue
(System.Threading.Channels) so a burst of telemetry never applies
backpressure to your request pipeline — under sustained overload, Nafas
drops its own data rather than slow your app down.
A dedicated background service drains and batches that queue into storage, and the dashboard's live views (the log stream, in particular) are pushed to the browser over Server-Sent Events at write time — they are not a polling query against the database.