Same SpanID, ParentID and TraceID in every span in different services
See original GitHub issueHi,
I just dived into Zipkin and it’s really cool so far. But I couldn’t get it running perfectly. To test the interaction I set up two express Server in docker and one is calling the other.
However, both servers emit the same Span information SpanID, ParentID and TraceID. Is that an intended behaviour, a bug or did I screw something up?
Is the Service that creates the root span (in this case watch_1
) supposed to have a ParentID?
(watch_1
calls, fetchme_1
responds )
If the environment variable FETCH_URL is set it will act as the caller otherwise it will just respond to queries.
import * as express from "express";
var fetch = require('node-fetch');
const {trace, BatchRecorder, Tracer, ExplicitContext, ConsoleRecorder} = require('zipkin');
const zipkinMiddleware = require('zipkin-instrumentation-express').expressMiddleware;
const {HttpLogger} = require('zipkin-transport-http');
const CLSContext = require('zipkin-context-cls');
var ctxImpl = new ExplicitContext();
var recorder = new ConsoleRecorder();
const tracer = new Tracer({
recorder: recorder,
ctxImpl: new CLSContext('zipkin')
});
//CALLER
const wrapFetch = require('zipkin-instrumentation-fetch');
const zipkinFetch = wrapFetch(fetch, {
tracer,
serviceName: process.env.SERVICE_NAME + '-fetch-' + process.env.APPLICATION_PORT,
port: process.env.APPLICATION_PORT
});
if (process.env.FETCH_URL != undefined) {
setTimeout(function () {
zipkinFetch(process.env.FETCH_URL).then(function (res) {
return res.text();
}).then(function (body) {
console.log(body)
});
}, 1000)
}
var app = express();
//RECEIVER
app.use(function (request:express.Request, response:express.Response, next) {
console.log(request.headers);
next()
});
app.use(zipkinMiddleware({
tracer,
serviceName: process.env.SERVICE_NAME + '-middleware-' + process.env.APPLICATION_PORT,
port: process.env.APPLICATION_PORT
}));
app.use('/', function (request:express.Request, response:express.Response, next) {
response.send('Hi');
});
app.listen(process.env.APPLICATION_PORT, function () {
console.log('The PetStore sample is now running at http://localhost:' + process.env.APPLICATION_PORT);
});
Thanks in advance 😃
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (2 by maintainers)
Top Results From Across the Web
How parentId can be same when using spring cloud sleuth ...
Span so it is completely normal if the parentId is not the same for two different Spans (if they don't share the same...
Read more >Understand distributed tracing
The child span creates its own ID and then propagates both that ID (as the parent span ID) and the trace ID in...
Read more >Spring Cloud Sleuth
The value of the ID of that span is equal to the trace ID. Trace: A set of spans forming a tree-like structure....
Read more >Technical distributed tracing details - New Relic Documentation
This applies filters to individual spans before all spans in a trace arrive, ... the trace ID, span ID, the New Relic account...
Read more >TraceId
In this case all three ids in the resulting TraceId are the same: TRACE ID SPAN ID PARENT ID SERVICE A 34429b04b6bbf478.34429b04b6bbf478<:34429b04b6bbf478.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That’s correct behavior. When you have only one span, all the ids in the trace will be the same. There are two services/nodes (I’ll call them nodes, since not all points in the graph have to be services) here, but only one span, because a span represents the interaction between two nodes. If you introduce a third node, for example a web browser, which calls the first service, then there will be two spans in the trace.
Usually, you would see a setup like this:
browser -> front-facing webapp -> microservice 1 -> microservice 2 -> database
Then, the root span would be “front-facing webapp” in the Zipkin UI. So even if the trace is triggered by the browser, the span starts at the first service.