the readme in zipkin-server has almost everything you need to troubleshoot zipkin, but no story on how to use the pieces. Having a coherent troubleshooting story conserves time from new users and volunteers who support them.
For example, you'd start with the /health endpoint (maybe noting /info). If debugging kafka, you'd make sure kafka was in the /health output and that it had corresponding metrics in /metrics. If not, you'd run a test by putting a fake span on the kafka topic using console-producer. If that works, you'd turn to what might be up with instrumentation. For example, it could be custom or misconfigured. You might direct someone to a working example and go from there.