Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/admbe/FluxOp/llms.txt

Use this file to discover all available pages before exploring further.

Flux provides deterministic VM right-sizing backed by governed telemetry, not heuristics alone. Every VM in your estate receives an explicit coverage state that tells you whether Flux has enough evidence to make a classification — and if not, exactly what is missing. Idle candidates require complete CPU, memory, and bidirectional network evidence before Flux will recommend deallocation. Resize candidates additionally require Azure Advisor to corroborate the target SKU; Flux will not invent a resize target. The result is a conservative, explainable set of candidates rather than an optimistically large list.

Coverage states

Before classifying a VM, Flux determines its coverage state:
StateMeaning
no-dataNo successful telemetry observation for this VM exists
warming-upTelemetry is present but the evidence window is shorter than FLUX_RIGHTSIZING_MIN_WINDOW_DAYS or CPU coverage is below FLUX_RIGHTSIZING_MIN_COVERAGE_PERCENT
partialCPU is covered but network or memory metrics are missing
conflictingAzure Monitor and LogicMonitor disagree materially on CPU p95 (gap > FLUX_RIGHTSIZING_CPU_DISAGREEMENT_PERCENT)
actionableAll required metrics are present, the evidence window is sufficient, and sources agree
A VM in any state other than actionable will not be classified as a candidate. Coverage state is shown on the right-sizing recommendation list and in the resource detail view so you can see exactly which VMs are blocked and why.

Classification criteria

Flux applies two classification paths:

Idle (shutdown candidate)

A VM is classified as an idle candidate when all of the following are true:
  • CPU p95 ≤ FLUX_RIGHTSIZING_IDLE_CPU_P95 (default 5%)
  • CPU maximum ≤ FLUX_RIGHTSIZING_IDLE_CPU_MAXIMUM (default 20%) — this protects periodic workloads that burst briefly
  • Network in p95 ≤ FLUX_RIGHTSIZING_IDLE_NETWORK_P95_BYTES (default 52,428,800 bytes / 50 MB)
  • Network out p95 ≤ same threshold
  • Memory p95 < FLUX_RIGHTSIZING_MEMORY_REVIEW_PERCENT (default 80%) — a high-memory VM is not idle
The target action is Deallocate VM. Flux does not recommend deletion.

Resize candidate

A VM is classified as a resize candidate when all of the following are true:
  • CPU p95 ≤ FLUX_RIGHTSIZING_REVIEW_CPU_P95 (default 30%)
  • Memory p95 < FLUX_RIGHTSIZING_MEMORY_REVIEW_PERCENT (default 80%)
  • Azure Advisor supplies a target SKU for this VM — Flux requires Advisor corroboration and will not generate a resize target independently
  • The VM does not meet the stricter idle criteria above
If CPU p95 is at or below the resize threshold but no Advisor target SKU is available, Flux returns rightsizing_review / target_rate_unavailable rather than inventing a recommendation.

Multi-source reconciliation

When both Azure Monitor and LogicMonitor have telemetry for the same VM, Flux reconciles them using a conservative approach:
1

Compute per-source values

CPU p95, CPU maximum, memory p95, and network p95 are computed independently from each source’s governed summary window.
2

Check for material disagreement

If the CPU p95 values from the two sources differ by more than FLUX_RIGHTSIZING_CPU_DISAGREEMENT_PERCENT (default 20 percentage points), the VM is routed to conflicting / needs_review status instead of being averaged. Averaging disagreeing sources could mask a real workload pattern.
3

Use conservative values

When sources agree within the threshold, the higher (more conservative) value from each metric is used. This means a VM is less likely to be misclassified as idle when one source captures a burst that the other missed.

Telemetry requirements

RequirementDefaultVariable
Minimum evidence window14 daysFLUX_RIGHTSIZING_MIN_WINDOW_DAYS
Minimum CPU sample coverage70%FLUX_RIGHTSIZING_MIN_COVERAGE_PERCENT
Coverage is measured as the proportion of expected hourly CPU observations that are actually present in the governed summary. A VM with sporadic collection (e.g. monitoring agent restarts) will warm up more slowly even if it has been observed for 14 calendar days.
Set FLUX_RIGHTSIZING_MIN_WINDOW_DAYS and FLUX_RIGHTSIZING_MIN_COVERAGE_PERCENT to match your monitoring cadence. If your monitoring agent has known collection gaps, a stricter coverage threshold prevents premature classification.

Configuration reference

VariableDefaultPurpose
FLUX_RIGHTSIZING_MIN_WINDOW_DAYS14Required telemetry evidence window in days
FLUX_RIGHTSIZING_MIN_COVERAGE_PERCENT70Minimum CPU sample coverage for classification
FLUX_RIGHTSIZING_IDLE_CPU_P955Maximum CPU p95 for an idle candidate
FLUX_RIGHTSIZING_IDLE_CPU_MAXIMUM20Peak CPU guardrail protecting periodic workloads
FLUX_RIGHTSIZING_IDLE_NETWORK_P95_BYTES52428800Maximum hourly p95 per network direction (50 MB)
FLUX_RIGHTSIZING_REVIEW_CPU_P9530CPU p95 headroom threshold for resize review
FLUX_RIGHTSIZING_MEMORY_REVIEW_PERCENT80Memory p95 guardrail that prevents automatic action
FLUX_RIGHTSIZING_CPU_DISAGREEMENT_PERCENT20Maximum CPU p95 difference before sources require review

Planning boards

Right-sizing candidates feed into planning boards — human-owned workspaces that turn telemetry-backed findings into purchase decisions (reservations and savings plans).

System board

Flux regenerates the system board from governed evidence every 72 hours. It represents the current deterministic classification of your fleet. Planners should copy the system board before modifying it — the next scheduled regeneration will not overwrite human boards.

Human boards

Planners create copies of the system board (or new empty boards) and then make placement decisions, adjust purchase assumptions, and record rationale. The decision log tracks all changes. Human boards are never overwritten by scheduled regeneration.
The right-sizing proposal regeneration runs as a due-check WebJob daily at 04:05 UTC: if the system board is older than 72 hours, it is regenerated. Administrators can also force an immediate regeneration from Administration without waiting for the scheduled job.
The Ask Flux assistant can only create new empty planning boards (via the create_rightsizing_board tool, after explicit user confirmation). It cannot modify existing boards, change placements, or alter purchase assumptions. Those actions remain human-owned.

LogicMonitor integration

Flux integrates with LogicMonitor as a second telemetry source alongside Azure Monitor:
AspectDetail
AuthenticationBearer token resolved from Azure Key Vault at runtime; never stored in environment variables or pipeline settings
Device discoveryIndependent six-hour WebJob at :10 matches LogicMonitor devices to ARG resource IDs
Metric collectionIncremental 30-minute WebJob, collecting FLUX_LOGICMONITOR_METRIC_BATCH_SIZE (default 12) least-recently-checkpointed devices per run
Raw sample retention30 days (FLUX_LOGICMONITOR_METRIC_RETENTION_DAYS)
Rolling summary window14 days (FLUX_LOGICMONITOR_METRIC_HISTORY_DAYS)
CheckpointsPer-device progress is stored in telemetry_collection_checkpoints so later runs resume without re-reading history
Metrics collectedCPU, memory, disk (up to FLUX_LOGICMONITOR_MAXIMUM_INSTANCES instances per datasource), and network

Build docs developers (and LLMs) love