add opentelemetry trace support

[frzifus]

Adding auto-instr. for gin.

Example

[frzifus]

@bbernhard wdyt? 😄

[bbernhard]

That's a tough one. I mean, I do understand why one might want to have opentelemetry traces, but I also think that a large part of the users (me included) of this software wants to use Signal, because it is focusing on privacy and doesn't collect any metrics. Even though your proposed implementation would be opt-in, I think alone the fact that this would be part of the codebase, would (understandably) raise some eyebrows. Apart from that, I also do not know anything about opentelemetry, so I wouldn't be able to help with issues.

That being said: golang allows to build and load shared objects. (to some degree that's already implemented in the codebase for one specific usecase, see https://github.com/bbernhard/signal-cli-rest-api/blob/master/src/main.go#L325). I could imagine to generalize that concept and allow the loading of arbitrary shared objects from a specific, user defined directory. I don't know if it would actually work, but the idea would be that all the opentelemetry code will be built into a shared object. If someone wants to use that feature, it will grab the code from your repository, build a shared object, put it into a directory and it will be loaded when the application starts. That way there would be a clear separation.

[poggenpower]

I think, you can archive almost the same if your put a reverse proxy in front of the signal service and trace the information there. No code dependencies, no maintenance.

[netwolfuk]

I think, you can archive almost the same if your put a reverse proxy in front of the signal service and trace the information there. No code dependencies, no maintenance.

Yes, that would work for simple incoming REST calls, but you'd also need to do the same for outgoing (I have a webhook configured and run SCRA in RPC mode).

I wonder if that might be possible to "intercept" outbound webhook requests with the plugins feature. However, SCRA metrics (memory usage, etc) and logging would also be useful.

[netwolfuk]

If someone wants to use that feature, it will grab the code from your repository, build a shared object, put it into a directory and it will be loaded when the application starts. That way there would be a clear separation.

This is interesting idea. I don't have go skills, but would love to help test it. Currently, SCRA is the gap in my Otel monitoring.

[frzifus]

...of this software wants to use Signal, because it is focusing on privacy and doesn't collect any metrics. Even though your proposed implementation would be opt-in, I think alone the fact that this would be part of the codebase, would (understandably) raise some eyebrows.

That is actually one of the reasons why I personally like to use Signal. 😃 However, I don't think there's any reason to raise an eyebrow. Tracing is nothing more than distributed and structured logging. Logging itself is enabled by default.

...I don't know if it would actually work, but the idea would be that all the opentelemetry code will be built into a shared object. If someone wants to use that feature..

I think thats actually not going to work. Since we need to accept and propagate some trace information through the system. I tried to play with the opentelemetry auto-instr. for golang. But that comes with issues like requiring root permission.

I think, you can archive almost the same if your put a reverse proxy in front of the signal service and trace the information there. No code dependencies, no maintenance.

That might be valid for just the spans on the router level. I did prefer to propagate the context further to json-rpc service to continue tracing there. I had already partially success to enable tracing.

          env:
            - name: MODE
              value: "json-rpc"
            - name: JAVA_OPTS
              value: "-javaagent:/otel-auto-instrumentation-java-signal-api/javaagent.jar -Dotel.service.name=signal-cli -Dotel.traces.exporter=otlp -Dotel.exporter.otlp.endpoint=http://backend-collector.observability.svc.cluster.local:4317 -Dotel.exporter.otlp.insecure=true -Dotel.traces.sampler=parentbased_traceidratio -Dotel.traces.sampler.arg=1 -Dotel.propagators=tracecontext,baggage -Dotel.instrumentation.common.default-enabled=true -Dotel.instrumentation.okhttp-client.enabled=true -Dotel.instrumentation.jdbc.enabled=true"