This was what we wer asking you from beginning. We were not sure what is that you wanted to troubleshoot. Now your query makes more sense.
Coming back to your question, You can troubleshoot replication based on the issues you might face
1) In case you think that the content is not getting replicated to publish as expected , you can go to the agents on author section http://localhost:4502/etc/replication/agents.author.html and do a test connection to on your publish servers. Your publish servers will be listed here and find them click and go inside the page . eg:-
You will see a Test Connection button. Click on that to make sure there is an active connection to your publish server from your author. It should return you response as below
You can do this on all of your publish instance configuration to make sure your publish servers are active and is connected from author.
2)whenever you do a replication , under your server /crx-quickstart/logs ; you will have a replication.log file which will log all your replication requests and status of that
A sample of the content of the file is pasted below
Here you can see that the log clearly says that the reverse replication failed due to connection timeout, which means that the server is not able to connect to the other server for many reasons. Either the other server is not started, or a firewall might be blocking.
3) When all of the above looks good and logs don't show any error too, may be that your publish connection is slow or something and all your request are still pending in your author. To verify that you can check the replication queue and see if anything is pending there. Same page you checked the test connection you will find the replication queue
Hope this helps a bit. Let me know if you have any more questions
Apart from testing the basic setup of author-publisher replication that is if the replication agent is configured correctly and the test connection works fine. In case you want to troubleshoot any issue related to replication then you can simply enable debug logging specific to replication by going at host:port/system/console/slinglog and adding a debug logger for api "com.day.cq.cq-replication" and print the debug logs in any custom file like rep.log/replication.log.
The above basically is part of generic troubleshooting in AEM for any specific issue like workflow or replication. You can enable debug logs for a particular api to understand where exactly it failed and why.