Service Map in Honeycomb visually represents how traffic flows through your system in any given environment. It displays known services, service dependencies, and communication between services. Interact with the Service Map to examine and investigate smaller sets of services in detail.
Service Map generates a view of:
p95 duration of request response time for each service and for service to service communication.
p95 stands for 95th percentile.
The p95 duration indicates that 5% of the data sample have durations higher than that threshold and 95% of the data sample have durations lower than that threshold.Use cases for Service Map includes, but are not limited to:
Service Map is an Enterprise feature that is only available for teams sending data to new environments. Enterprise Honeycomb Classic teams are encouraged to migrate to Environments in order to use Service Map.
Access Service Map from the left navigation bar:
Service Map is built with distributed tracing data that you send to Honeycomb.
Spans within traces must contain several key pieces of data to construct the Service Map:
These fields can be configured in each dataset’s Definitions.
In order for Service Map to be generated, at minimum, teams need to send tracing datasets to specific environments. The following defined fields for spans in traces are required for a map to be automatically generated from your tracing datasets:
To draw a meaningful map, the traces should span multiple services.
By default, Service Map treats service.name in spans as a distinct service.
For infrastructure with gateways, this treatment could be problematic as it could obscure true service to service relationships.
If multiple services communicate through this gateway, the visual may appear as if some services speak exclusively to the gateway, or as if some services only receive traffic from the gateway.
For example, if Service A communicates to Service B through a gateway foo, the automatically generated Service Map will show Service A communicating to foo and foo communicating to Service B.
To ensure the relationship is not hidden by this representation, users can adjust their instrumentation so Honeycomb can represent gateways accurately.
No semantic convention exists for designating services on spans as gateways. We recommend the following methods for enabling Gateway visuals on Service Map. These recommendations are subject to change, pending the creation of an OpenTelemetry standard for Gateways.
To flag services as gateways and thus change its representation on the map:
This option automatically instruments component.proxy to each span.
No additional manual instrumentation is required.
We recommend manually instrumenting net.component: proxy for your gateway service(s) with one of two options:
When enabling tracing for a service mesh or gateway, modify the meshConfig to include custom_tags:
spec:
meshConfig:
enableTracing: true
defaultConfig:
tracing:
custom_tags:
net.component:
literal:
value: proxy
zipkin:
address: otel-collector.default:9411
When sending telemetry to an OpenTelemetry Collector, use the Attributes Processor to add specific attributes for the pipeline that contains the spans from the mesh:
processors:
batch:
attributes:
actions:
- key: "net.component"
value: "proxy"
action: insert
We recommend using Service Map to understand overall request traffic, as Service Map automatically samples traces to represent higher volume services. This means that Service Map may not represent services or edges with very low traffic in a selected time range.
Use Services Map in the following situations:
Quickly onboard engineers into a large complex architecture. Ask and identify:
During debugging or Root Cause Analysis for an issue with one or more services, ask and identify:
When validating system observability, or instrumentation quality assurance, ask and identify:
To explore common issues when working with Service Map, visit Common Issues with Visualization: Service Map.