SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbyted-volcengine-capacity-auditor

byted-volcengine-capacity-auditor

General & other

View repository

Updated 10-15 17:30

About this skill

Volcengine Resource Inspection and Capacity Assessment Skill

Capability Positioning

This Skill is used to consolidate "resource inventory + last 30/90 days monitoring + rule-based assessment + inspection recommendations + trend analysis" into a stable process.

Currently verified scope of V1:

  • ECS: resource inventory, CPU, memory, disk utilization, disk write IOPS
  • CLB: resource inventory, listener-level QPS / 并发连接 / 新建连接 / 带宽 summary (by default attempts to fetch first, explains the reason on failure)
  • ALB: resource inventory, listener-level QPS / 并发连接 / 新建连接 / 带宽 / 丢连接 / HTTP 5xx summary
  • RDS MySQL: resource inventory, current CPU/memory/disk snapshot, last 30 days QPS / ConnUsage

Known boundaries of current V1:

  • CLB Currently by default attempts to fetch listener-level bandwidth, connection count, and QPS summary, but still lacks specification upper limit conversion and more complete metrics, so it first provides factual summaries and pending recommendations, without giving conclusive scaling assessments
  • ALB Currently listener-level traffic and anomaly summaries are integrated, but it remains a conservative assessment; if finer-grained conclusions are needed, listener/rule/server group dimension metrics still need to be supplemented
  • RDS MySQL historical CPU / Mem / Disk monitoring metrics are not fully mapped yet; currently instance snapshot + QPS / ConnUsage is used for the first version of the assessment

If the task is to supplement monitoring metrics or troubleshoot "why metrics cannot be obtained", read references/metric_gaps.md。

Routing Principles

This Skill internally handles two types of requests uniformly, no longer split into two independent skills:

  • Inspection mode: the user wants to first see current resources, utilization, low utilization, and risk points
  • Trend mode: the user has already obtained inspection results, or explicitly wants to see future 7/15/30 day risk, budget direction, scaling timing

If in trend mode, read references/forecasting.md。

Applicable Scenarios

  • Want to quickly inventory the current account's ECS / CLB / ALB / RDS MySQL resources in a certain region
  • Want to see the last 30 days resource utilization and find low-utilization resources
  • Want to output the first version of scaling recommendations or budget optimization recommendations
  • Want to make capacity trend assessments based on the last 30/90 days of data
  • Want to continue assessing future 7/15/30 day risk based on inspection results
  • Want to assess how the entire chain should be scaled based on "next year customer count growth 10% / business volume growth 20% / request increase on a certain link"
  • Want to do monthly inspection, capacity review, resource health check

Inapplicable Scenarios

  • The user requests execution of high-risk resource changes, such as direct shutdown, instance deletion, specification adjustment
  • The user requests accurate CLB capacity forecasting, but the connection/bandwidth/QPS monitoring metrics have not yet been supplemented
  • The user requests strict financial-grade budget forecasting, but there are no price metrics, billing methods, and historical bills

Prerequisites

  1. The current workspace has .env
  2. .env at least includes:
VOLCENGINE_AK=...
VOLCENGINE_SK=...
VOLCENGINE_REGION=cn-beijing
  1. The local Python environment has the Volcengine SDK installed

Default Entry

Prefer to use the built-in script:

python3 <byted-volcengine-capacity-auditor-skill>/scripts/run_capacity_audit.py \
  --env-path ./.env \
  --project-name mysite \
  --region cn-beijing \
  --format markdown

If the user did not provide project-name, by default output the results for the entire region.

For link-level trend judgment, use:

python3 <byted-volcengine-capacity-auditor-skill>/scripts/run_capacity_audit.py \
  --env-path ./.env \
  --project-name mysite \
  --region cn-beijing \
  --mode forecast \
  --growth-factor 0.1 \
  --link-name payment-core \
  --format markdown

If topology artifacts already exist and you want to evaluate the capacity of related resources within the link scope according to the topology link, use this first:

python3 <byted-volcengine-capacity-auditor-skill>/scripts/run_capacity_audit.py \
  --env-path ./.env \
  --region cn-beijing \
  --mode forecast \
  --growth-factor 0.1 \
  --topology-file ./business_topologies/payment-core/topology.json \
  --link-name payment-core \
  --format markdown

