This message was deleted.

If worth noting, the services are Java Spring Boot using OTel auto-instrumentation only at this time.

I was surprised to see that a few services haves lines connecting them directly, rather than the connection being between a database

message queue i understand but what you mean by database here?

Thanks for asking. My Java services each either pull from a message queue, or run on a scheduler to do basic ETL out of a few databases. In most cases I'm seeing the databases and message queue servers show up interacting with each service. In these few cases, I'm seeing lines and flow between the Java services that should not have any way to communicate. So I'm curious if they are in fact some how communicating, or where I may have misconfigured OTel, or even the java services themselves, that is making auto-instrumentation think they're communicating.

If they are showing up as connected in graph then there must be some one-to-one connection b/w them.

How can I use Signoz to see what that correleation might be?

the span that initiated the request would have the

externalHttpUrl

set to upstream url. Search by that and see the trace graph.

externalHttpUrl would assume that the communication is happening on port 80/443? Or that's a general term? The services typically aren't listening to any traffic, except for rare instances of Spring Actuator running for health checks.

It doesn't assume anything. It uses the host and port used in the network request.

Okay

I don't understand what you mean by that. Use the traces explorer and filter by

externalHttpUrl

CONTAINS

upstream service host

. And it should give the trace which contains the call from service A (downstream) to service B (upstream).

Hmmm, okay. I'm sure it's just. a lack of my understanding. Let me take a look around with these details and come back with more questions if I get lost. These are all things I didn't look into yesterday. 🙂