Add support for directly generating span graphs

[grcevski]

Some initial code for generation of span graphs directly from Beyla. The basic design is as follows:

• Look to match a service by the calculated svc.ID.
• If you can't find it, use k8s (if enabled) and DNS to resolve the name.
• Cache all lookups to ensure we don't spam the DNS.
• Works properly across different nodes if the DNS agrees with the service name configured for OTel. If they don't then service graphs will be partial.

TODO:

• Prometheus scrape support
• Unit tests
• Integration tests
• Docs

[mariomac]

The following PR does the merge with origin/main. It just resolves the reported conflict in the instrumenter.go file, adapting the current code to the new pipes API. Despite the big size of the PR (it adds all the changes from main into your branch), I have only slightly changed the pipeline.go and name_resolver.go files.

grcevski#4

[grcevski]

The following PR does the merge with origin/main. It just resolves the reported conflict in the instrumenter.go file, adapting the current code to the new pipes API. Despite the big size of the PR (it adds all the changes from main into your branch), I have only slightly changed the pipeline.go and name_resolver.go files.

grcevski#4

Thanks a bunch Mario!

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 80.60942% with 70 lines in your changes are missing coverage. Please review.

Project coverage is 67.91%. Comparing base (fe9ac27) to head (b517207).

Files	Patch %	Lines
pkg/internal/export/otel/metrics.go	55.84%	23 Missing and 11 partials ⚠️
pkg/internal/export/prom/prom.go	76.11%	12 Missing and 4 partials ⚠️
pkg/transform/name_resolver.go	88.23%	10 Missing and 4 partials ⚠️
pkg/internal/transform/kube/db.go	90.32%	3 Missing ⚠️
pkg/internal/export/otel/traces.go	87.50%	2 Missing ⚠️
pkg/beyla/network_cfg.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #745      +/-   ##
==========================================
+ Coverage   67.41%   67.91%   +0.49%     
==========================================
  Files         102      103       +1     
  Lines        8853     9181     +328     
==========================================
+ Hits         5968     6235     +267     
- Misses       2445     2489      +44     
- Partials      440      457      +17     

Flag	Coverage Δ
integration-test	67.91% <80.60%> (+0.49%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mariomac]

🚀🙌🏻

[cyrille-leclerc]

From what I understood, Tempo generates traces_target_info when the OTel Collector Service Graph Connector generates target_info and we have a configuration flag to choose the one used (screenshot below).

@domasx2 do we have best practices here?

[grcevski]

Does it mean we may not need it? I simply went by what I saw Tempo generated for my cloud instance when using Alloy.

[domasx2]

It's needed for sure. I think what @cyrille-leclerc wondering is wether you should align with Tempo metric generator metric names, or OTEL spanmetrics/ service graph metrics connector metric names. I don't have a strong opinion TBH, though would lean towards OTEL

[grcevski]

Oh absolutely OTel then, just confirming, so if we renamed the collection as target_info App O11y will continue to work, correct? I'll create a PR to fix this.

[domasx2]

Note that span metric names change as well for Otel, instead of traces_span_* it's duration_seconds_bucket, duration_seconds_count and duration_seconds_total

[cyrille-leclerc]

as @domasx2 said, the question of OTel vs Tempo naming conventions. I would see value in adopting OTel conventions.
That being said, what's our recommendation if a customer is getting started combining Beyla with a bunch of app instrumented with OTel SDKs the simplest possible way, relying on Tempo metrics generation?
Sorry it's more complicated than we would like.

[cedricziel]

I do agree with the Gang that it would be beneficial to run with the new otel default. Given that users can have more instrumentation than just a single beyla deployment, I would opt to make this configurable to be either Otel (default) OR tempo.

If it was flexible, people could rely on tempo generated metrics + the ones from Beyla.

I would also lean towards helping tempo to align with otel long-term.

[grcevski]

Alright, I think we have a consensus. We'll add an OTel format and make it default.

I opened a new issue to track this here #821