Node Targeting

Node targeting decides which scenarios stay on the coordinator and which are pushed to agents in clustered runs.

What this page helps you do

What this page helps you do

Node targeting decides which scenarios stay on the coordinator and which are pushed to agents in clustered runs.

Who this is for

Teams moving from one machine to coordinator-and-agent execution or tighter workload targeting.

Prerequisites

  • A scenario that already works in a single-node run

By the end

A clearer cluster topology and the fields that must line up across nodes.

Use this page when

Use this page when execution topology, partitioning, or targeting changes how the run should be distributed.

Visual guide

Cluster topology diagram showing the coordinator, agents, and merged result.
Cluster settings matter because the coordinator, agents, and merged result all belong to the same workload definition.

Guide

What node targeting solves

Node targeting lets you run only the scenarios that belong on a given role or node group. This is useful when one set of nodes should publish traffic and another should consume or observe downstream activity.

Available target lists

Use TargetScenarios for a global filter, AgentTargetScenarios for agent-only filters, and CoordinatorTargetScenarios for coordinator-only filters. The runtime compares scenario names using the names you registered in code.

When to keep it simple

If every node can run every scenario, skip targeting and let the coordinator distribute the workload normally. Add targeting only when you need explicit workload ownership.

Cluster setup samples

The sample below keeps both scenario definitions in both processes, then uses CoordinatorTargetScenarios and AgentTargetScenarios to route the right scenario names to the right role.

If you run these examples locally, add a valid runner key before execution starts. Set it with WithRunnerKey("...") or the config key LoadStrike:RunnerKey.

Target Scenarios Per Node

using LoadStrike;

var clusterId = "orders-cluster";
var natsUrl = "nats://nats.example.internal:4222";

var publishOrdersScenario = LoadStrikeScenario.Create(
        "publish-orders",
        _ => Task.FromResult(LoadStrikeResponse.Ok(statusCode: "202")))
    .WithLoadSimulations(LoadStrikeSimulation.IterationsForConstant(1, 2));

var observeCompletionScenario = LoadStrikeScenario.Create(
        "observe-completion",
        _ => Task.FromResult(LoadStrikeResponse.Ok(statusCode: "200")))
    .WithLoadSimulations(LoadStrikeSimulation.IterationsForConstant(1, 2));

var agentContext = LoadStrikeRunner
    .RegisterScenarios(publishOrdersScenario, observeCompletionScenario)
    .WithNodeType(LoadStrikeNodeType.Agent)
    .WithClusterId(clusterId)
    .WithAgentTargetScenarios("observe-completion")
    .WithNatsServerUrl(natsUrl);

// Each agent process listens for the scenario names assigned to agents.
agentContext.Run();

var coordinatorContext = LoadStrikeRunner
    .RegisterScenarios(publishOrdersScenario, observeCompletionScenario)
    .WithNodeType(LoadStrikeNodeType.Coordinator)
    .WithClusterId(clusterId)
    .WithAgentsCount(2)
    .WithCoordinatorTargetScenarios("publish-orders")
    .WithAgentTargetScenarios("observe-completion")
    .WithNatsServerUrl(natsUrl)
    .WithRunnerKey("rkr_your_remote_runner_key");

// The coordinator triggers only its own scenarios and routes agent work by scenario name.
coordinatorContext.Run();

Node targeting fields

WithTargetScenarios(names)

Applies a global scenario-name filter to the current run context.

WithAgentTargetScenarios(names)

Applies an additional scenario-name filter for agent-side work.

WithCoordinatorTargetScenarios(names)

Applies an additional scenario-name filter for coordinator-side work.

Scenario names

Filters are matched against the registered scenario names, so they must use the exact names defined in code.