Troubleshooting
Wrong Service Or Environment
Use this guide when telemetry appears in Vight but under the wrong service name, environment, version, or deployment.
Symptom
Use this guide when telemetry appears in Vight but under the wrong service name, environment, version, or deployment.
The expected service is empty, but another service name has the data. Production data appears under staging, preview, dev, or another environment. Version or deployment filters do not match the release you are investigating.
Likely causes
- Values set after startup
- Identity values must be present before the SDK initializes so every signal uses the same labels.
- Fallback names
- Default service names are useful during setup but make production ownership unclear.
- Shared variables
- Preview, staging, and production deployments can accidentally reuse the same environment or deployment value.
Checks
Start with the broadest possible evidence window, then narrow the cause once you know where data is landing.
- 1
Inspect `VIGHT_SERVICE_NAME`, `VIGHT_ENVIRONMENT`, `VIGHT_SERVICE_VERSION`, and `VIGHT_DEPLOYMENT_ID` in the running service.
- 2
Confirm values are set before the SDK starts.
- 3
Check whether local, preview, and production deployments reuse the same variables.
- 4
Search Logs or Traces without narrow filters to find where telemetry landed.
Resolution
The fix should make new telemetry appear in the expected Vight page, under the expected service and environment, without relying on stale data.
Use stable service names that match how your team talks about ownership. Set environment values from deployment context instead of ad hoc defaults. Set version and deployment identifiers in the release process. Redeploy after changing identity values, then generate a fresh request.
After applying the fix, validate it this way: Redeploy with the intended service, environment, version, and deployment values. Generate a fresh request after the new process starts. Confirm the request appears under the intended labels in Services, Traces, Logs, and Runtime. Remove or rename stale labels only after confirming current telemetry is correct.