allow printing out spans in OTEL format using debugexporter

[NimrodAvni78]

This allows us to print out the spans in their "final" OTEL compliant form instead of our intermediate representation, using the collector debugexporter, this can be very good when debugging the full path from OBI -> OTEL, and also for quick demos :)
still have 2 questions im wondering about

1. what Verbosity Level we want for printing?
   • basic doesn't tell us much but the number of spans
     Traces {"resource spans": 1, "spans": 3}
   • normal gives us all the information in a compact view

     ResourceTraces #0 service.name=python3.12 telemetry.sdk.language=python telemetry.sdk.name=opentelemetry-ebpf-instrumentation telemetry.sdk.version=unset host.name=ip-192-168-5-15.eu-west-1.compute.internal host.id=a998876e9a2642d8a1a9b8a0030c786e os.type=linux service.instance.id=ip-192-168-5-15.eu-west-1.compute.internal:200438 otel.library.name=go.opentelemetry.io/obi
     ScopeTraces #0
     in queue b158b6313328f1ef2e0303d7eb1ccf0c 4c0ec5a43092a9f0
     processing b158b6313328f1ef2e0303d7eb1ccf0c 1cef30258b957bb3
     GET / b158b6313328f1ef2e0303d7eb1ccf0c 977d6eb54c1c900b http.request.method=GET http.response.status_code=200 url.path=/ client.address=127.0.0.1 server.address=python3.12 server.port=8000 http.request.body.size=77 http.response.body.size=696 http.route=/
   

   • detailed gives us the full view with all attributes expanded

    ResourceSpans #0
    Resource SchemaURL:
    Resource attributes:
    -> service.name: Str(python3.12)
    -> telemetry.sdk.language: Str(python)
    -> telemetry.sdk.name: Str(opentelemetry-ebpf-instrumentation)
    -> telemetry.sdk.version: Str(unset)
    -> host.name: Str(ip-192-168-5-15.eu-west-1.compute.internal)
    -> host.id: Str(a998876e9a2642d8a1a9b8a0030c786e)
    -> os.type: Str(linux)
    -> service.instance.id: Str(ip-192-168-5-15.eu-west-1.compute.internal:200438)
    -> otel.library.name: Str(go.opentelemetry.io/obi)
    ScopeSpans #0
    ScopeSpans SchemaURL:
    InstrumentationScope  
    Span #0
    Trace ID       : 1ccc05fa47645f4074ac3e89ea1c5d35
    Parent ID      : 34854a7271bf3083
    ID             : 159ddd9db195cbc2
    Name           : in queue
    Kind           : Internal
    Start time     : 2025-11-10 11:03:43.546042775 +0000 UTC
    End time       : 2025-11-10 11:03:43.549766864 +0000 UTC
    Status code    : Unset
    Status message :
    Span #1
    Trace ID       : 1ccc05fa47645f4074ac3e89ea1c5d35
    Parent ID      : 34854a7271bf3083
    ID             : ad6bcebb3329cd94
    Name           : processing
    Kind           : Internal
    Start time     : 2025-11-10 11:03:43.549766864 +0000 UTC
    End time       : 2025-11-10 11:03:43.559647901 +0000 UTC
    Status code    : Unset
    Status message :
    Span #2
    Trace ID       : 1ccc05fa47645f4074ac3e89ea1c5d35
    Parent ID      :
    ID             : 34854a7271bf3083
    Name           : GET /
    Kind           : Server
    Start time     : 2025-11-10 11:03:43.546042775 +0000 UTC
    End time       : 2025-11-10 11:03:43.559647901 +0000 UTC
    Status code    : Unset
    Status message :
    Attributes:
    -> http.request.method: Str(GET)
    -> http.response.status_code: Int(200)
    -> url.path: Str(/)
    -> client.address: Str(127.0.0.1)
    -> server.address: Str(python3.12)
    -> server.port: Int(8000)
    -> http.request.body.size: Int(77)
    -> http.response.body.size: Int(696)
    -> http.route: Str(/)```
   
   

i went with detailed for now to see everything, but if you think its too much lmk, we can also make it configurable.
2. should we allow this debugexporter to be used in combination with other exporters? currently its either debug or something like otlp, but not both at the same time.
we can support this but we need to implement some combined exporter or send a slice of exporters to the handling function.

[codecov]

Codecov Report

❌ Patch coverage is 8.33333% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 55.13%. Comparing base (104fdd0) to head (e8ae2f5).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/export/otel/traces.go	0.00%	11 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #881      +/-   ##
==========================================
- Coverage   55.15%   55.13%   -0.02%     
==========================================
  Files         251      251              
  Lines       21481    21492      +11     
==========================================
+ Hits        11847    11849       +2     
- Misses       8818     8828      +10     
+ Partials      816      815       -1     

Flag	Coverage Δ
integration-test	23.34% <8.33%> (+0.08%)	⬆️
integration-test-arm	0.00% <0.00%> (ø)
integration-test-vm-${ARCH}-${KERNEL_VERSION}	?
k8s-integration-test	2.76% <0.00%> (-0.01%)	⬇️
oats-test	0.00% <0.00%> (ø)
unittests	46.24% <8.33%> (-0.02%)	⬇️

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.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[grcevski]

This is great! I would just suggest to maybe call the exporter "console" instead of debug, this is how other OTEL SDKs would do it.

It's a great idea!

[grcevski]

My take on things :)

what Verbosity Level we want for printing?

Detailed as you have it is perfect.

should we allow this debugexporter to be used in combination with other exporters? currently its either debug or something like otlp, but not both at the same time.

It's fine to be one or the other, that's how the SDKs do it. You can define console exporter instead of the HTTP or gRPC and it prints the traces on stdout. Like I mentioned in the review, if we call it console then it will be consistent with the rest of OTEL SDKs.

[NimrodAvni78]

This is great! I would just suggest to maybe call the exporter "console" instead of debug, this is how other OTEL SDKs would do it.

It's a great idea!

since we are using the exporter packages from the collector we are using the debugexporter. is there a reason we are using collector exporters and not sdk exporters?

[NimrodAvni78]

It's fine to be one or the other, that's how the SDKs do it. You can define console exporter instead of the HTTP or gRPC and it prints the traces on stdout. Like I mentioned in the review, if we call it console then it will be consistent with the rest of OTEL SDKs.

in SDKs you can also manage multiple exporters as part of your traceprovider config, i think i can keep it like that as a single one for now, we also had a talk regarding how we can make sure the OBI config conforms to more standard sdk configs, but that can be done in the future

[grcevski]

since we are using the exporter packages from the collector we are using the debugexporter. is there a reason we are using collector exporters and not sdk exporters?

Oh I see what you mean, yeah the collector calls it "debug/traces", I think that works then. I understand the comment about two of them at the same time now too, you mean something like configuring the OTel collector exporters like: exporters: [otlphttp/traces, debug/traces]? I think it's fine. I'm good to merge.