Concepts & Reference
Services, Endpoints, And Dependencies
Understand how Vight organizes application behavior into services, endpoints, external calls, and dependency paths.
Concept
Understand how Vight organizes application behavior into services, endpoints, external calls, and dependency paths.
A service is the named application component that emits telemetry, such as an API, web app, job, or background process.
An endpoint is an inbound route or operation handled by a service.
A dependency is another service or external resource called while work is being handled.
Examples
- Service
- `checkout-api` is the service because it owns request handling, deploys independently, and appears as one operational unit.
- Endpoint
- `POST /checkout` is an endpoint because it is an inbound operation users or callers trigger.
- Dependency
- `payments-api` is a dependency when checkout calls it during the request path.
How Vight uses it
Use Services when you need to compare health across application components. Use Service Detail when you already know which service owns the symptom. Use Endpoints for inbound request behavior and External calls for outbound dependency behavior. Use the Service Map when a symptom may be caused by a caller or downstream dependency. Use Traces when a single request path is the best way to prove where time or failure happened.
Usage guidance
Name services by ownership and purpose, not by temporary host or process names. Use endpoints to compare inbound behavior before blaming dependencies. Use the service map when a failure could have spread from a caller or downstream service. Use traces when you need proof for one specific request path.