Skip to content

feat: Add lag/idle plot simulator for cost-based autoscaler - #19687

Open
kfaraz wants to merge 16 commits into
apache:masterfrom
kfaraz:visualize_auto_scaler
Open

feat: Add lag/idle plot simulator for cost-based autoscaler#19687
kfaraz wants to merge 16 commits into
apache:masterfrom
kfaraz:visualize_auto_scaler

Conversation

@kfaraz

@kfaraz kfaraz commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Description

Tuning the lag-based auto-scaler can sometimes be a little involved.

This patch aims to allow making the process simpler by simulating the optimal task count chosen by the auto-scaler under different conditions.

Changes currently in this PR

  • UI code is generated by Claude and may contain mistakes
  • Add a simulate API currently supported for Kafka supervisors only
  • This API creates a CostBasedAutoScaler in "simulate" mode and generates the optimal task count for various input values of lag (based on criticalLag)
  • Add a UI panel in the supervisor dialog which shows up only for "kafka" supervisors
  • Add a single plot between task count vs lag

Web-console screenshot

Screenshot 2026-07-15 at 2 31 16 PM

Other required changes

  • Use a POST API instead of GET so that the current autoscalerConfig may be sent as payload
  • Wire up the UI side so that changes made in the simulate window are reflected in the autoscalerConfig and vice versa
  • Fix up the taskIdleRatio field to accept decimal numbers, currently the field resets to integers
  • Maybe more plots that help the user make a more informed decision
  • Perhaps a plot with the task idleness as well

This PR has:

  • been self-reviewed.
  • added documentation for new or modified features or behaviors.
  • a release note entry in the PR description.
  • added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
  • added or updated version, license, or notice information in licenses.yaml
  • added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
  • added integration tests.
  • been tested in a test Druid cluster.

@kfaraz
kfaraz requested a review from Fly-Style July 15, 2026 08:50
}

@GET
@Path("/{id}/autoscaler")

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will rename this API based on what we decide the final result set to look like:

Suggested change
@Path("/{id}/autoscaler")
@Path("/{id}/autoscaler/simulate")

Comment on lines +544 to +548
@QueryParam("taskCountMin") int taskCountMin,
@QueryParam("taskCountMax") int taskCountMax,
@QueryParam("maxProcessingRatePerTask") int maxProcessingRatePerTask,
@QueryParam("optimalTaskIdleRatio") double optimalTaskIdleRatio,
@QueryParam("criticalLag") int criticalLag,

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of multiple query params, we should just be able to send a POST payload object as a CostBasedAutoScalerConfig.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 9e550b2

@Fly-Style
Fly-Style requested a review from vogievetsky July 20, 2026 07:46
@Fly-Style
Fly-Style marked this pull request as ready for review July 24, 2026 09:04
@QueryParam("maxProcessingRatePerTask") int maxProcessingRatePerTask,
@QueryParam("criticalLag") int criticalLag,
@QueryParam("currentTaskCount") Integer currentTaskCount,
@Context HttpServletRequest request

@FrankChen021 FrankChen021 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity Findings
P0 0
P1 1
P2 2
P3 0
Total 3

Reviewed 11 of 11 changed files.


This is an automated review by Codex GPT-5.6-Sol

requestedTaskCount,
((SeekableStreamSupervisor<?, ?, ?>) supervisor).getIoConfig().getTaskCount()
);
InvalidInput.conditionalException(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Bound the simulation task counts at the API boundary

The request body can set taskCountMin to zero, which the config constructor accepts; with a positive live task count this reaches computeValidTaskCounts and divides by zero. It can also set an arbitrarily large taskCountMax, which is reused as partitionCount and makes each of the 40 samples scan linearly through that range, allowing an authorized request to monopolize the Overlord CPU. Require a positive minimum and impose a practical maximum before running the simulation.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

);

// Assumption: enough partitions to reach taskCountMax.
final int partitionCount = config.getTaskCountMax();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Simulate the supervisor's actual topology

The live cost scaler uses supervisor.getPartitionCount() and the supervisor IO config's task duration, but this endpoint substitutes taskCountMax and a hard-coded hour. For example, a two-partition supervisor configured with a maximum of ten is shown recommendations that cannot run, and a custom task duration changes the lag-recovery cost curve. Read both values from the selected supervisor so the chart predicts what its scaler would actually choose.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is under user control; let them play.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These values are not currently user-controlled: the panel/API do not expose partition count or task duration; they derive partition count from taskCountMax and fix duration at 3600 seconds. Thus a two-partition supervisor can still show impossible recommendations up to 10 tasks, and non-hour task durations produce a different curve. Please either read both from the selected supervisor, or expose them as explicit simulator inputs and label the assumptions.

