synthetic-monitoring-agent

synthetic-monitoring-agent copied to clipboard

First in line for restricting scripted/browser checks to enabled probes.

ScriptedChecksEnabled will be sent to the API when calling RegisterProbe - the API will read this and mark the probe as capable of executing scripted checks.

sm.Probe.K6Enabled is named after the database field we're adding in the migration -- see migration PR.

Open to changing the naming - I went back and forth between K6 and Scripted checks. In my mind, K6 covers both browser checks + scripted checks as two different points of focus but maybe we should just call both scripted.

Looking at the other PR (https://github.com/grafana/synthetic-monitoring-agent/pull/675), I'm thinking that whether or not a probe is allowed to run scripts is something that should be set the API level (because the probe is created and available before it connects to the API). The API should tell the probe "you are supposed to run scripts" and the probe can validate that the feature flag is set (or that it's able to run k6, because the binary is available, or it's been provided with a URL for the runner).

So I think the proto message should be extended to include that info, and the API should be extended so that a probe is eligible for running k6 checks or not.

Looking at the other PR (#675), I'm thinking that whether or not a probe is allowed to run scripts is something that should be set the API level (because the probe is created and available before it connects to the API). The API should tell the probe "you are supposed to run scripts" and the probe can validate that the feature flag is set (or that it's able to run k6, because the binary is available, or it's been provided with a URL for the runner).

So I think the proto message should be extended to include that info, and the API should be extended so that a probe is eligible for running k6 checks or not.

I think that having the API determine if the probe should run the check or not will add some UI overhead and also some friction in toggling this for a probe.

Here are a few of my thoughts:

• Having the probe opt-in via its config (ProbeInfo) upon registration is more flexible - otherwise, I would have to create a 'new probe' on the API and change my token to toggle scripted checks execution.
• It's easy to toggle on/off for our public clusters by updating the config (see this PR).
• We already update probe info in the DB when probes (re)connect to the API, so there's not significant new overhead introduced by making this field reflect the probe's runtime config.

I figure it makes sense regardless to do the same set of validations on a probe if someone enables Feature.K6 on it, but maybe I'm missing something with that.

Edit: though I think if we want some probes to have K6 enabled (i.e. for MultiHTTP checks) but not perform more complex scripted checks, we could add a separate flag for this enablement.

EDIT (4/15/24): we're going with an API-driven implementation - resolving prior threads and updating PR.