Concepts & Reference
Advanced SDK Configuration
Use advanced SDK configuration when the default setup works but you need cleaner service identity, less noise, or better release context.
Concept
Use advanced SDK configuration when the default setup works but you need cleaner service identity, less noise, or better release context.
The quickstart is enough for first telemetry, but production setup usually needs stable identity and filtering.
Advanced configuration should make investigations clearer, not hide important evidence.
Keep SDK options aligned across traces, logs, runtime metrics, releases, and environments.
Examples
- Route exclusions
- Exclude health checks only after confirming user-facing routes still produce traces.
- Log capture
- Capture request logs in the same service context so trace detail can show related events.
- Release metadata
- Set version and deployment values during release so incidents can be compared before and after deploys.
How Vight uses it
Set service name, environment, version, and deployment before application code handles traffic. Exclude health checks and noisy technical routes only after confirming real user routes still appear. Capture logs in the same service context as traces so related events can link to requests. Use consistent setup between local, preview, staging, and production so filters stay predictable. Validate changes by generating one request, one log event, and one known route after deploy.
Usage guidance
Validate every SDK configuration change with a fresh request and log event. Keep advanced filters narrow; hiding noise should not hide incidents. Use the same identity values across SDKs in a multi-service flow. Prefer predictable setup values over clever runtime-generated labels.