Feature request:
Add a per-piece download duration metric broken out by traffic source, download_piece_duration_milliseconds labeled by type (LOCAL_PEER, REMOTE_PEER, BACK_TO_SOURCE).
Today, download_task_duration_milliseconds only reports latency at the whole-task level, and its task_type label is the TaskType enum (STANDARD/PERSISTENT/PERSISTENT_CACHE/CACHE), not the traffic source. The traffic-source distinction (TrafficType) already exists on the byte-counter metric download_traffic, but there's no equivalent duration/histogram metric, so there's currently no way to answer "is p2p actually faster than back-to-source for us?" from metrics alone.
Use case:
We run Dragonfly client fleets and want a Grafana panel showing p50/p95/p99 download latency split by traffic type, to answer questions like:
- Is p2p delivering the latency improvement we expect over back-to-source?
- Are local-cache hits actually near-zero latency, or is something adding overhead there?
- When back-to-source latency spikes (e.g. origin having a bad day), can we see that in isolation from p2p latency, instead of it being blended into a single task-level number?
Right now the closest proxy is backend_request_duration_milliseconds (back-to-source only, no p2p/local equivalent) plus dragonfly_scheduler_download_piece_finished_total{traffic_type=...} (a count, not a duration) — neither gives latency split cleanly across all three traffic types in one place.
UI Example:
Not a CLI/command change — this is a new Prometheus metric exposed on the existing /metrics endpoint. Example output once implemented:
# HELP dragonfly_client_download_piece_duration_milliseconds Histogram of the download piece duration.
# TYPE dragonfly_client_download_piece_duration_milliseconds histogram
dragonfly_client_download_piece_duration_milliseconds_bucket{type="LOCAL_PEER",le="1"} 42
dragonfly_client_download_piece_duration_milliseconds_bucket{type="REMOTE_PEER",le="8"} 17
dragonfly_client_download_piece_duration_milliseconds_bucket{type="BACK_TO_SOURCE",le="64"} 5
Which would let us query, e.g.:
histogram_quantile(0.95, sum(rate(dragonfly_client_download_piece_duration_milliseconds_bucket[5m])) by (le, type))
Feature request:
Add a per-piece download duration metric broken out by traffic source, download_piece_duration_milliseconds labeled by type (LOCAL_PEER, REMOTE_PEER, BACK_TO_SOURCE).
Today, download_task_duration_milliseconds only reports latency at the whole-task level, and its task_type label is the TaskType enum (STANDARD/PERSISTENT/PERSISTENT_CACHE/CACHE), not the traffic source. The traffic-source distinction (TrafficType) already exists on the byte-counter metric download_traffic, but there's no equivalent duration/histogram metric, so there's currently no way to answer "is p2p actually faster than back-to-source for us?" from metrics alone.
Use case:
We run Dragonfly client fleets and want a Grafana panel showing p50/p95/p99 download latency split by traffic type, to answer questions like:
Right now the closest proxy is backend_request_duration_milliseconds (back-to-source only, no p2p/local equivalent) plus dragonfly_scheduler_download_piece_finished_total{traffic_type=...} (a count, not a duration) — neither gives latency split cleanly across all three traffic types in one place.
UI Example:
Not a CLI/command change — this is a new Prometheus metric exposed on the existing /metrics endpoint. Example output once implemented:
Which would let us query, e.g.: