zipkin traces not visible after enabling zipkin-receiver in skywalking

[p1742000]

I followed below document given by skywalking :
https://skywalking.apache.org/docs/main/v9.2.0/en/setup/backend/zipkin-trace/

skywalking installation has been done by :
helm install skywalking skywalking -n skywalking \ --set oap.storageType=elasticsearch \ --set ui.image.tag=9.2.0 \ --set oap.image.tag=9.2.0 \ --set oap.replicas=1 \ --set oap.env.SW_RECEIVER_ZIPKIN=default \ --set oap.envoy.als.enabled=true

my skywalking pods are up and running :

my istio and demo app is also running fine

i have exposed the zipkin port from skywalking side.

i configured istio to send the zipkin traces to skywalking backend with port as 9411. but, still skywalking UI doesn't show zipkin trace as expected.

Anything am i missing here ?

[wu-sheng]

No, it wouldn't. You have two options

1. Use Zipkin lens UI
2. Use the bundled lens UI only from 9.4.0

The bottom line, Zipkin spans are different from SkyWalking spans. SkyWalking OAP is an alternative server, rather than a processer.
This position has been listed on Zipkin document very clearly.

[wu-sheng]

https://skywalking.apache.org/docs/main/v9.2.0/en/setup/backend/zipkin-trace/

The doc you referred to, doesn't have a word to say we would visualize the spans of Zipkin on SkyWalking trace query widget. They are not the same.

[p1742000]

Okay. Thanks for your reply @wu-sheng . So, we didn't get zipkin trace to be visualised in SW-UI 9.2.0, right as per my understanding from your answer. But, we will be having zipkin UI that is bundled in skywalking's newer version 9.4.0 where we can visualize zipkin traces also apart from native traces. is my understanding correct ?

So, Now, i tried with skywalking updated version, where in i can see zipkin UI tab visible in Skywalking Service mesh dashboard. That is actually a very great feature to use with native skywalking (Thanks for that to our whole SW community).

So, i configured that 9411 port exposed with the skywalking service in istio zipkin address. and added this SW_QUERY_ZIPKIN=default in the application.yaml. Also deployed demo application. but i didn't see the zipkin traces in the zipkin UI. i missed something slighest. can you please look into this ?

my application.yaml

`receiver-otel:
selector: ${SW_OTEL_RECEIVER:default}
default:
enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"oc,otlp"}
enabledOtelRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_RULES:"istio-controlplane"}

receiver-zipkin:
selector: ${SW_RECEIVER_ZIPKIN:default}
default:
searchableTracesTags: ${SW_ZIPKIN_SEARCHABLE_TAG_KEYS:http.method}
# The sample rate precision is 1/10000, should be between 0 and 10000
sampleRate: ${SW_ZIPKIN_SAMPLE_RATE:10000}
## The below configs are for OAP collect zipkin trace from HTTP
enableHttpCollector: ${SW_ZIPKIN_HTTP_COLLECTOR_ENABLED:true}
restHost: ${SW_RECEIVER_ZIPKIN_REST_HOST:0.0.0.0}
restPort: ${SW_RECEIVER_ZIPKIN_REST_PORT:9411}
restContextPath: ${SW_RECEIVER_ZIPKIN_REST_CONTEXT_PATH:/}
restMaxThreads: ${SW_RECEIVER_ZIPKIN_REST_MAX_THREADS:200}
restIdleTimeOut: ${SW_RECEIVER_ZIPKIN_REST_IDLE_TIMEOUT:30000}
restAcceptQueueSize: ${SW_RECEIVER_ZIPKIN_REST_QUEUE_SIZE:0}
## The below configs are for OAP collect zipkin trace from kafka
enableKafkaCollector: ${SW_ZIPKIN_KAFKA_COLLECTOR_ENABLED:false}
kafkaBootstrapServers: ${SW_ZIPKIN_KAFKA_SERVERS:localhost:9092}
kafkaGroupId: ${SW_ZIPKIN_KAFKA_Group_Id:zipkin}
kafkaTopic: ${SW_ZIPKIN_KAFKA_TOPIC:zipkin}
# Kafka consumer config, JSON format as Properties. If it contains the same key with above, would override.
kafkaConsumerConfig: ${SW_ZIPKIN_KAFKA_CONSUMER_CONFIG:"{"auto.offset.reset":"earliest","enable.auto.commit":true}"}
# The Count of the topic consumers
kafkaConsumers: ${SW_ZIPKIN_KAFKA_CONSUMERS:1}
kafkaHandlerThreadPoolSize: ${SW_ZIPKIN_KAFKA_HANDLER_THREAD_POOL_SIZE:-1}
kafkaHandlerThreadPoolQueueSize: ${SW_ZIPKIN_KAFKA_HANDLER_THREAD_POOL_QUEUE_SIZE:-1}

query-zipkin:
selector: ${SW_QUERY_ZIPKIN:default}
default:
# For HTTP server
restHost: ${SW_QUERY_ZIPKIN_REST_HOST:0.0.0.0}
restPort: ${SW_QUERY_ZIPKIN_REST_PORT:9412}
restContextPath: ${SW_QUERY_ZIPKIN_REST_CONTEXT_PATH:/zipkin}
restMaxThreads: ${SW_QUERY_ZIPKIN_REST_MAX_THREADS:200}
restIdleTimeOut: ${SW_QUERY_ZIPKIN_REST_IDLE_TIMEOUT:30000}
restAcceptQueueSize: ${SW_QUERY_ZIPKIN_REST_QUEUE_SIZE:0}
# Default look back for serviceNames, remoteServiceNames and spanNames, 1 day in millis
lookback: ${SW_QUERY_ZIPKIN_LOOKBACK:86400000}
# The Cache-Control max-age (seconds) for serviceNames, remoteServiceNames and spanNames
namesMaxAge: ${SW_QUERY_ZIPKIN_NAMES_MAX_AGE:300}
## The below config are OAP support for zipkin-lens UI
# Default traces query max size
uiQueryLimit: ${SW_QUERY_ZIPKIN_UI_QUERY_LIMIT:10}
# Default look back for search traces, 15 minutes in millis
uiDefaultLookback: ${SW_QUERY_ZIPKIN_UI_DEFAULT_LOOKBACK:900000}`

