UDP configurable payload

[momoXD007]

The current version of the UDP prober sends the hardcoded payload "cloudprober".
However, in practice there are many applications UDP that will simply drop a packet like that, which basically means one has to change the application to make it "probable" with cloudprober.
The source code udp.go in lines 44 ff. even lists this inline as an open todo.

In my case it would help me with a set of applications that only answer udp probes if they contain specific payload. Without this change cloudprober is not an option to monitor these applications.

[manugarg]

Sure, this should be an easy change. I'll submit the fix soon.

[manugarg]

@momoXD007 and @tarrychk,

I probably spoke to too soon. We don't send a simple payload, but we send a message with payload. Message contains endpoints, timing data, and payload. If you just change the "inner payload", your UDP server will likely still not recognize the packet.

To give you some background, this probe was written primarily for detecting network issues. Cloudprober comes with a UDP server that this probe can work with: https://github.com/cloudprober/cloudprober/tree/master/servers/udp. This is what we did at my previous job (Google).

I was wondering what kind of apps you had in mind, and what kind of payloads do they expect. We may need another probe type to probe these apps. We may also try just modifying this probe, but getting more context from your side will help figure out the best way for this.

[manugarg]

@momoXD007 wondering if you got a chance to look at my last message.

[momoXD007]

One IPsec Gateway I saw, expects “Ping“ as payload for its UDP healthcheck and sends “Pong” back. A neat test to see if it works.

I imagine many applications that use UDP would implement a similar mechanism. But it is just an “educated guess”.