Reviewed 11 of 11 changed files.

final int lagStepSize = criticalLag / 20;
final CostBasedAutoScaler autoscaleSimulator = CostBasedAutoScaler.createSimulator(config, supervisorId);
for (int i = 0; i < 40; ++i) {
final double observedAggregateLag = lagStepSize * i * 1.0;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Avoid overflowing the generated lag values

lagStepSize * i is evaluated as int before conversion to double. Large but valid criticalLag query values therefore wrap to negative lag in later samples, producing nonsensical task-count recommendations. Promote either operand before multiplying, or keep the calculation in long/double throughout.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Fly-Style
Fly-Style requested a review from FrankChen021 July 24, 2026 14:06

@FrankChen021 FrankChen021 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity Findings
P0 0
P1 0
P2 1
P3 0
Total 1

The task-count bounds and lag-overflow findings are addressed. A separate inline reply covers the remaining topology-assumption discussion.

Reviewed 11 of 11 changed files.


This is an automated review by Codex GPT-5.6-Sol

avgProcessingRatePerTask,
maxProcessingRatePerTask * 1.0
);
final int optimalTaskCount = autoscaleSimulator.computeOptimalTaskCount(costMetrics);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Suppress production logs for simulation samples

computeOptimalTaskCount emits an INFO metrics line on every call and often a second candidate-table INFO line. This loop calls it 40 times per API request, while the panel issues requests after debounced edits, so ordinary simulator use floods Overlord logs with at least 40 entries per edit. Gate these logs for simulator instances as metrics already are.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 9d7e9c1

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks—the panel's default payload now suppresses the original computation/candidate logs and metrics. One INFO path remains outside !isSimulation at CostBasedAutoScaler.java:380: a positive minCostDropPercentForScaling can still log for simulation samples. Please gate that log too.

Reviewed 11 of 11 changed files.

@kfaraz

kfaraz commented Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

@Fly-Style , there is a merge conflict. Also, the patch currently seems broken. The request being sent by the web-console is a malformed JSON and throws a 400 error. Would you be able to take a look?

@Fly-Style

Copy link
Copy Markdown
Contributor

@kfaraz 5c53c26

@FrankChen021 FrankChen021 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity Findings
P0 0
P1 1
P2 1
P3 0
Total 2

Reviewed 11 of 11 changed files.


This is an automated review by Codex GPT-5.6-Sol

@Fly-Style
Fly-Style requested a review from FrankChen021 August 3, 2026 10:21
@Fly-Style

Copy link
Copy Markdown
Contributor

@vogievetsky please review :)
Your review is decisive

@kfaraz

kfaraz commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

Please don't merge this just yet, there are a few more tweaks required in the API.

@FrankChen021 FrankChen021 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity Findings
P0 0
P1 0
P2 2
P3 0
Total 2

Reviewed 11 of 11 changed files. Both prior critical-lag findings are resolved; this update still has read-only authorization and simulation log-volume problems.


This is an automated review by Codex GPT-5.6-Sol

@Path("/{id}/autoscaler")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
@ResourceFilters(SupervisorResourceFilter.class)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Authorize the read-only simulation as READ

SupervisorResourceFilter derives authorization from the HTTP method, so this POST requires DATASOURCE WRITE permission. The endpoint only computes and returns a plot, while the new tab is exposed to users who can view Kafka supervisors; read-only operators therefore see the tab but every simulation request is rejected. Use a READ-specific authorization path or filter for this read-only POST.

avgProcessingRatePerTask,
maxProcessingRatePerTask * 1.0
);
final int optimalTaskCount = autoscaleSimulator.computeOptimalTaskCountInternal(costMetrics, true);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Suppress threshold logs during simulation

Passing true suppresses the main computation log and metrics, but computeOptimalTaskCountInternal still emits INFO messages for every high- or critical-lag point. With the 40-row sweep and the submitted threshold, a single request emits roughly 25 INFO lines, and the UI issues another request after each debounced input change. Guard the high/critical threshold logs with simulation mode as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants