Skip to main content
The SDK exposes one ActivitySource and one Meter, both named Westyx.Nexus. The name is a constant, so nothing has to be spelled out twice:
That is the whole integration. NexusDiagnostics lives in Westyx.Nexus and ships in the core package, so no extra reference is needed.

​
Spans

The three cover every network call the SDK makes on its own. A read from the cache raises nothing - it does no I/O.

​
Instruments

not_modified is a 304: the data was unchanged and the TTL was reset without a download. It is a success, and separating it from ok is what makes the ratio of the two readable as how often your configuration actually changes.

​
Why they exist, and what they cost

Both are inert until something subscribes. An ActivitySource with no listener returns null from StartActivity, and an instrument nobody observes does no work - so an application that wants neither pays for neither, and there is no configuration flag to turn them off. They exist because the SDK makes network calls on a background loop, which is the shape an operator cannot diagnose from outside. A sync that has been failing for an hour is invisible while the cache keeps serving: the application answers every request correctly, from data that is an hour old. westyx.nexus.syncs{outcome=failed} is the signal that says so, and it is the one worth alerting on.

​
There is no cache-age gauge

An observable gauge belongs to the meter rather than to a client, so one gauge per client instance would register a duplicate instrument for every client an application creates. The age is:
Publish it under your own name, with the lifetime you actually have. An application with one client - the normal case - can register it once at startup.

​
Correlating with your own traces

The spans are ordinary activities, so they nest under whatever ambient activity is current. On the dependency-injection path the initial sync runs during host startup, outside any request, and every later sync runs on the background loop - so those appear as roots. A sync you trigger yourself with await client.SyncAsync() nests under the request that called it, which is usually what you want when you are chasing a specific read.