AI
Why OpenTelemetry Naming Requires a Team Strategy
OpenTelemetry gives teams wide flexibility in how they instrument services. That flexibility creates a real problem: the names you choose for spans and attributes determine whether engineers can isolate failures in production. Poor names slow down debugging. The OTel project publishes blog posts on naming conventions, and those are worth reading. This talk adds a second method drawn from network science research, focused on how a team organizes itself to produce better names in the first place.
The Paradox in the Research Literature
Prior research found a contradiction: both fully decentralized teams and centralized single-broker teams were credited with producing the best shared language. The paper Travaglini cites resolves this by splitting “best” into two dimensions. Speed and descriptive quality are separate. Fully decentralized teams name things fastest. Centralized teams, where names pass through one broker, are slower but produce more precise names that handle ambiguous cases better. Recognizing that distinction makes the paradox disappear and points toward a testable middle ground.
The Experiment: Groups of Five Naming Abstract Symbols
Researchers assembled groups of five people and asked each group to name tangrams, abstract symbols that varied in how easy they were to distinguish. Some tangrams were simple; others were ambiguous. An effective name had to let another person pick out the right symbol quickly, including the ambiguous ones. Groups worked across several network configurations ranging from fully decentralized to fully centralized. The connected-broker configuration sits just slightly toward the centralized end of that spectrum.
What the Connected-Broker Model Actually Produces
The connected-broker network finished fastest of all configurations, including the fully decentralized one. It also matched the fully centralized network on descriptive quality. One structure beat every other on both measures at once. The mechanism: individuals still get time to form and test names independently, but a connected broker synthesizes those proposals quickly. No one waits long on a bottleneck, and the names that emerge have already been filtered for precision across the group.
Applying the Finding to OpenTelemetry Instrumentation
For teams instrumenting services with OpenTelemetry, the practical step is to assign one connected broker, someone with ties across the team who can collect proposed span names, compare them, and confirm a convention. Fully decentralized naming produces inconsistent attribute names across services. A single dictator slows the team down. The connected-broker model threads between those outcomes. Travaglini notes this is a controlled laboratory result and asks practitioners to test it in real engineering organizations and report back.
Notable Quotes
Both a totally decentralized network of people and a centralized with a single person, single node, a broker are supposed to produce the best names, a shared language. And they’re like, how is this possible? How can they both be the best? Nick Travaglini · ▶ 2:21
The connected broker network, the one that is just slightly more centralized than decentralized, is fastest. It’s actually faster than decentralized. Nick Travaglini · ▶ 4:03
this is a laboratory experiment. Your results may vary in the wild. So, please try this out and share your results in forums like this. Nick Travaglini · ▶ 4:42
Key Takeaways
- A connected-broker team structure produces OpenTelemetry span names faster and more precisely than fully decentralized or fully centralized teams.
- Splitting “best naming” into speed and descriptive quality resolves the research paradox and points to the right team configuration.
- This result comes from a controlled experiment; teams should test the connected-broker model in real instrumentation work and share findings.
About the Speaker(s)
Nick Travaglini is a Senior Technical Customer Success Manager at Honeycomb.io, where he helps engineering organizations adopt observability practices and technologies including OpenTelemetry.