Uploaded image for project: 'Distributed Tracing'
  1. Distributed Tracing
  2. TRACING-5973

[Tempo Monolithic] The gateway always forwards OTLP HTTP traffic to the tempo receiver using plain HTTP, regardless of whether receiver TLS is enabled:

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Tempo
    • None
    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • False
    • Tracing Sprint # 285

      Scenario: TempoMonolithic with `multitenancy.enabled: true` (gateway enabled) and `ingestion.otlp.http.tls.enabled: true`.

      Problem: The gateway always forwards OTLP HTTP traffic to the tempo receiver using plain HTTP, regardless of whether receiver TLS is enabled:

      // internal/manifests/monolithic/statefulset.go:478
      args = append(args, fmt.Sprintf("--traces.write.otlphttp.endpoint=http://localhost:%d", manifestutils.PortOtlpHttp))

      When `ingestion.otlp.http.tls.enabled: true` is set, `build.go` configures the receiver with a serving cert (via `configureReceiverTLS` in `configmap.go`), so it expects TLS connections. But the gateway still connects with `http://localhost:4318`, causing `connection reset by peer`:

      level=warn name=observatorium caller=reverseproxy.go:675 msg="httputil: ReverseProxy read error during body copy: read tcp 127.0.0.1:50434->127.0.0.1:4318: read: connection reset by peer"

      OTLP gRPC ingestion through the gateway works fine (port 4317). Only the OTLP HTTP path (port 4318) is affected.

              Unassigned Unassigned
              rhn-support-ikanse Ishwar Kanse
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: