Hi Ben,
This is sort of a known issue with the stackdriver surfacer. Cloudprober exports all metrics as counters[1] and stackdriver automatically converts counters into rates for graphing (and alerting I think). That's where the "/s" is coming from. Default latency unit is microseconds so if you're seeing 30,000/s in graphs, that means a cumulative latency of 30ms per second -- if you are running one probe every second, this will mean an average latency of 30ms.
One solution to this problem will be to include units while exporting data to stackdriver, but this will require non-trivial changes to how cloudprober handles metrics and this will benefit only stackdriver surfacer at this point. Can you please file an issue so that this issue is more visible and we can take a stab fixing it in future.
Also, if you're interested in more latency details, I'd suggest using latency distributions. Here is an example of using latency distribution for custom metrics:
Latency distribution can also be enabled for the default latency metric through this option:
Stackdriver handles distributions pretty well.
[1]-Except if you configure them as gauge for external probes' custom metrics.