Skip to main content

Server Telemetry

Client-side numbers tell you what users experience under load; server telemetry tells you why. Install the TestVibe agent in the application you are testing and your results gain live server-side CPU, memory, session, and custom metrics — rendered next to the client-side charts.

The metrics appear in two places:

  • Load test results — server vitals next to the client-side charts.
  • Analytics → Telemetry → Live — the same vitals streaming in real time while you watch.

The agent increases metric reporting while a load run is active or someone is watching live telemetry. It still polls for activity while idle, and error reporting continues independently. Reporting is best-effort; assess its overhead in your application.

What you'll need​

  1. A TestVibe API key (tvb_…, workspace-scoped) — TestVibe → Settings → CLI & API keys. See API keys. The agent discovers your projects from the key.
  2. The agent for your stack (below). The .NET agent is the TestVibe.Telemetry NuGet package; it discovers your projects from the API key, so you don't even need a project id.

.NET​

Install the package:

dotnet add package TestVibe.Telemetry

It targets netstandard2.0, so it runs on .NET Framework 4.6.1+, .NET Core 2.0+, and .NET 5–10+. Register it once at startup. The optional SessionCount callback unlocks Sessions and Memory / session; wire it to whatever represents an active session in your app.

// Program.cs
using TestVibe;

var builder = WebApplication.CreateBuilder(args);
// ... services ...
var app = builder.Build();

Telemetry.Register(
    builder.Configuration["TestVibe:Server"] ?? "https://testvibe.app",
    builder.Configuration["TestVibe:ApiKey"], // tvb_… from Settings → CLI & API keys
    new TelemetryOptions
    {
        // Optional: report a live count (e.g. active SignalR connections or signed-in users).
        SessionCount = () => MyConnectionCounter.Current,
    });

app.Run();

Custom metrics, info & errors​

Anywhere in your app:

// Gauges — chart alongside CPU/memory (latest value wins, up to 20 metrics).
TestVibe.Telemetry.ReportMetric("Orders/min", ordersPerMinute);

// Static facts shown in the server card header.
TestVibe.Telemetry.ReportInfo("Region", "westeurope");

// Errors — grouped + persisted under Analytics → Telemetry → Errors & exceptions.
// Unhandled exceptions are captured automatically; report handled ones too:
try { DoWork(); }
catch (Exception ex) { TestVibe.Telemetry.ReportError(ex); throw; }

Node.js​

Node services use the testvibe-telemetry npm package (Node 18+, zero dependencies):

npm install testvibe-telemetry

Start it once at boot:

const { startTestVibeLoadAgent } = require('testvibe-telemetry');

const telemetry = startTestVibeLoadAgent({
  server: 'https://testvibe.app',
  apiKey: 'tvb_…',               // Settings → CLI & API keys
  project: '<your-project-id>',  // Analytics → Telemetry → Set up telemetry
  sessions: () => myActiveSessions, // optional
});

Uncaught exceptions are captured automatically; report handled errors with telemetry.reportError(err).

No npm? Copy the single-file agent shown in Analytics → Telemetry → Set up telemetry (testvibe-load-agent.js — the same file the package installs) into your app and require './testvibe-load-agent' instead.

Reading server metrics​

  • CPU climbing toward saturation while latency p95 rises is the classic capacity ceiling — scale up or optimize before raising thresholds.
  • Memory growing run-over-run without recovering suggests a leak the load test is exposing; Memory / session isolates whether it's per-session.
  • Sessions confirms the load actually produced the concurrency you configured.