[proposal] servicegraph support virtual/peer node

[JaredTan95]

Component(s)

processor/servicegraph

Is your feature request related to a problem? Please describe.

as #9232 (comment) designed, the current processor discards the call relationship when processing the following scenarios:

• It is requested by the browser to the backend, but the browser side does not integrate OTEL/sdk, and the backend integrates otel. So, the processor only received backend server span and will drop it from the cache when expired.

• The backend requests a service for an external address(like cloud service), and the backend integrates OTEL/sdk, but the external address does not integrate OTEL.

Describe the solution you'd like

so, I propose to patch edge before the processor discards these spans, depending on the kind of span in the cache:

• extract remote peer attributes in client and consumer span in

  opentelemetry-collector-contrib/processor/servicegraphprocessor/processor.go

  Line 201 in 0f57f29

  case ptrace.SpanKindClient:

  , and then store above attributes in edge.
• patch those edge before expired:

  opentelemetry-collector-contrib/processor/servicegraphprocessor/internal/store/store.go

  Line 117 in 0f57f29

  func (s *Store) Expire() {

• if expired span's kind is server, we can directly patch client=user, user represents all of requert source, maybe browser or curl.etc

finally , the metrics geanerated would be like:

traces_service_graph_request_total{client="user",server="B"} 10

traces_service_graph_request_total{client="a",server="http://example.com/hello-world"} 1

traces_service_graph_request_total{client="a",server="grpc.hello_world"} 1

traces_service_graph_request_total{client="a",server="10.10.10.1:8080"} 1

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• processor/servicegraph: @jpkrohling @mapno

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[JaredTan95]

I already finished it and tested in my fork repo. if the proposal makes sense, I will contribute it upstream. :)

[mapno]

Hi! Thanks for the proposal, I like the two use-cases described here. They can be a nice addition to the servicegraph processor.

We can make the actual implementation a bit more generic, so it doesn't spill to the store pkg. We also need to make sure that the use-cases are included in the semantic conventions-ie. net.sock.peer.addr is meant to be used for those types of connections.

[JaredTan95]

We also need to make sure that the use-cases are included in the semantic conventions-ie. net.sock.peer.addr is meant to be used for those types of connections.

After careful consideration, I found that not every span attribute has a generic tag like net.sock.peer.addr.

for database peer node, it only db.url provided for us to get peer info.

[mapno]

After careful consideration, I found that not every span attribute has a generic tag like net.sock.peer.addr.

Are there any attributes in the semantic conventions that we can reliably use to extract the data in the use-cases you described?

[JaredTan95]

Are there any attributes in the semantic conventions that we can reliably use to extract the data in the use-cases you described?

Unfortunately, it seems that this does not exist. :-(

[djaglowski]

Closed by #17350