FWIW @Sushisource , we can't just pass flags through to plumb this, the metric line contains state from both the scenario runner & worker, but they'll be running in separate processes, and in cloud, separate vms.

The prom instance already has the address of the worker, I want to add an /info endpoint to the worker's prom metrics server, which we can query to get the worker's run config at metrics export time.

I also want to separate MetricsOptions into distinct ClientMetricsOptions and WorkerMetricsOptions. They're distinct enough that they don't make sense to share the same logic or flags:

• PromInstanceOptions will only be in ClientMetricsOptions (tie the lifetime of the prom instance to the client, which means its scoped to a scenario. I don't seen any benefit to running a prom instance tied to the worker's lifetime)
• options to setup the /metrics server to WorkerMetricsOptions (I don't see any benefit from capturing the metrics of the scenario runner)

LMK if this makes sense and I'll have the PR up

@THardy98

, I want to add an /info endpoint to the worker's prom metrics server, which we can query to get the worker's run config at metrics export time.

Is this just for reporting it with the tests? Shouldn't we know already because we set it? (I'm not necessarily opposed, just asking).

The separation of types makes sense to me

@THardy98

, I want to add an /info endpoint to the worker's prom metrics server, which we can query to get the worker's run config at metrics export time.

Is this just for reporting it with the tests? Shouldn't we know already because we set it? (I'm not necessarily opposed, just asking).

The separation of types makes sense to me

Yes - it'd be for reporting, but I can see the client having worker config/info being useful generally.

If we spawn the worker and client in separate processes, their configurations are not provided to each other. run-scenario-with-worker is an exception because we spawn both from a single process, so the client has complete information