Skip to main content
Modern development teams often choose to organize their code into a set of loosely-coupled services that communicate with each other. Honeycomb organizes its data to support this service-oriented concept.

​
Services in Honeycomb

In service-oriented architecture (SOA), an application is made up a set of services. It can be valuable to separate observability information among different services, because you may want to observe the behavior of a single service. On the other hand, it is also useful to be able to trace requests through a set of linked and connected services. In SOA, then, each Service represents one or more programs sharing a common executable. Many instances of the same Service might run at the same time for scaling; they all share the same name. Honeycomb’s approach to organizing Services is to separate your observability data by the different services it comes from, but to connect those services through distributed tracing.

​
Tracing and Services

Distributed Tracing is a method to connect a single request across multiple services. Honeycomb supports distributed tracing across multiple services. A single trace follows a request between different services to help see how they interact. A trace is made up of spans. Each span represents the execution of one piece of code on a service. A span is marked with a start time and a duration, as well as information that shows its connecting spans. Honeycomb can then visualize these spans in the waterfall view.

​
How to Define a Service Dataset in Honeycomb

Honeycomb organizes your observability data into individual Service Datasets. A Service Dataset represents all the information coming from a single Service. Automatic instrumentation with OpenTelemetry Tracing will properly produce traces in Honeycomb and propagate headers between services to ensure the traces are intact.