feat(telemetry): set authority and enable TLS for telemetry backends#7904
feat(telemetry): set authority and enable TLS for telemetry backends#7904zirain merged 6 commits intoenvoyproxy:mainfrom
Conversation
✅ Deploy Preview for cerulean-figolla-1f9435 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
will buff out some platform differences and put ready for review |
24ad81d to
9a121a3
Compare
9a121a3 to
515c74c
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #7904 +/- ##
==========================================
+ Coverage 72.75% 72.78% +0.02%
==========================================
Files 235 237 +2
Lines 35380 35467 +87
==========================================
+ Hits 25742 25813 +71
- Misses 7801 7811 +10
- Partials 1837 1843 +6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
22e960b to
523bfd9
Compare
|
hi folks. I am planning to do a talk at ElasticON on Envoy AI Gateway being able to export data directly to a TLS endpoint (in this case Elastic Cloud). However, until I know if this will merge or not, I can't finalize my outline for the organizers. Can I get a yes or no on this to save insecurity on direction? cc @arkodg |
| } | ||
| // Set GRPC protocol for OTLP | ||
| for _, d := range ds { | ||
| d.Protocol = ir.GRPC |
There was a problem hiding this comment.
Nit, non-blocking: it might be helpful to add a comment to the API to clarify that OTLP is only supported over gRPC.
There was a problem hiding this comment.
I adjusted the code comment. d.Protocol, I might be wrong but is used besides for telemetry, so not sure how to phrase this. we can do that in another PR or you can feel free to push a commit if you can think of a way!
There was a problem hiding this comment.
Also once this is released to Envoy we should be able to implement http transport here. the example yaml there uses logs, metrics and traced, just like the gRPC here does envoyproxy/envoy#43001
There was a problem hiding this comment.
I adjusted the code comment. d.Protocol, I might be wrong but is used besides for telemetry, so not sure how to phrase this. we can do that in another PR or you can feel free to push a commit if you can think of a way!
I mean in the API, not the internal code. Just nit picking, not blocking.
…metrics, tracing, access logs) Sets proper gRPC authority from Service/Backend metadata and enables TLS for Backend resources used by telemetry (metrics, tracing, access logs). This allows direct use of cloud OTLP endpoints like Elastic Cloud, Datadog, etc. without an intermediate collector. Signed-off-by: Adrian Cole <adrian@tetrate.io>
Route backends need AutoSNI to use the Host header for SNI. Telemetry backends (metrics, tracing, access logs) have no Host header and need SNI inferred from the FQDN endpoint. Move SNI inference to the telemetry-specific code in processBackendRefs so route backends get AutoSNI while telemetry backends get inferred SNI. Signed-off-by: Adrian Cole <adrian@tetrate.io>
28322d9
523bfd9 to
28322d9
Compare
Signed-off-by: Adrian Cole <adrian@tetrate.io>
|
adding a preparatory PR to aigw in case we can get this merged at least I can test off main branch all things work envoyproxy/ai-gateway#1774 |
| return rate | ||
| } | ||
|
|
||
| // getAuthorityFromDestination extracts the gRPC authority from a destination setting. |
There was a problem hiding this comment.
@zhaohuabing @zirain what about a BTLSP attaching to a Service
…nvoyproxy#7904) * feat(telemetry): set authority and enable TLS for Backend resources (metrics, tracing, access logs) Sets proper gRPC authority from Service/Backend metadata and enables TLS for Backend resources used by telemetry (metrics, tracing, access logs). This allows direct use of cloud OTLP endpoints like Elastic Cloud, Datadog, etc. without an intermediate collector. Signed-off-by: Adrian Cole <adrian@tetrate.io> * feedback Signed-off-by: Adrian Cole <adrian@tetrate.io> * fix: move SNI inference to telemetry-specific code path Route backends need AutoSNI to use the Host header for SNI. Telemetry backends (metrics, tracing, access logs) have no Host header and need SNI inferred from the FQDN endpoint. Move SNI inference to the telemetry-specific code in processBackendRefs so route backends get AutoSNI while telemetry backends get inferred SNI. Signed-off-by: Adrian Cole <adrian@tetrate.io> * feedback Signed-off-by: Adrian Cole <adrian@tetrate.io> * update-comment Signed-off-by: Adrian Cole <adrian@tetrate.io> --------- Signed-off-by: Adrian Cole <adrian@tetrate.io> Signed-off-by: Sadmi Bouhafs <sadmibouhafs@gmail.com>
What type of PR is this?
feat(telemetry): set authority and enable TLS for telemetry backends
What this PR does / why we need it:
Sets proper gRPC authority from Service/Backend metadata and enables TLS for Backend resources used by telemetry (metrics, tracing, access logs).
This allows direct use of cloud OTLP endpoints like Elastic Cloud, Datadog, etc. without an intermediate collector.
Which issue(s) this PR fixes:
Fixes #
Release Notes: Yes
Testing
See
examples/otel-headersfor a working example with commented-out TLS config.Ran otel-tui on a different port to make sure it can't accidentally receive anything
Used ngrok to route a public TLS endpoint to it
Changed the example yaml to point to that instead of plain text and ran all steps
Noticed connections coming to ngrok

Verified in otel-tui


