[Feature request]: Preserve 'traceparent' received on inbound requests to preserve telemetry context
Open5GS Release, Revision, or Tag
v2.7.5
Steps to reproduce
I'm implementing an opentelemetry tracing solution based on side containers that export Open5GS HTTP2 signaling telemetry to Jaeger. For correlation (context) purposes it's required that NF outgoing messages maintain the 'traceparent' header received on inbound request.
For example, given the following request
Request nudm-uecm flow consisting in communication from SCP -> UDM -> SCP -> UDR
My solution is injecting the 'traceparent' header in the outbound request from SCP to UDM but the UDM is not keeping this header on the resulting request from UDM -> SCP -> UDR hence tracing context is lost and this flow will be displayed as separate traces in Jaeger which limits tracing core correlation functionality
The request for Open5GS is: would it be possible for NFs to store the 'traceparent' HTTP2 header received in an incoming requests and send in the resulting outgoing message?
Thanks Gustavo
Logs
Expected behaviour
If present, the Open5GS NFs will use the received 'traceparent' header on outgoing requests
Observed Behaviour
Outgoing request ignore the received 'traceparent' header
eNodeB/gNodeB
No response
UE Models and versions
No response
Hi @gustavobsch ,
Firstly, I don't think this is a bug, but rather a new feature request. Secondly, if you can wait a few days, I can provide a branch/pull request that has OpenTelemetry enabled, together with sending traceparent field and sending HTTP requests to OpenTelemetry collector (Jaeger).
Regards Bostjan
Hi @Bostjan
Correct, is not a bug, I fixed the tittle. I can wait for sure, thanks for looking into this.
Thanks Gustavo
@bmeglic . Just wanted to confirm this is being looked at, thanks
@gustavobsch Yes, it's gonna take me until some time next week.
@gustavobsch Just to give you an update, you can checkout the "work-in-progress" for OpenTelemetry at https://github.com/bmeglic/open5gs/tree/opentelemetry . I do have an issue where it seems there is a memory leak with TraceData, but I can't yet pinpoint the cause.
Regards Bostjan
@bmeglic appreciate your work
I think I'm doing something wrong, I can compile that branch but then when I run open5gs NF they show version v2.4.5 and tracing is not working. What I am doing wrong?
$ apt install python3-pip python3-setuptools python3-wheel ninja-build build-essential flex bison git libsctp-dev libgnutls28-dev libgcrypt-dev libssl-dev libidn11-dev libmongoc-dev libbson-dev libyaml-dev libnghttp2-dev libmicrohttpd-dev libcurl4-gnutls-dev libnghttp2-dev libtins-dev libtalloc-dev meson protobuf-compiler libprotoc-dev
$ git clone https://github.com/bmeglic/open5gs.git
$ cd open5gs/
$ git checkout opentelemetry
$ git checkout 140c57c
$ meson build --prefix=/
open5gs 2.7.6
Subprojects
freeDiameter : YES 1 warnings
opentelemetry-cpp : YES 2 warnings
prometheus-client-c: YES
User defined options
prefix : /
$ ninja -C build
$ cd build/
$ ninja install
$ cat /tmp/scp.yaml | head -n 1
trace_uri: http://jaeger-collector.telemetry:4318/v1/traces
$ open5gs-scpd -c /tmp/scp.yaml
Open5GS daemon v2.4.5-1283-g140c57c
07/23 20:04:50.015: [app] INFO: Configuration: '/tmp/scp.yaml' (../lib/app/ogs-init.c:146)
@gustavobsch I have updated the branch.
Have you managed to start the new core? I am assuming that you already have another Open5GS core installed on your system, which takes precedence based on your PATH.
What about if you start SCP with absolute path? For example: (location of Open5GS sources)/build/src/scp/open5gs-scpd -c ...?
I checked out 8432ee3 and re-compiled again this time from inside a fresh docker container but the issue remains. I can see all the libopentelemetry stuff built and installed but when I launch the Open5gs binary from src folder I still see v2.4.5
root@6adafeff1de3:/open5gs/build# head -n1 configs/open5gs/scp.yaml
trace_uri: http://localhost:4318/v1/traces
root@6adafeff1de3:/open5gs/build# ls /usr/lib/libopentelemetry_*
/usr/lib/libopentelemetry_common.so /usr/lib/libopentelemetry_exporter_otlp_http_client.so /usr/lib/libopentelemetry_proto.so
/usr/lib/libopentelemetry_exporter_in_memory.so /usr/lib/libopentelemetry_exporter_otlp_http_metric.so /usr/lib/libopentelemetry_resources.so
/usr/lib/libopentelemetry_exporter_ostream_metrics.so /usr/lib/libopentelemetry_http_client_curl.so /usr/lib/libopentelemetry_trace.so
/usr/lib/libopentelemetry_exporter_ostream_span.so /usr/lib/libopentelemetry_metrics.so /usr/lib/libopentelemetry_version.so
/usr/lib/libopentelemetry_exporter_otlp_http.so /usr/lib/libopentelemetry_otlp_recordable.so
root@6adafeff1de3:/open5gs/build# src/smf/open5gs-smfd
Open5GS daemon v2.4.5-1288-g8432ee3
07/24 07:25:41.901: [app] INFO: Configuration: '/etc/open5gs/smf.yaml' (../lib/app/ogs-init.c:146)
07/24 07:25:41.901: [app] INFO: File Logging: '/var/log/open5gs/smf.log' (../lib/app/ogs-init.c:149)
Can you share the steps you use to compile / install?
Thanks Gustavo
cd docker && docker compose run dev
cd /mnt/ (<path to open5gs sources)
meson build
ninja -C build
This issue has been marked as stale because there has been no recent activity on it. If there is no further activity, it will be closed. The Open5GS team is a small but dedicated team with limited resources and may not be able to address every issue directly. Do not attempt to circumvent this by 'bumping' the issue; doing so will result in it's immediate closure and possibly your exclusion from participating in any future discussions.
This issue has been marked as stale because there has been no recent activity on it. If there is no further activity, it will be closed. The Open5GS team is a small but dedicated team with limited resources and may not be able to address every issue directly. Do not attempt to circumvent this by 'bumping' the issue; doing so will result in it's immediate closure and possibly your exclusion from participating in any future discussions.