Concepts & Reference
Service Identity And Environments
Keep service names, environments, versions, and deployments consistent so every Vight page points to the same application slice.
Concept
Keep service names, environments, versions, and deployments consistent so every Vight page points to the same application slice.
Service name tells Vight which application component emitted telemetry.
Environment separates production, staging, preview, development, and other deployment contexts.
Version and deployment values help compare behavior before and after releases.
Examples
- Service name
- `checkout-api` is better than `node-server` because it maps to a real owner and investigation surface.
- Environment
- `production`, `staging`, and `preview` should be distinct so filters do not mix unrelated traffic.
- Deployment
- `deploy_2026_06_24` or a release identifier helps compare behavior around a specific change.
How Vight uses it
Choose stable service names based on team ownership, not hostnames or temporary process names. Set environment from the deployment context and keep it consistent across services. Set version when you need to compare package, image, or application changes. Set deployment identifiers when release timing matters during incident review. Configure identity values before the SDK starts so traces, logs, runtime signals, and service rows agree.
Usage guidance
Set identity values before the SDK starts. Use the same labels for traces, logs, runtime metrics, and releases. Avoid changing service names casually; it splits history and ownership. Use versions and deployments when release correlation matters.