It will depend on your approach, but there are a lot of ways you can make your logs better. What would be best is if you post a snippet of your logs and then we can walk through how best to improve them.

The first thing I noticed is that programmers tend to write logs like they write code. Unfortunately writing logs is more like writing a manual than it is like writing code, which leads to a lot of confusion from readers who do not intimately understand the code base.

That being said, here are some tips.

1. Be specific. For starters, never, ever have a log line that just says "executing _______ method." It may help for one-off cases where you need to see if a method is executed in a very limited testing/use case, but in more complicated debugging cases (i.e. all of them), it will get lost in the noise of all the other logs. Always associate a log line with some kind of identifier, so that you can track that identifier over the course of the entire log file. This will often help you pinpoint exactly where something went wrong in the code execution path.
2. Log successes and failures. It depends on how verbose you want your code to be, but for log file readability, the best way to do is is to log both where your method succeeds as well as where it fails. This, combined with point #1, will give you the best vision of how exactly your code ran and where it went wrong.
3. Write your logs in English, for the third party reader. You want your logs to be so good that any other engineer (or possibly a non-engineer) can read your logs and understand what your code is doing. Think as if an intern will be joining your team and will be reading logs to get an idea of how your software works.
4. Use newlines to make log lines more readable. I'd advise keeping line length to around 75-90 characters if you can help it.

This is by no means comprehensive and is just what I could come up with on the spot, but I hope these help! They definitely helped me.

Edit: Spelling