A core security principle applies here - obscurity is not security.
In this case you should evaluate the business benefits to troubleshoot and understand the system against how easy you make an attacker’s job at learning about your system.
The attacker can figure most of the architecture stuff out anyways. Your security model should assume they already know such that leaking the information you describe is low risk.
Tl;dr;
It’s usually better to assume the bad guys already know how the micro services interconnect.
Then you can focus attention on making sure there are no vulnerabilities with the micro services.
There is a trade off. If you obfuscate the trace information in the error codes then it’s more difficult for your engineers to understand how the services interoperate. If your team cannot easily understand how things work, how can they evaluate design weaknesses?
By obfuscating how your system works, you also obfuscate it from your staff.
By making the system transparent, it’s transparent to your staff as well. And you can focus on fixing vulnerabilities and design vulnerabilities.
This is why we trust AES over a proprietary and obfuscated cypher - it’s open and tested.
However, information asymmetry is still an advantage to whoever has more of it. The real value in the principle is to plan security after assuming the bad guys know everything. You should absolutely still keep information confidential. But also assume the bad guy knows or will know. IE, at any time the adversary can learn your architecture so never assume they don’t/can’t.
