Thanks for sharing, @BlueSeaOcean! That's interesting. I guess in your probe you must be building a SAML assertion and posting to an HTTP endpoint. I've thought about implementing this in cloudprober as my current employer had similar requirements, but I was not sure if it was a common use case. I'll think more about it now :)

Are you using Cloudprober at work? If yes, and if it's okay, can you please share your organization's name.

One thing to add, I am also using proxy probe although it is not used as much as http probe at the moment. I imagine supporting authentication would be a common use case. For example, you may want to probe internal jira not only to check if the jira instance is up and running, sometimes you also want to check if your account still have access to it.

Yes, I am using at work. I'm not sure if I am supposed to disclose the name. It's an investment bank.

I imagine supporting authentication would be a common use case. For example, you may want to probe internal jira not only to check if the jira instance is up and running, sometimes you also want to check if your account still have access to it.

I agree. I wonder if you know about the OAuth based authentication option for HTTP probes: https://cloudprober.org/docs/config/oauth/. Basically you can add oauth_config stanza to an HTTP probe to do OAuth based authentication. It can be used to get a new access token using username-password, or a refresh token issued previously. Quite a few API based services support OAuth based authentication now, e.g. Google, Robinhood, Meta, etc. I should probably write a how-to page on how to use OAuth authentication with HTTP probes.

Yes, I am using at work. I'm not sure if I am supposed to disclose the name. It's an investment bank.

No worries. Thanks for sharing the industry.

I didn't know that and I also built oauth authentication in the extension too! Let me know if you have the document ready.

Hello @krzee, you can get metrics for individual runs instead of cumulative metrics by setting export_as_gauge surfacer config field to true: https://cloudprober.org/docs/surfacers/overview/#modifying-metrics. Even with GAUGE metrics the best way to get accurate latency is to divide latency by success. If you don't want to do that, you'll need to do the following to make sure your metrics are for single run:

• If your probe interval is <10s, set stats_export_interval_msec to same value as interval_msec.
• Some probes still do more than 1 request (or packets) per run, e.g. PING probe sends 2 packets in every run -- you can change packets_per_probe in the ping probe config to get latency for absolutely single packet: https://cloudprober.org/docs/config/latest/probes/#cloudprober_probes_ping_ProbeConf

interesting! thank you! I will play with this.

I have rolled this out and its working exactly as i hoped and is already shedding light on new information!
Thank you! Both for helping me understand the options to use, and also for making this great prober!