Andrewangeta
commented
3 months ago Could this be related to #26 ?
Open Andrewangeta opened 3 months ago
Andrewangeta
commented
3 months ago Could this be related to #26 ?
slashmo
commented
2 months ago Thanks for bringing this up @Andrewangeta 🙏 The issues you're facing should indeed be caused by our current gRPC support being limited to insecure channels. Have you already tried using the fixes made in #130? Would you still want/need HTTP support in swift-otel even if a secure gRPC connection does the trick for you?
Andrewangeta
commented
2 months ago @slashmo
Yea the ClientConfiguration never took into account a secure endpoint. I went to the exporters
OTLPGRPCLogEntryExporter OTLPGRPCMetricExporter OTLPGRPCSpanExporter
and altered the config setup
+var connectionConfiguration = ClientConnection.Configuration(target: .host(configuration.endpoint.host, port: configuration.endpoint.port),
+ eventLoopGroup: group,
+ tls: .init(configuration: .clientDefault),
+ backgroundActivityLogger: requestLogger)
+if configuration.endpoint.isInsecure {
+ connectionConfiguration = ClientConnection.Configuration.default(
+ target: .host(configuration.endpoint.host, port: configuration.endpoint.port),
+ eventLoopGroup: group
+ )
+}
-var connectionConfiguration = ClientConnection.Configuration.default(
- target: .host(configuration.endpoint.host, port: configuration.endpoint.port),
- eventLoopGroup: group
- )As far as needing HTTP, I suppose someone could have a valid usecase. Currently grafana cloud only accepts HTTP for delivering OTLP to ingest. So someone who opts out of using an otel collector (that can forward HTTP requests) for whatever reason and want a HTTP ingestor/endpoint HTTP seems like a sensible option someone can choose. I'm using an otel collector for my needs so I can get away with GRPC currently.
slashmo
commented
2 months ago Currently grafana cloud only accepts HTTP for delivering OTLP to ingest. @Andrewangeta
Interesting! We could add http/protobuf support in a separate OTLPHTTP target. I prototyped this a while ago, including an OTLP target which brings together both OTLPGRPC and OTLPHTTP to support the OTEL_EXPORTER_OTLP_PROTOCOL variable for dynamically choosing between one or the other.
I'm curious as to what work would need to be done to support HTTP as an additional transport mechanism to GRPC.
Currently I'm setting up otel on iOS and using GRPC fails when sending to a remote otel-collector. funny enough localhost always seems to resolve and push telemetry data but GRPC times out constantly on macOS, iOS and in a swift container image running in docker locally on macOS.
I've isolated the issue to being something specific to GRPC in swift. There's a tool I used to test called otel-cli to verify if the issue was my remote endpoint or not.
Running the following command using the cli on macOS
otel-cli exec --service my-service --name "curl google" curl https://google.com --endpoint otel.example.com:443results in the telemetry data being pushed to theotel-collectorwhich then forwards it to grafana cloud viaotlp/httpand I can see the data in my dashboardDebugging
I've enabled some logging for grpc in iOS and Hummingbird and see the following
Hummingbird in Xcode Logs
iOS Logs
Hummingbird Container Logs macOS
Leveraging HTTP support would help alleviate these issues since it's a valid transport mechanism. Not sure if anyone else has experienced these issues with sending OLTP data over GRPC to a non
localhostendpoint.