[{"traceId":"607e3e086301ffaf74e217d5983efbc5","parentId":"74e217d5983efbc5","id":"91d3f96d11d7cb8e","kind":"SERVER","name":"get /api/msgcenter/msg/lastest","timestamp":1618886163861028,"duration":3775,"localEndpoint":{"serviceName":"base-msg-center","ipv4":"10.20.5.160"},"remoteEndpoint":{"ipv4":"123.157.238.102"},"tags":{"http.method":"GET","http.path":"/api/msgcenter/msg/lastest","mvc.controller.class":"ClientAPIController","mvc.controller.method":"getLastestMsgRecord"},"shared":true},{"traceId":"607e3e086301ffaf74e217d5983efbc5","parentId":"74e217d5983efbc5","id":"91d3f96d11d7cb8e","kind":"CLIENT","name":"get","timestamp":1618886152337857,"duration":11526274,"localEndpoint":{"serviceName":"lingyue-gateway","ipv4":"10.20.6.52"},"tags":{"http.method":"GET","http.path":"/api/msgcenter/msg/lastest"}},{"traceId":"607e3e086301ffaf74e217d5983efbc5","parentId":"74e217d5983efbc5","id":"864bdbd5a06a0515","kind":"SERVER","name":"get /auth/check","timestamp":1618886152333018,"duration":5224,"localEndpoint":{"serviceName":"dmo-user","ipv4":"10.20.7.38"},"remoteEndpoint":{"ipv4":"10.20.6.52","port":33926},"tags":{"http.method":"GET","http.path":"/auth/check","mvc.controller.class":"AuthController","mvc.controller.method":"checkToken"},"shared":true},{"traceId":"607e3e086301ffaf74e217d5983efbc5","id":"74e217d5983efbc5","localEndpoint":{"serviceName":"lingyue-gateway","ipv4":"10.20.6.52"},"annotations":[{"timestamp":1618886174659000,"value":"brave.flush"}]},{"traceId":"607e3e086301ffaf74e217d5983efbc5","parentId":"74e217d5983efbc5","id":"864bdbd5a06a0515","kind":"CLIENT","name":"get","timestamp":1618886152331773,"duration":5668,"localEndpoint":{"serviceName":"lingyue-gateway","ipv4":"10.20.6.52"},"tags":{"http.method":"GET","http.path":"/auth/check"}},{"traceId":"607e3e086301ffaf74e217d5983efbc5","id":"74e217d5983efbc5","kind":"SERVER","name":"get","timestamp":1618886152322007,"duration":11542205,"localEndpoint":{"serviceName":"lingyue-gateway","ipv4":"10.20.6.52"},"remoteEndpoint":{"ipv4":"123.157.238.102"},"tags":{"http.method":"GET","http.path":"/base-msg-center/api/msgcenter/msg/lastest"}}]
Hi all,I have deployed Jaeger on istio to monitor the bookinfo application. Then I want to analyze the trace data of Jaeger. However, I am confused by some span tags, such as, upstream_cluster and peer address. I found the meaning of peer.address from https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk_exporters/zipkin.md
, It says that peer.address means remote address. I think it means that when a client start a request and a server receive the request, the client's peer.address will be the server and the server's peer address will be the client.
Here is some information I get from one trace with 8 spans.
spanID operationName podIP serviceName pid refType peer.address span.kind
0 0044bea01e572833 productpage.default.svc.cluster.local:9080/pro... 10.244.27.204 istio-ingressgateway 192.168.0.49 client
1 a2bdd3593ab25d00 productpage.default.svc.cluster.local:9080/pro... 10.244.27.238 productpage.default 0044bea01e572833 CHILD_OF 10.244.27.204 server
2 626e09f9758da789 details.default.svc.cluster.local:9080/* 10.244.27.238 productpage.default a2bdd3593ab25d00 CHILD_OF 10.244.27.238 client
3 5a76f143f0e5c301 details.default.svc.cluster.local:9080/* 10.244.27.247 details.default 626e09f9758da789 CHILD_OF 10.244.27.238 server
4 9c1aaf91ea5e5ce9 reviews.default.svc.cluster.local:9080/* 10.244.27.238 productpage.default a2bdd3593ab25d00 CHILD_OF 10.244.27.238 client
5 923db83990a9e7e5 reviews.default.svc.cluster.local:9080/* 10.244.27.246 reviews.default 9c1aaf91ea5e5ce9 CHILD_OF 10.244.27.238 server
6 8e3dbd4dd0b70f85 ratings.default.svc.cluster.local:9080/* 10.244.27.246 reviews.default 923db83990a9e7e5 CHILD_OF 10.244.27.246 client
7 f227decb8d8b2c51 ratings.default.svc.cluster.local:9080/* 10.244.27.217 ratings.default 8e3dbd4dd0b70f85 CHILD_OF 10.244.27.246 server
However, the peer.address seems to be it's parent span's pod id, which is different from what I understand, and I don't know which is right.
Besides, I don't understand the meaning of upstream_cluster and downstream_cluster as below. Why all downstream_cluster is None, and what is the meaning of '9080' and 'inbound' in outstream_cluster?
spanID operationName podIP ... upstream_cluster downstream_cluster span.kind
0 0044bea01e572833 productpage.default.svc.cluster.local:9080/pro... 10.244.27.204 ... outbound|9080||productpage.default.svc.cluster... - client
1 a2bdd3593ab25d00 productpage.default.svc.cluster.local:9080/pro... 10.244.27.238 ... inbound|9080|| - server
2 626e09f9758da789 details.default.svc.cluster.local:9080/* 10.244.27.238 ... outbound|9080||details.default.svc.cluster.local - client
3 5a76f143f0e5c301 details.default.svc.cluster.local:9080/* 10.244.27.247 ... inbound|9080|| - server
4 9c1aaf91ea5e5ce9 reviews.default.svc.cluster.local:9080/* 10.244.27.238 ... outbound|9080||reviews.default.svc.cluster.local - client
5 923db83990a9e7e5 reviews.default.svc.cluster.local:9080/* 10.244.27.246 ... inbound|9080|| - server
6 8e3dbd4dd0b70f85 ratings.default.svc.cluster.local:9080/* 10.244.27.246 ... outbound|9080||ratings.default.svc.cluster.local - client
7 f227decb8d8b2c51 ratings.default.svc.cluster.local:9080/* 10.244.27.217 ... inbound|9080|| - server
Hi!
At our company we're going to implement Zipkin. However as database we're obliged to use PostgreSQL. Is there any documentation regarding the database component so that we could write our own implementation?
I checked out the Zipkin source code/javadoc and also looked at the Cassandra and ElasticSearch implementations but some kind of documentation would be very helpful.
Maybe other remarks that we should take into account? Or tips to make this implementation easier?
Thanks in advance for the info!
Kr
I was typing up a question here about how I could include Zipkin as part of my Spring Boot project as a subproject (Gradle) without using EnableZipkinServer, Docker Compose or the self-contained jar since the compose setup has problems with live-reload and cache sharing, while the self contained jar would've been available with Gradle ideally to avoid unnecessary binaries in the repo. I soon answered my own question after thinking it through, so I wanna document it for archival's sake even if it may be almost obvious to someone more experienced:
Treat Zipkin as an external service, and use Docker Compose to describe your external services. This also includes things like databases, messaging servers and cache servers. Use Docker Compose to ready the infrastructure and let your build tool manage your code outside Docker instead. No custom binaries for your external dependencies, no manual cache management, and as an added bonus, single command infrastructure.
I sure would've loved to grok this earlier so I didn't have to spend so many days trying different options. Ah well, sometimes you learn the hard way xD
Hello everybody, just joined. I was trying to use Zipkin for a few days in my Ruby on Rails app and I am using::Logger::Formatter.new as the formatter. How do I print the trace id, span id etc in the application logs ?
In my Java App it automatically comes as "[vmsservice,c6b162b6763740b6,93228fedf49d17c2,true]" as part of the log.
hello,
trying to run zipkin on ec2 centos instance & getting
"Armeria server failed to start"
Caused by: io.netty.channel.unix.Errors$NativeIoException: bind(..) failed: Address already in use
I'd like to know which address it wants to use. zipkin is running fine on our other servers with the same version.
any help is much appreciated.