Why Nafas

Standing up observability for a small or medium ASP.NET Core service usually means an OTel Collector, a time-series database, and a separate dashboard to run and secure — real infrastructure for a problem that's often just "let me see recent errors and know when something breaks."

Nafas is the alternative for that case: it lives inside your application's own process, stores data in a local SQLite file (or your existing SQL Server) by default, and needs nothing external to run.

What it doesn't try to be

It is not a replacement for a full OTel/Prometheus/Grafana stack at scale:

• it does not federate across services
• it does not do long-term, high-cardinality storage
• it does not export to other backends

What it's for

The case where a single self-hosted app — or a handful of them sharing a database — needs real logs, metrics, traces, and threshold-based alerting without introducing new infrastructure to operate. If that's you, see the Quick start.