Start here

Vight SDK Quickstart

Install the SDK for your runtime, set the shared Vight environment variables, and send OpenTelemetry traces, runtime metrics, and logs to Vight.

Vight SDKAPMLogs

How SDK setup works

Every Vight SDK does the same three jobs: it gives the service a stable identity, starts OpenTelemetry collection before work is handled, and sends traces, runtime signals, and logs to the Vight project identified by your ingestion key.

Choose the runtime adapter that matches where the service receives traffic. Framework adapters add request-specific context, while the shared environment variables keep service names, environments, versions, and deployments consistent across every Vight page.

Choose your runtime

.NET / ASP.NET Core

Vight.AspNetCore

Deepest runtime surface today. Adds ASP.NET Core, HTTP client, runtime metrics, and Vight resource attributes.

Node.js

@vight/node

General Node services. Preload the SDK or start it programmatically before your app handles traffic.

Next.js

@vight/nextjs

App Router instrumentation through Next's instrumentation hook and @vercel/otel.

Hono

@vight/hono

Request span middleware for Hono apps running on Node.js.

Shared setup

Use the same setup sequence for every runtime. The package changes by framework, but identity, routing, and validation should stay consistent.

  1. 1

    Create or open the Vight project that should receive telemetry for the service.

  2. 2

    Copy a project ingestion key from Settings and store it in the deployment environment.

  3. 3

    Set the shared service identity variables before the application process starts.

  4. 4

    Install the SDK package for the runtime or framework that handles requests.

  5. 5

    Deploy, generate fresh traffic, and confirm the service appears in Services, Traces, Runtime, and Logs.

.env
VIGHT_SERVICE_NAME=checkout-api
VIGHT_ENVIRONMENT=production
VIGHT_SERVICE_VERSION=1.0.0
VIGHT_DEPLOYMENT_ID=deploy_2026_06_24
VIGHT_INGESTION_KEY=...
VIGHT_OTLP_ENDPOINT=https://ingest.vight.dev

What Vight captures

Traces
Inbound requests, outbound calls, database spans, errors, routes, and status codes. Use traces when you need request-level proof.
Runtime signals
Process and runtime measurements such as CPU, memory, garbage collection, event loop, thread activity, and framework metrics when the runtime exposes them.
Logs
Application events enriched with service, environment, trace, span, version, and deployment context for correlation.

Validation

A setup is not complete when the package installs. It is complete when a new request appears under the expected service and environment, opens as a trace, and has related logs or runtime context when those signals are enabled.