Note:

  • After passing in --topology-file , the script will first extract the resources hit within the link from the topology, and then perform capacity evaluation according to the currently supported resource types
  • If --topology-fileis not passed, but business_topologies/<link-name>/topology.jsonexists, the script will automatically narrow the evaluation scope according to that topology
  • The resource types currently supported for topology-based narrowing and participation in capacity evaluation are CLB / ALB / ECS / RDS MySQL
  • This is not only for one fixed link; as long as the corresponding business path exists in the topology, the script will perform whole-chain evaluation according to the supported resources hit by that path
  • Currently, if CLB / ALB is already within the topology link, it will also be included in the whole-chain evaluation; among these, ALB already supports listener-level QPS / 连接 / 带宽 / 丢连接 / HTTP 5xx summary. If key metrics are still missing, the report will clearly mark them as data gaps rather than skipping the entry layer

Output artifacts

By default, output one of two formats:

  • markdown: suitable for direct viewing by users
  • json: suitable for continued consumption by scripts, agents, or subsequent trend judgment processes

Standard workflow

  1. Read .env or the AK / SK / REGION
  2. Pull the ECS / CLB / ALB / RDS MySQL resource inventory
  3. For ECS , pull CPU and memory monitoring for the last 30 days; supplement with recent disk and IOPS summaries
  4. For RDS MySQL , pull the current instance snapshot and the last 30 days QPS / ConnUsage
  5. For CLB , by default attempt to pull listener-level traffic summaries; when they cannot be pulled, explain the billing method, listener protocol, or metric gap; for ALB , output listener-level traffic and anomaly summaries
  6. Output based on threshold rules:
    • low-utilization resources
    • capacity-risk resources
    • recommend scale-in / continue observing / add monitoring
  7. If the user requests trend judgment, then based on existing inspection results continue to provide:
    • future 7/15/30 -day risk
    • high/medium/low confidence
    • budget direction recommendations
    • If the user provides a business growth target (for example, growth in customer count, order volume, QPS, bandwidth, or call volume), first perform link-level scenario modeling to determine which layer is most likely to become the bottleneck first, then give the scaling order
  8. Return the report in a unified structure

The current script entry point already supports:

  • --mode audit: default inspection
  • --mode forecast: link-level trend judgment
  • --growth-factor 0.1: indicates scenario growth 10%
  • --link-name xxx: specify the link name; if a business topology directory with the same name exists, its topology.json
  • --topology-file xxx: explicitly specify the topology file and filter the resources for this evaluation by topology link

Threshold definitions

Read references/thresholds.md。

If the user has not given explicit thresholds, use this set of definitions by default, and do not improvise a different set of rules.

Filling gaps in monitoring definitions

If the user is not simply asking for an inspection, but is asking "why certain monitoring items cannot be obtained and how they should be supplemented," handle it in the following order:

  1. First confirm whether the product already supports CloudMonitor GetMetricData
  2. Then confirm Namespace / SubNamespace / MetricName / Dimensions
  3. If it is visible in the console but the script cannot obtain it, first determine whether the definition is written incorrectly, the dimension is wrong, or the granularity does not match
  4. If the product documentation explicitly states that this metric is not reported, do not continue to assume it can be automatically filled in
  5. When it cannot be filled in, clearly tell the user which conclusions cannot therefore be drawn

When it involves a specific troubleshooting path, read references/metric_gaps.md。

Report structure

By default, output according to the following structure:

# 资源巡检报告
## 摘要
## ECS
## CLB
## RDS MySQL
## 建议清单
## 数据缺口

Explanation rules

  • Give the overall conclusion first, then the breakdown by resource type
  • Clearly distinguish between "verified data conclusions" and "data gaps not yet filled"
  • For metrics that have not been fully connected, do not pretend that the assessment has been completed
  • For downsizing recommendations, prefer conservative wording such as "recommend entering the candidate pool / recommend downgrading after verification", and do not directly assert that downsizing is required
  • For trend conclusions, clearly label "high confidence / medium confidence / low confidence"
  • If there is only 30 days of data, do not make predictions sound too certain

Script resources

  • scripts/run_capacity_audit.py: main entry point, outputs a JSON or Markdown report

Test cases

Refer to evals/evals.json。