What Is a Span ID in OpenTelemetry?
A beginner-friendly guide to the small identifier that gives every piece of work in a trace its own name tag: what it looks like, how it is created, how it links parents to children, and how it travels between services.
Imagine a huge wedding where hundreds of guests arrive. Every guest receives a name tag, but the tags are special. Each tag has the family name of the wedding printed on it, so everyone knows which event they belong to, and each tag also has a personal seat number, so no two guests are ever confused with each other. The family name is shared by everyone, while the seat number belongs to one person only. In OpenTelemetry tracing, the shared family name is the trace ID, and the personal seat number is the Span ID.
This guide starts from zero. You do not need to know what a span is, what an identifier is, or why software needs special numbers to describe its own work. We will build the idea one small step at a time, using simple pictures and everyday comparisons, until you can explain a Span ID to a colleague without hesitation.
1The Problem: How Do You Tell Pieces of Work Apart?
Before we meet the Span ID, let us feel the problem it quietly solves.
Software does many things at once
When a customer clicks “Buy” on an online shop, many small pieces of work happen. A login check runs. A basket is read. Stock is verified. A payment is taken. A receipt is saved. Some of these happen one after another, and some happen at the same time. Often they run on different computers owned by different teams.
Recording the work is not enough
OpenTelemetry records each piece of work as a span. A span has a name, a start time, an end time and some extra details. But imagine a trace containing thirty spans, and five of them are all named “query database”. Which one was slow? Which one belongs to the payment service and which one belongs to the stock service? Which one was started by which other piece of work? A name alone cannot answer these questions, because names repeat.
What the system needs is a label that is unique to each individual span. That label must be small, easy to send over a network, and standard enough that every tool in the world can read it. That label is the Span ID.
Think of a school with five students all named “Sam”. The teacher cannot call out “Sam” and expect the right child to answer. So each student receives a unique roll number. Names may repeat, but roll numbers never do. Span IDs are the roll numbers of the work done by your software.
Many beginners think the span name and the Span ID are the same thing. They are not. The name is for humans and is often repeated many times. The Span ID is for machines and is meant to be different for every span.
2A Quick Refresher: Traces and Spans
A Span ID only makes sense once you remember what a span is.
A trace is the complete record of one request or transaction as it moves through a system. It is made of many smaller records called spans. A span represents one unit of work, such as reading a file, running a database query, or calling another service. Every span has a start time and an end time, so it also has a duration, which tells you how long the work took.
Trace
The whole journey of one request, from the first service to the last. It is the complete story.
Span
One step in that journey, with a name, a start, an end, a status and extra details.
Trace ID
A label shared by every span in the same trace. It answers: which journey do I belong to?
Span ID
A label unique to one span. It answers: which exact step am I?
Notice how the last two ideas work as a pair. The trace ID groups spans together. The Span ID separates them from each other. You need both. A group label with no individual label cannot tell members apart, and an individual label with no group label cannot tell which group a member belongs to.
A parcel tracking page shows one parcel number at the top (trace ID) and a list of stops below. Each stop on the list also has its own line number (Span ID) so that the page can say “stop 3 happened after stop 2”. The parcel number alone could not do that.
3So, What Is a Span ID?
A plain definition first, then the reasons behind each word.
A Span ID is a unique identifier assigned to a single span within a trace. In OpenTelemetry, it is a random value that is eight bytes long. Because computers like to show bytes using the hexadecimal number system, which uses the digits zero to nine and the letters a to f, a Span ID is normally written as a string of sixteen of those characters.
For example, a Span ID might look like 00f067aa0ba902b7. It means nothing to a human reader. It carries no customer name, no service name and no time. It is simply a label, and that is exactly the point.
Unique
Each span should have its own Span ID. Two different spans in the same trace must never share one, otherwise the tree of work would become confusing.
Random
The value is generated randomly, not counted upwards. Random generation lets thousands of computers create IDs at the same moment without talking to each other.
Short and fixed in size
Eight bytes is small enough to attach to every network call cheaply, yet large enough that accidental repeats are extremely unlikely.
Meaningless on purpose
The value holds no business information. This keeps it safe to copy into logs and headers, and keeps it from leaking anything about your customers.
4Span ID Versus Trace ID
The two identifiers sit side by side everywhere, so let us compare them carefully.
Both identifiers are random and both are written in hexadecimal. The big differences are their size, their job and how often they change as a request moves between services.
| Question | Trace ID | Span ID |
|---|---|---|
| What does it identify? | The whole journey of one request | One single step of work |
| Size in bytes | 16 bytes | 8 bytes |
| Length in hexadecimal | 32 characters | 16 characters |
| How many spans share it? | All spans in the trace | Only one span |
| Changes between services? | No, it stays the same all the way | Yes, every new span gets a new one |
| Main purpose | Group spans into one trace | Tell spans apart and link parents to children |
Think of a hotel booking. The booking reference is the same for the whole family and for the entire stay, like a trace ID. Each room key card has its own number, like a Span ID. If one family member loses a key, the hotel replaces that card only, and the booking reference stays unchanged.
Why is the trace ID longer?
A trace ID must be unique across all traces ever created by all services in the world, so it needs more room. A Span ID only needs to be unique among the spans of one trace, which are usually counted in tens or hundreds, not billions. Eight bytes is more than enough for that job.
An easy memory trick: the trace ID is the “which story” label and the Span ID is the “which sentence” label. Stories are long and few, and sentences are short and many.
5Where Span IDs Come From
Nobody types a Span ID. The software makes one automatically the moment a span begins.
Inside an application, the OpenTelemetry SDK includes a component called an ID generator. Its job is simple: whenever a new span is created, it produces a fresh random Span ID, and whenever a brand-new trace begins, it also produces a fresh trace ID. The developer does not have to do anything.
The life of a Span ID
Work begins
Your code, or the automatic instrumentation, asks the tracer to start a span for some piece of work.
The ID generator makes a random value
It creates eight random bytes and makes sure they are not all zero, because an all-zero value is reserved to mean “invalid”.
The span records its identity
The new Span ID is stored on the span together with the trace ID and the parent’s Span ID, if there is a parent.
The work runs and the span ends
The Span ID stays the same for the whole life of the span. It never changes after creation.
The finished span is exported
The span, with its Span ID, is sent onwards to a Collector and then to a tracing tool for display.
Why random and not a counter?
You might wonder why the system does not simply count one, two, three. The trouble is that a counter needs a single place that everyone agrees on. In a world of thousands of servers creating spans at the same moment, asking a central counter for every number would be slow and fragile. Random numbers need no coordination. Each computer picks its own, and the enormous range of possible values makes accidental repeats astronomically unlikely.
Can the generator be customised?
Yes. The ID generator is a replaceable part of the SDK. Some cloud systems use special formats for trace identifiers, so OpenTelemetry allows teams to plug in their own generator when they must. For most beginners, the default random generator is the right choice and requires no thought at all.
Trying to build “meaningful” Span IDs by mixing in customer numbers, timestamps or server names. This is unnecessary and risky. If you need business details in a trace, put them in attributes, not in the identifier.
6The Parent Span ID: Linking Spans into a Tree
The real power of the Span ID appears when one span points at another.
Every span records two identifiers about itself: its own Span ID and the Parent Span ID. The Parent Span ID is simply the Span ID of the span that caused this one to start. When service A calls service B, the span created in B writes down A’s Span ID as its parent. This tiny habit is what lets a tracing tool rebuild the whole family tree of work later.
The very first span in a trace has no parent. It is called the root span, and its Parent Span ID is simply empty. Every other span points to exactly one parent.
flowchart TD
R["Root Span: Handle Buy Click"] --> A["Span: Check Login"]
R --> B["Span: Read Cart"]
R --> D["Span: Take Payment"]
D --> D1["Span: Call Bank"]
D --> D2["Span: Save Receipt"]
A worked example in words
Imagine the root span has the Span ID that we will nickname “A1”. The login check starts and records its own new Span ID, nicknamed “B2”, plus a parent of “A1”. The payment span records its own Span ID “C3” with parent “A1”. The call to the bank is a child of the payment span, so it records its own Span ID “D4” with parent “C3”. Nobody ever has to tell the tool about the tree. The tool simply reads each span’s parent value and joins the dots.
| Span Name | Span ID (nickname) | Parent Span ID (nickname) |
|---|---|---|
| Handle Buy Click | A1 | None, this is the root |
| Check Login | B2 | A1 |
| Take Payment | C3 | A1 |
| Call Bank | D4 | C3 |
Think of a family tree built from birth certificates. Each certificate has the person’s own number and the number of the parent. You never need a drawing. Collect enough certificates, match the numbers, and the whole tree appears.
If a tool shows a span floating alone with a missing parent, it usually means the parent span was never received. The Span ID was recorded correctly, but the span it points to did not arrive, perhaps because that service was not instrumented or its data was dropped.
7Span Context: The Bundle That Travels
The Span ID never travels alone. It rides inside a small package called the span context.
When a request leaves one service for another, something must carry enough identity information across the gap. OpenTelemetry calls this package the span context. It is deliberately small and unchangeable once created.
Trace ID
Tells the next service which journey this request belongs to.
Span ID
Tells the next service which span is making the call, so the new span can name it as its parent.
Trace Flags
Small switches, most importantly whether this trace has been chosen for recording.
Trace State
Optional vendor notes carried along as simple key-and-value pairs.
Notice that the Span ID inside the span context is the Span ID of the current span, the one making the outgoing call. When the next service receives it, that value becomes the parent of whatever new span the service starts. In this sense, the Span ID in a message on the wire is really a “my parent will be this” label for the receiver.
Imagine passing a baton in a relay race. The baton has a team colour (trace ID) and the name of the runner who is handing it over (Span ID). The next runner sees the name and remembers who passed it. That is how the chain of runners can be reconstructed afterwards.
Believing that the Span ID stays the same as a request travels through the system. It does not. The trace ID stays the same, but every new span creates a new Span ID, so the value changes at each step.
8Context Propagation: Carrying the Span ID Between Services
How does the Span ID jump from one computer to another?
Inside one program, OpenTelemetry remembers the current span in memory. But memory does not cross a network. When a service calls another service, the span context must be written into the outgoing message and read back out on the other side. This practice is called context propagation. It has two halves: inject on the sending side and extract on the receiving side.
sequenceDiagram
participant W as Web Service
participant P as Payment Service
participant B as Bank Service
Note over W: Span ID is W1
W->>P: Call with trace ID and Span ID W1
Note over P: Extract W1, create new Span ID P2, parent is W1
P->>B: Call with trace ID and Span ID P2
Note over B: Extract P2, create new Span ID B3, parent is P2
B-->>P: Reply
P-->>W: Reply
The standard format
For different teams and different tools to understand each other, the label must be written in an agreed format. The widely used standard is the W3C Trace Context. It defines one message label that carries a version number, the trace ID, a field named “parent ID”, and the trace flags, all separated by dashes. The “parent ID” field in that label is exactly the Span ID of the caller. So when you see “parent ID” in the standard, think “the Span ID of whoever is calling me”.
OpenTelemetry uses this standard by default. That is why a service written in one programming language can pass a trace to a service written in another, even if different vendors monitor each of them.
Propagators
The component that performs injection and extraction is called a propagator. You can configure which propagators a service uses. Older systems sometimes use other formats, and OpenTelemetry supports several of them. The important rule is that the sender and receiver must understand the same format, or the Span ID will not be recognised and a new trace will start.
Beyond web calls
Span IDs also need to cross message queues and background jobs. In those cases, the span context is attached to the message itself. A worker that picks up the message later can read the Span ID and either continue the trace as a child or link back to it.
If your traces appear chopped into separate pieces, check every hop for a proxy, gateway or message system that might be removing the propagation label. If the label disappears, the Span ID disappears with it.
9Valid and Invalid Span IDs
Not every eight-byte value counts as a proper Span ID.
OpenTelemetry sets aside one special value to mean “no valid span”: the value made entirely of zero bytes. It is written as sixteen zero characters. Because of this rule, a proper Span ID must contain at least one non-zero byte, and the ID generator is careful never to produce the all-zero value.
Why a special empty value?
The system needs a way to say “there is no span here”. For example, a root span has no parent, and a request that arrives with a damaged label has no usable caller. The all-zero value gives libraries a simple, consistent way to represent an absent or broken identifier without needing extra fields.
Non-zero, sixteen characters
A normal Span ID from the random generator, made of the digits zero to nine and the letters a to f.
All zeros
Means “no span”. Libraries treat it as missing and will not use it to build parent-child links.
Wrong length or characters
A label with too few characters, too many, or letters outside the allowed set is rejected and ignored.
Lowercase hexadecimal
In the standard text form, letters are written in lowercase so that comparisons between systems always match.
Writing your own code that builds identifiers from short or padded values, such as a simple counter, can accidentally create invalid or repeated Span IDs. Always let the SDK generate them.
10Uniqueness: Can Two Span IDs Ever Collide?
A fair worry for any careful beginner.
Eight bytes can hold an enormous number of different values, roughly eighteen quintillion. A Span ID only has to be unique among the spans of a single trace, and a typical trace contains somewhere between a handful and a few thousand spans. With random generation, the chance that two spans in one trace pick the same value is so small that, for practical purposes, it can be ignored.
Imagine a gigantic stadium with eighteen quintillion seats, and a hundred guests choosing seats completely at random. The chance that any two of them pick the same seat is vanishingly small. The seat range is so large compared to the number of guests that collisions essentially never happen.
The role of the trace ID
Even if two different traces somehow produced the same Span ID, nothing would go wrong, because the trace ID keeps them in separate groups. Tracing tools always combine the two together when they match a parent to a child. A Span ID is only meaningful together with its trace ID.
What if a collision did happen?
In the extremely rare event that two spans in the same trace shared a Span ID, a tool might draw the tree incorrectly, attach a child to the wrong parent, or hide one span. This is more likely to be caused by faulty custom code, such as a bad ID generator that reuses values or a copied span context that was reused by mistake, than by pure chance.
When debugging strange trace shapes, duplicated Span IDs are rarely the first suspect, but they are worth checking if you use a custom generator or if spans are being replayed from storage.
11Span IDs in the Wire Format and the Collector
What happens to the Span ID after the span ends?
When an application sends finished spans to a Collector or a tracing tool, it uses the OpenTelemetry Protocol, often shortened to OTLP. Inside this protocol, a Span ID is stored as raw bytes, which is compact and fast to send. When OTLP is written in its text-based web format, the identifiers are shown as hexadecimal text, matching what you see in logs and dashboards.
What the Collector does with Span IDs
The OpenTelemetry Collector receives spans, may change them in various ways, and forwards them on. In nearly every normal setup, the Collector leaves the Span ID untouched. It is part of the span’s identity, and changing it would break the parent-child links that other spans rely on.
flowchart LR
APP["Application creates spans with Span IDs"] --> SDK["SDK exports spans over OTLP"]
SDK --> COL["Collector receives and processes"]
COL --> BE["Tracing backend stores spans"]
BE --> UI["Dashboard rebuilds the tree using Span IDs"]
How the backend uses it
The tracing backend receives spans from many services, in no particular order. It groups them by trace ID, then looks at each span’s Parent Span ID to find the matching Span ID of another span. By following these links, it rebuilds the tree and draws the waterfall view. Without Span IDs, the backend would have a pile of timings with no structure.
Late-arriving spans
A parent span usually finishes last and is exported last. The backend may briefly show children without their parent. Once the parent arrives and its Span ID matches, the tree completes itself.
Sampling and Span IDs
Sampling decisions in OpenTelemetry are based on the trace ID, not on the Span ID, so that every span of a trace gets the same fate. The Span ID simply travels along with whichever spans are kept.
Missing parents
If a processor or sampler drops a parent span but keeps its children, the children will point at a Span ID that no longer exists. The tool shows them as orphans. This is a sign that sampling or filtering was applied inconsistently.
12Span IDs in Logs and Metrics
The same small label helps you jump between different kinds of data.
One of the most practical uses of the Span ID is correlation, which means linking different signals together. When a log message is written while a span is active, OpenTelemetry can stamp the log with both the trace ID and the Span ID. Later, an engineer looking at a slow span can search the logs for that exact Span ID and see only the messages written during that specific piece of work.
From span to logs
Copy a Span ID from a slow span and search your logs for it to read the exact messages written during that step.
From logs to span
Spot an error message that carries a Span ID, then jump straight to the span and its place in the trace tree.
From metrics to span
Metric samples called exemplars can store a trace ID and Span ID so a spike on a chart leads to a real example.
Support conversations
A customer or colleague can quote a trace ID or Span ID, and you can find the exact moment without guesswork.
Think of a hospital where each patient wears a wristband with an ID number. The doctor’s notes, the lab results and the nurse’s chart all carry the same number. Whichever paper you pick up first, the number takes you to the others. Trace IDs and Span IDs are the wristband numbers of your telemetry.
Many logging libraries have an OpenTelemetry integration that adds the trace ID and Span ID to every log line automatically. Turning it on is one of the cheapest improvements you can make to your debugging experience.
13Span IDs and Span Links
Sometimes work is related but not parent and child.
A normal parent-child relationship uses the Parent Span ID. But some situations do not fit that mould. A batch job might process a hundred messages, each created by a different trace. It would be wrong to say the job is the child of all hundred, since a span can have only one parent. Instead, OpenTelemetry offers span links.
A span link is a pointer from one span to another, made of the other span’s trace ID and Span ID. It says “I am related to that span”, without claiming a parent-child relationship. Because the link uses the Span ID, it can point to a span in a completely different trace.
Parent Span ID
- Exactly one per span
- Builds the tree of causes and effects
- Stays inside one trace
- Best for direct, waiting calls
Span Links
- Can have many on one span
- Connects loosely related work
- Can point into other traces
- Best for batches and fan-in from many sources
A good rule of thumb: if the caller is waiting for the result, use a parent. If the connection is more like “this was triggered by or is related to that”, consider a link.
14How to Use Span IDs When Debugging
The identifier is boring to look at, yet very handy in practice.
Find the slow span in a trace
Open the waterfall view and click the widest bar. The tool shows its Span ID and its parent’s Span ID.
Copy the Span ID
Use it as a search term in your log tool to see messages written during that exact piece of work.
Walk up using the parent
If the problem is unclear, follow the Parent Span ID upwards to see what started the slow step and why.
Walk down using children
Search for spans whose parent is your current Span ID to see everything this step triggered.
Share the pair of IDs
When asking a colleague for help, send the trace ID and Span ID together so they land on the exact same spot.
Troubleshooting common symptoms
| Symptom | Likely Cause Related to Span IDs |
|---|---|
| Trace broken into separate traces | The Span ID and trace ID were not passed on at some hop |
| Spans floating with no parent | The parent span was dropped, delayed or never instrumented |
| Wrong shape in the waterfall | Duplicate Span IDs from faulty custom code or replayed data |
| Logs do not match spans | The logging library is not adding trace identifiers |
| Every span shows an all-zero ID | Tracing is disabled or no real span was active when logging |
15Security and Privacy Considerations
Span IDs are harmless labels, but a few habits keep them that way.
A Span ID is a random, meaningless value, which makes it very safe to copy into logs and send across networks. It reveals nothing about customers, servers or business data. However, there are some practical points worth remembering.
Not a secret
Do not treat a Span ID like a password or a key. It is designed to be visible. Knowing a Span ID gives nobody any power over your system.
Not for authentication
Never use a trace ID or Span ID to decide who is allowed to do something. They are labels for observation, not proof of identity.
Trust incoming context carefully
When your public-facing service receives a propagation label from the open internet, someone may have crafted it. Many teams choose to start a fresh trace at the edge and link to the incoming one, rather than blindly joining it.
Keep sensitive data out of identifiers
Because identifiers appear in many places, never mix personal information into them. Keep such data, if you must record it, in carefully reviewed attributes with redaction rules in a Collector.
Problem
A team builds a custom ID generator that embeds the customer’s account number inside each Span ID so that support staff can recognise customers at a glance.
Why It’s Harmful
Identifiers are copied into headers, logs and third-party tools. Personal data is now spread everywhere, and the values are no longer random, which can cause collisions and privacy problems.
Correct Approach
Keep identifiers random and meaningless. Add a harmless internal customer reference as a span attribute, and apply redaction at the Collector.
16Best Practices and Anti-patterns
A handful of habits will keep your Span IDs useful and trustworthy.
Good habits
Let the SDK generate IDs
The default generator is well tested. Replace it only when you have a clear reason, such as a required format.
Propagate context at every hop
Ensure gateways, queues and background jobs pass the span context along so the parent link is never lost.
Stamp logs with trace and Span IDs
Enable logging integration so that every log line can be traced back to its span.
Use standard propagation formats
Stick to the W3C Trace Context unless you have older systems that need something else.
Sample by trace, never by individual span
Keep or drop whole traces so that parent and child Span IDs stay consistent.
Share both IDs when asking for help
A trace ID and Span ID together pinpoint one exact moment in one exact journey.
Mistakes to avoid
Problem
A developer reuses the same span context object for many different outgoing calls instead of creating fresh spans for each call.
Why It’s Harmful
Several different pieces of work end up claiming the same identity. Parent-child links become confusing and the tree in the dashboard looks wrong.
Correct Approach
Create a new span for each separate unit of work so that each one receives its own Span ID.
Problem
A gateway or message system in the middle of the architecture silently strips unknown message labels, including the propagation label.
Why It’s Harmful
The next service never sees the Span ID of its caller, so it starts a new trace. The journey is cut in half and nobody can see the full picture.
Correct Approach
Configure intermediaries to forward the standard trace labels, and test an end-to-end request after every infrastructure change.
Problem
A filter in the Collector drops some spans based on their names but leaves their children in place.
Why It’s Harmful
The surviving children point to Span IDs that no longer exist. Tools show orphans and engineers lose confidence in the traces.
Correct Approach
Filter or sample at the trace level, or make sure that dropping a parent also drops its dependent children.
Problem
Engineers use Span IDs as keys for business decisions, for example treating them as order numbers or customer references.
Why It’s Harmful
Span IDs exist only inside traces and may be sampled away or never stored. Building business logic on them leads to missing data and broken processes.
Correct Approach
Use proper business identifiers for business logic, and attach them to spans as attributes for searching.
17Advantages and Trade-offs of Random Span IDs
The design choice behind the Span ID has clear strengths and a few limits.
Advantages
- No central counter, so every computer can create IDs independently and instantly
- Tiny size, so attaching it to every network call is cheap
- Collisions inside one trace are extremely unlikely
- Meaningless content means no accidental data leaks
- Standard format that works across languages and vendors
- Makes parent-child trees and log correlation possible
Disadvantages / Trade-offs
- Humans cannot read or remember them, so tools are essential
- Random values cannot be sorted into a meaningful order
- A tiny, non-zero chance of collision always exists
- Parent links break if any hop drops the propagation label
- Only meaningful together with the trace ID
A side-by-side look at identifier choices
| Approach | How It Works | Main Strength | Main Weakness |
|---|---|---|---|
| Random Span ID | Each span picks eight random bytes | No coordination needed | Not human friendly |
| Central counter | One service hands out the next number | Easy to read and sort | Slow and a single point of failure |
| Meaningful names | Build the ID from service and time | Self-explanatory | Leaks details and risks repeats |
“A Span ID tells me when or where a span happened.” It does not. It is just a random label. Timing lives in the span’s start and end times, and location lives in its resource attributes.
18Real-World Scenarios
Picture how teams use this humble identifier every day.
An engineer connects a slow span to its logs
During an incident, an engineer finds a database span that took six seconds. She copies its Span ID and searches the logs. Within seconds she sees a warning about a missing index, written during that exact span. The fix takes minutes instead of hours.
A team finds a broken trace after a gateway upgrade
After upgrading a gateway, traces suddenly appear in two halves. The second half’s first span has no parent. The team realises the gateway stopped forwarding the propagation label, so the Span ID of the caller never arrived. A one-line configuration change restores full traces.
A support agent finds one customer’s request
A customer reports a failure and mentions a reference shown on their error page, which includes the trace ID. The agent opens the trace, spots the red span, notes its Span ID, and shares both with the development team. The developers land on the exact failing step immediately.
A platform team audits its sampling setup
A platform team notices many orphan spans in its dashboards. Checking Span IDs shows that children refer to parents that were never stored, because a filter dropped parents by name. After switching to trace-level sampling, orphans disappear.
A batch job links back to many producers
A nightly job processes thousands of queued messages. For each message, it adds a link containing the trace ID and Span ID of the span that produced it. Engineers can later jump from the job to any original request, even though they lived in different traces.
19Frequently Asked Questions
It is a random, eight-byte identifier that uniquely labels one span inside a trace. It is usually shown as sixteen hexadecimal characters. Its job is to tell spans apart and to let child spans point back to their parents.
A trace ID is shared by every span in the same trace and is sixteen bytes long. A Span ID belongs to one span only and is eight bytes long. The trace ID stays the same through the whole journey, while the Span ID changes with every new span.
The OpenTelemetry SDK creates it automatically through its ID generator when a span starts. Developers normally never create or type one by hand.
The next service creates a new span with a new Span ID. The caller’s Span ID travels in the propagated context and becomes the new span’s parent, so the link between them is preserved while the identifiers themselves differ.
It is the Span ID of the span that caused the current span to start. It is stored on the child span, and the root span has no parent, so its Parent Span ID is empty.
No. An all-zero value is reserved to mean “invalid” or “no span”. The ID generator avoids producing it, and libraries ignore it if they receive it.
Yes. They are random and meaningless, so they reveal nothing sensitive. Putting them in logs is a recommended practice because it lets you jump between spans and log lines easily.
Within one trace, they should not. With random eight-byte values, accidental repeats are astronomically unlikely. If you see duplicates, suspect a faulty custom generator or reused context rather than bad luck.
Standard sampling decisions are based on the trace ID, so that all spans in a trace are kept or dropped together. The Span ID simply travels with whichever spans are kept.
The parent span may not have arrived yet, may have been dropped by a filter or sampler, or may belong to a service that is not instrumented. The child correctly recorded its parent’s Span ID, but no span with that ID exists in the data.
No. Span IDs exist only for tracing, may be sampled away, and are not stable business references. Use proper business identifiers and attach them to spans as attributes if you want to search by them.
No. Events are timestamped notes inside a span and do not have identifiers of their own. They belong to the span that contains them and are identified through that span’s Span ID.
20Summary and Key Takeaways
A Span ID is the small, random label that gives every span in an OpenTelemetry trace its own identity. It is eight bytes long, usually written as sixteen hexadecimal characters, created automatically by the SDK, and never reused inside one trace. Paired with the trace ID, it lets tools tell spans apart and rebuild the tree of work: each child span records its parent’s Span ID, and the span context carries that value across service boundaries through propagation. The Span ID stays unchanged from the application through the Collector to the dashboard, and it also connects traces with logs, metrics and span links. Keep identifiers random and meaningless, make sure every hop forwards the propagation label, sample whole traces rather than single spans, and let the SDK do the generating.
Key Takeaways
- One span, one Span ID — it is a random eight-byte value, written as sixteen hexadecimal characters, that uniquely labels a single span within a trace.
- It pairs with the trace ID — the trace ID groups spans into one journey, and the Span ID separates them, so you always need both to find one exact step.
- Parent Span IDs build the tree — each child stores its parent’s Span ID, and the root span has no parent, which lets tools reconstruct the full shape of a request.
- The SDK creates it automatically — an ID generator makes random, non-zero values, and an all-zero value is reserved to mean invalid or absent.
- Propagation carries it between services — the sender’s Span ID travels in the span context, using the W3C Trace Context by default, and becomes the receiver’s parent.
- It connects signals — adding trace and Span IDs to logs, metrics exemplars and span links lets you move smoothly between different kinds of telemetry.
- Keep it simple and safe — never embed business data in IDs, never use them for security or business logic, forward propagation labels at every hop, and sample whole traces.