Sampling key provisioning/evaluation for local roots

[codefromthecrypt]

Right now, apis exist to evaluate sampling keys provided upstream. #10 looks at this closer to allow for provisioning new keys when you can read an incoming request.

There's a somewhat harder use case, which is when there was no incoming request. To start on this, we need information about the use cases (scheduled activity? client calls?) and if "request" parameters need to be read.

For example, lets say this is a local root. Would provisioning a key need to look at the client request that is about to be made? or would it be fine for it to base solely on out-of-band data?

[connectwithnara]

Interesting.

For example, lets say this is a local root. Would provisioning a key need to look at the client request that is about to be made?

It depends on the rule created. For example, if the rule is match client calls to the db query - select * from table and sample 20%. This means the sampler will need the necessary context to perform a match and then run probability sampler to provision the sampling_key.

[codefromthecrypt]

ok though we have no hook for uninstrumented apps, so this is an interesting use case. For example, most databases have no means to propagate stuff, and so we don't hook in propagation there..

[connectwithnara]

The example I posted is hypothetical. It's a good start and good enough to support just the incoming calls now.

[codefromthecrypt]

ok yeah the easiest path for more is to hook into the "inject" side on clients, and reduce the scope of this configuration to remote-only.

For example, we can configure a fake injector which doesn't actually try to write to mysql, but at least it hooks in. We might have to tentatively locally sample all client requests possibly, then throw them out if they had no sampling keys. The "tentative sample" is a use case of locallySampled when you don't know enough until later.