Thoughts: Synthetic Transaction Support?

[dmicanzerofox]

My current org (and many previous places i've been a part of) have a need for a tool which can be used to drive synthetic transactions by applying an application level input on a schedule (much like registering a probe :p). This service could measure latency/success of message processing (with a timeout). In my head this service is different from a probe as it would potentially need to support many different application level protocols ie (send a message over cloud pub/sub, kakfa, nsq, sqs, grpc, http/json, etc)

I was imagining that the input would contain a unique id for each synthetic transaction and when the target service is finished processing it would make an RPC call with the transaction status back to this service:

The reason I'm wondering about this in cloudprober is because cloudprober has all the pieces for something like this:

• config system
• scheduling system
• surfacer architecture
• probe architecture

In order for something like above I imagine it would require some additional features like:

• stateful storage of active synthetic transactions
• grpc service for clients to modify synthetic transaction states (ie success/failure/completion)

@manugarg I would love to hear your thoughts on synthetic transactions and if cloudprober might be a home for features like this?

[manugarg]

@dmicanzerofox Sorry, I completely forgot about this. About your proposal, we have internally been talking about adding ad-hoc probe execution capabilities (through a gRPC service) to cloudprober but haven't gotten around to designing and implementing it. Your sounds similar and makes sense to me.

Now that you closed this issue, did you think of some other ways of doing it? :)