public sealed class NetworkTelemetryThe metrics endpoint a dedicated server is expected to have.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
It pushes rather than being scraped, and that is the decision this type embodies. A game server is not a web service with a stable address: it is one of a fleet, started and stopped per match, on a port an orchestrator chose, often behind NAT and frequently shorter-lived than a scrape interval. Everything Prometheus's pull model is good at depends on the target being findable and long-lived, and a match server is neither. OTLP to a collector inverts that — the server needs to know one address, and the collector is the thing with a stable name that a Prometheus can then scrape if that is what the organisation runs. This is also the shape a sidecar or a DaemonSet already expects.
It is a wrapper around four lines of SDK setup, and that is deliberate. Its value is not the abstraction — it is that the meter name, the resource attributes and the cardinality decisions are made once, correctly, where they can be reviewed, rather than copied into every server head that ever gets written. A game that wants the SDK directly should use the SDK directly; Vixen.Net's instruments are plain System.Diagnostics.Metrics and need nothing from this package to be read.
Nothing here is on the frame's path. The exporter runs on its own timer and reads what Sample last published, which is why that method exists — see its remarks for why the game pushes rather than the collector pulling.
Fields and properties (1)
public NetworkMetrics MetricsThe instruments. Attach the session and the servers to it, and sample it a tick.
Methods (3)
public static NetworkTelemetry Start(TelemetryOptions? options = null)Starts exporting.
public bool Flush(TimeSpan timeout)Flushes anything not yet exported.
public void Dispose()Stops exporting and closes the meter.
Used by (1)
- NetworkTelemetryTestsVixen.Net.Telemetry.Tests