Here are the subjects covered in this page.
The service fields can be used to * describe the service for or from which the data was collected (i.e. observed service) * or to describe external services that have a direct invocation relationship to the observed service
Service fields at the Root of an Eventedit
Use the service fields at the root of an event to describe the service the event primarily relates to.
An example for this use case is a log entry being recorded for a particular service or appplication (e.g.
Describing external services in an invocation relationshipedit
Multiple services can be in an invocation relationship. Where it is possible to apply distributed tracing on all the involved services describe the individual services using root-level service fields and use the tracing fields to represent the invocation relationship.
There are situations when distributed tracing cannot be applied on some external services that are in an invocation relationship to an observed service.
Let’s consider the example of a service
MyService being deployed on a cloud provider with an upstream API gateway that passes through requests to
MyService (with additional context information about the API gateway itself).
To describe the API gateway as a service from the perspective of
MyService one can self-nest the service fields under
Describes the observed service that receives the inbound request from an external service
Describes the origin external service of the inbound request
Similar to the usage of
service.origin fields the service fields can be self-nested under
service.target.* to describe an external target service for an outbound request:
Describes the observed service that emits the outbound request to an external service
Describes the target external service of the outbound request
service.target.* fields should only be used on events that represent an invocation relationship.