Is End-to-End Mobile-to-Backend Tracing Worth the Risk of a Public Ingest Endpoint?

The unified waterfall is valuable mainly for breaking down the latency budget. It can show whether an issue is in the mobile network or your backend. For backend errors, throughput, and server-side p99s, your existing backend traces already provide most of what you need.

Be especially cautious about mobile attributes such as app version, device model, operating system, carrier, and locale. Those values can create huge cardinality if they reach the Tempo index. Strip or normalize them at the collector, retaining essentials like trace_id, span_id, HTTP status, and perhaps a controlled session identifier. Keep dashboards useful even when client spans are missing because older app versions, offline devices, battery-saving modes, and sampling will create gaps.

I'd ingest the client spans, but keep them in a separate pipeline and join them to backend traces with the trace_id when querying. That gives you the end-to-end view without allowing noisy or malformed mobile data to interfere with the main backend trace pipeline.

A sacrificial Alloy gateway is a good pattern if it has a hard memory limit, bounded queues, aggressive sampling, and no ability to backpressure your core telemetry or API systems. Also avoid exposing raw OTLP directly. Put a gateway in front that handles TLS, rate limiting, token validation, and coarse filtering. Per-device or per-token limits are generally more useful than per-IP limits.

The biggest benefit is seeing the latency across the mobile-to-backend boundary. Without client spans, it can be difficult to tell whether a delay comes from the device, DNS, TLS, the carrier network, or your API. Just be careful with timing: device clocks drift, so anchor important timing on the server and treat client-side timings as approximate.

Treat the endpoint as an untrusted, unauthenticated ingestion service. Put a CDN, WAF, or gateway in front of it rather than exposing a collector directly. Short-lived tokens issued after app attestation, such as App Attest or Play Integrity, can make abuse harder and allow limits per device or token instead of per IP. Carrier NAT makes IP-only limits unreliable.

Most importantly, telemetry must be shedable. Isolate the ingest path from production APIs, use bounded buffers and memory limits, and drop data under pressure before it can affect Tempo or application traffic. The worst case should be reduced observability, not a degraded product.

I wouldn't treat this as a special DDoS problem so much as another public ingestion API that needs normal edge protection. A determined attacker can control a client and send fake telemetry, so perfect authenticity is impossible. The practical goal is to make abuse expensive, bound the resource usage, and ensure the telemetry path cannot cascade into application traffic.

Use rate limiting and filtering at the edge, isolate the infrastructure, and accept that some data will be dropped or poisoned. Properly formed junk telemetry may not be likely, but an attacker can still generate enough volume to increase storage and processing costs, so budget and cap those independently.