Read the per-VM series from telegraf, not monasca

[Eandalf-Bigstack]

What type of PR is this?

/kind bug

Which issue(s) this PR fixes?

Part of bigstack-oss/cubecos#772 — specifically bigstack-oss/cubecos#769 (COS UI > Home > Chart page after the OpenStack and InfluxDB upgrade) and bigstack-oss/cubecos#771 (COS UI > Home > Health page).

What this PR does?

Repoints twelve Flux queries from the monasca bucket to telegraf. Six history queries in internal/cubecos/metric.go and six Top-Instances rank queries in internal/apis/v1/handlers/metrics/stmt.go.

bigstack-oss/cubecos#672 removed monasca. The consequence differs by install type, and the upgrade case is the worse one:

• fresh install — the monasca bucket does not exist, so every per-VM chart and rank in the UI comes back empty
• upgraded cluster — migrate_monasca_retire deliberately keeps the InfluxDB database so an operator can still read history. So the queries succeed and silently return data frozen at the upgrade moment

hex_sdk instance_metrics_collect writes the replacement series and was written as a drop-in: same measurement names, same tag names, same field name. Only the database moved. So this is a bucket rename and nothing else — no measurement, tag, field or unit changes in any of the twelve.

Two other monasca leftovers go with it:

• the monasca entry in the metrics module group (module.go), matching the group list in CubeCOS' cli_cluster.cpp — prometheus and thanos already moved out to metricsDb, this is the rest of that change
• MonascaDebugEnabled and its role mapping (tuning.go), a tuning for a service with nothing left to configure

Test results (optional)

1). make sure the api docs have been updated

api/docs.json regenerates from the bumped submodule with zero monasca and zero senlin references. It is not tracked, but api/docs.go embeds it with go:embed, so it does reach the binary — the two builds differ in size accordingly.

2). make sure the api works properly

Verified against live clusters, not by inspection.

Query level — running the exact statement these builders generate against bucket: "telegraf" on jim-1cc returns every tag the queries rely on:

_value 0.282257, _field value, _measurement vm.cpu.utilization_norm_perc,
resource_id e1997ae2-…, tenant_id 6e6449b…, tenant_name admin, vm_name p3test-vm

resource_id and vm_name are what the rank queries group by; device is present on vm.io.* and vm.net.* for the storage and network queries.

Endpoint level — binary built from this branch and staged on jim-1cc and all three accept-3cc controllers (/usr/local/bin/cube-cos-api, service active on :8082). Each node independently reports 0 monasca/senlin strings and 12 from(bucket: "telegraf") references — exactly the twelve queries changed. Calling the real endpoints with a keystone token:

endpoint	result
GET /api/v1/datacenters/cc1/metrics/cpuUsage/rank/vms	200 — p3test-vm, value 0.3041, full history series
GET /api/v1/datacenters/cc1/metrics/memoryUsage/rank/vms	200 — p3test-vm, value 17.4731, full history series

The memory figure is worth noting: 17.47% matches monasca's usable-based definition rather than the ceilometer one (~26%), so the numbers the UI draws keep their meaning, not just their shape.

hex_cli -v -c cluster check remains 28/28 OK on both labs after the swap.

This PR needs

• Drop monasca and senlin from the schema cube-cos-openapi#112 — the schema half. This branch pins the submodule at that PR's head (3d9065d); it wants re-pinning to the merged SHA before this lands.

🤖 Generated with Claude Code

[SekiXu]

Approving. This is the cube-cos-api half of the blocker I raised on cubecos#1457, and it covers it completely.

Verified on this branch rather than from the write-up:

• All twelve are changed — six in internal/apis/v1/handlers/metrics/stmt.go and six in internal/cubecos/metric.go — and git grep -i monasca over the branch returns nothing outside the submodule.
• The module.go and tuning.go removals are symmetric with the product side: cubecos#1457 deletes config_monasca.cpp, which carries CONFIG_TUNING_BOOL(MONASCA_DEBUG, "monasca.debug.enabled", ...) with it. So the tuning disappears from both ends together rather than leaving one side advertising a key the other no longer accepts.
• The measurement, tag and field names are untouched, which is what makes this a bucket rename and nothing more.
• The submodule pins 3d9065db, which is cube-cos-openapi#112's head. That PR is a clean fast-forward from its develop, so a true ff merge lands develop on exactly that SHA and this pin is already correct — no re-pin needed unless the merge is not a fast-forward.

One sequencing constraint beyond the three-repo order. This must not reach a build ahead of cubecos#1457. On cubecos/develop the six vm.* measurements are written only by monasca-agent's libvirt plugin, into the monasca bucket — instance_metrics_collect, which writes them to telegraf, exists only on that branch. An ISO carrying this without #1457 leaves all twelve endpoints reading a bucket nothing writes.

The 17.47% figure is the part of your verification that mattered: matching monasca's usable-based definition rather than ceilometer's ~26% is what shows the numbers kept their meaning and not merely their shape.