Skip to content

PATTERN Cited by 1 source

Edge proxy as telemetry collector ingress

Problem

Browser-side observability requires sending telemetry (spans, metrics) from a customer's browser on the public internet to an internal collector. Three structural problems arise:

  1. The collector is typically in the private cluster with no public endpoint.
  2. Opening a new public endpoint for telemetry expands attack surface: abuse / scraping / DDoS on the ingest path.
  3. The browser SDK's exporter needs to authenticate or at least be rate-limited so a rogue client can't overwhelm the collector.

Server-side observability never faces this — server services run in the same cluster as the collector and speak over internal networks.

Solution

Reuse an existing edge proxy (the one already terminating public customer traffic) as the ingress path for browser telemetry. The proxy:

  • Routes telemetry requests from the public internet to an internal collector endpoint that stays private.
  • Applies rate-limits configured as endpoint protection so a single client (or bot) can't saturate the collector.
  • Applies existing auth / WAF / observability layers the customer-facing path already has.

The proxy is already hardened, already scaled, already monitored. Reusing it for telemetry adds one routing rule and one rate-limit policy, not a new public service.

Zalando instantiation

Zalando routes browser telemetry through Skipper — the same edge proxy that fronts the web shop — to the internal collector. Rate-limits are configured on the Skipper route as endpoint protection. Source: sources/2024-07-28-zalando-opentelemetry-for-javascript-observability-at-zalando:

We used our edge proxy (Skipper) to route frontend telemetry to an internal collector. This also allowed us to implement certain endpoint protection measures like rate-limits.

Zalando also publishes a template for other applications that want to deploy a proxy-to-collector topology without sharing the main Skipper instance — the pattern is productised for the internal fleet.

When to use this pattern

  • You have a browser / mobile / edge client that needs to export telemetry to a collector behind a private network.
  • You already run an edge proxy (Skipper, Envoy, nginx, Cloudflare Workers, AWS ALB / CloudFront) on the customer- facing path.
  • You need rate-limiting and abuse protection on the ingest path and the edge proxy already provides those primitives.

When not to use this pattern

  • If your edge proxy is latency-sensitive and the extra routing rule adds measurable overhead. Browser telemetry via sendBeacon is designed to be low-priority so this is rarely an issue, but worth measuring.
  • If your telemetry needs direct-to-collector TLS (e.g. cert pinning, client certs); proxy termination breaks that.
  • If the edge proxy doesn't support the telemetry protocol (e.g. OTLP-gRPC — most HTTP-only edge proxies won't route this; use OTLP-HTTP instead, as Zalando does).

Failure modes

  • Telemetry storms counted as customer traffic — the ingest path hits the edge proxy's main request-per-second quota if you don't carve out a separate rate-limit bucket for the telemetry route.
  • Rate-limit too aggressive — if a legitimate page load emits 20+ telemetry requests (page-load-trace + subresource-fetches + vitals) the rate-limit designed for "one request per page" will false-positive drop. Baseline against per-page-load telemetry emission volume.
  • GDPR consent leakage — rate-limits alone don't gate consent; per-export consent check must live in the SDK, not at the proxy, because the proxy can't know the user's consent state.

Sibling patterns

Seen in

Last updated · 550 distilled / 1,221 read