synthetic-monitoring-agent

synthetic-monitoring-agent copied to clipboard

Currently we add a custom User-Agent header to make it easier for people on the receiving end of these checks to identify the source as Synthetic Monitoring.

To better handle abuse requests, we should add more information (possibly in the form of headers) to the request so that it's simpler and faster to track the issue down to specific users, e.g.

X-SM-Check-Id: 123 X-SM-Tenant-Id: 1000 (this is redundant) X-SM-Region: prod-us-central-0

we need to balance this against adding too much information (increasing the payload), so maybe:

X-SM-Id: prod-us-central-0/1000/123

I think adding a unique checkID, that includes a number for the probe ID (not a string) , shoudl be sufficiant. X-SM-Id: nnnnnnnn-xxx were nnnnnnnn is the checId, and xxx is the probe ID.

There should be an (internal only) API where the checkID can be translated into the tennant/customer details.

This needs to include the region ID (or use the "global" check ID).

And I think Simon is right, the global check ID (which allows us to identify the API instance) + the probe ID should be more than enough.

We would also need to consider this for k6-backed checks