my istio mesh config is

mesh: |- accessLogFile: /dev/stdout defaultConfig: discoveryAddress: istiod.istio-system.svc:15012 tracing: zipkin: address: skywalking-skywalking-helm-oap.skywalking:9411 enablePrometheusMerge: true extensionProviders: - envoyOtelAls: port: 4317 service: opentelemetry-collector.istio-system.svc.cluster.local name: otel rootNamespace: null trustDomain: cluster.local meshNetworks: 'networks: {}'

[wu-sheng]

I don't know, As this is an upstream error, it depends on Zipkin upstream only.
AFAIK, that fix is just for adopting unexpected span data.

[p1742000]

Okay, but with proper trace data, this error shouldn't be there, right. i think i do have proper trace data. One of the trace data is :

"traceId":"2626155b696501ad","parentId":"1c3f553277536de9","id":"8229274fc6e56c9a","kind":"SERVER","name":"ratings.default.svc.cluster.local:9080/*","timestamp":1685943963029759,"duration":1852,"localEndpoint":{"serviceName":"ratings.default","ipv4":"10.1.2.70"},"annotations":[{"timestamp":1685943963031747,"value":"ss"}],"tags":{"component":"proxy","downstream_cluster":"-","guid:x-request-id":"c46f6948-8804-467c-a7e6-4f0c7db8e6b6","http.method":"GET","http.protocol":"HTTP/1.1","http.status_code":"200","http.url":"http://ratings:9080/ratings/0","istio.canonical_revision":"v1","istio.canonical_service":"ratings","istio.mesh_id":"cluster.local","istio.namespace":"default","node_id":"sidecar10.1.2.70ratings-v1-5f9699cfdf-8t8b8.default~default.svc.cluster.local","peer.address":"10.1.2.74","request_size":"0","response_flags":"-","response_size":"48","upstream_cluster":"inbound|9080||","upstream_cluster.name":"inbound|9080||","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36"

it is coming to a backend, but the only problem is it is not coming in the UI.

[wu-sheng]

Again, this is SkyWalking community, not Zipkin community. We don't have enough knowledge or capabilities to clarify or fix this.

[p1742000]

Hii, @wu-sheng how can we connect separate zipkin UI with skywalking version 9.2.0 ?
Is it simply like in the zipkin deployment i gave ZIPKIN_BASE_URL as our skywalking server port (skywalking-oap.skywalking-ns.svc:9411) ?
Will it works successfully as i still didn't get traces in zipkin lens UI. so, am i missing something here ?

we tried skywalking version 9.4.0, but still we couldn’t figured out why we get blank screen once we hit that SHOW button. So, we are trying out another approach to connect skywalking (9.2.0) to separate zipkin lens UI.

[wu-sheng]

As it was mentioned, it is not caused by the backend. I can't see the point of continuing the talking here.

[Yangfisher1]

You need to configure the UI container since the tutorial is based on local deployment rather than k8s cluster. See #11116