Problem

Netdata now has the framework for collector-owned dashboard taxonomy:

• collector-adjacent taxonomy.yaml
• integrations/gen_taxonomy.py
• integrations/check_collector_taxonomy.py
• taxonomy schemas under integrations/schemas/
• section/icon registries under integrations/taxonomy/
• CI wiring for changed collector taxonomy consistency

But coverage is still partial. Current committed taxonomy.yaml files exist only for a small set of producers/collectors, including:

• src/collectors/network-viewer.plugin/taxonomy.yaml
• src/go/plugin/go.d/collector/apache/taxonomy.yaml
• src/go/plugin/go.d/collector/cato_networks/taxonomy.yaml
• src/go/plugin/go.d/collector/mysql/taxonomy.yaml
• src/go/plugin/go.d/collector/nvidia_smi/taxonomy.yaml
• src/go/plugin/go.d/collector/panos/taxonomy.yaml
• src/go/plugin/go.d/collector/postgres/taxonomy.yaml
• src/go/plugin/go.d/collector/prometheus/taxonomy.yaml
• src/go/plugin/go.d/collector/snmp/taxonomy.yaml
• src/go/plugin/go.d/collector/vsphere/taxonomy.yaml

Most collectors still rely on legacy/default dashboard placement behavior or downstream taxonomy ownership. The source of truth for the existing dashboard TOC still lives in the Cloud frontend repository under:

• cloud-frontend/src/domains/charts/toc/

Until the remaining TOC structure is migrated into collector-owned taxonomy.yaml files and consumed by Cloud frontend, taxonomy drift can continue.

Description

Complete taxonomy.yaml coverage for collectors/producers that declare metric contexts, using the current Cloud frontend TOC as the migration source of truth.

The migration should move dashboard table-of-contents ownership from Cloud frontend taxonomy files into Netdata collector-owned taxonomy files, then update Cloud frontend to consume the generated Netdata taxonomy artifact.

Scope:

• Inventory current TOC definitions from cloud-frontend/src/domains/charts/toc/.
• Map existing Cloud frontend TOC entries to Netdata collectors/producers and metric contexts.
• Identify collectors/producers with metric contexts and missing taxonomy.yaml.
• Add collector-owned taxonomy.yaml files in reviewable batches.
• Use integrations/gen_taxonomy_seed.py as a starting point where useful.
• Manually review and refine generated taxonomy placement; do not blindly accept seed output.
• Add required dynamic declarations in metadata.yaml.metrics.dynamic_context_prefixes or metadata.yaml.metrics.dynamic_collect_plugins when a collector legitimately uses dynamic contexts.
• Update Cloud frontend to consume integrations/taxonomy.json.
• Remove or reduce duplicated legacy Cloud frontend TOC ownership once the generated taxonomy artifact covers the same behavior.
• Extend or adjust the taxonomy schema if migration or Cloud frontend consumption exposes a real schema gap.

Out of scope:

• Unrelated collector metric changes.
• Unrelated dashboard UX redesign.
• Reworking taxonomy schema preemptively without a concrete migration or Cloud frontend consumption need.

Importance

must have

Value proposition

1. Prevents dashboard TOC drift by making collectors own their dashboard taxonomy placement.
2. Makes taxonomy validation possible in the public Netdata repository.
3. Reduces hidden coupling with downstream frontend taxonomy code.
4. Gives contributors a single source of truth for metric contexts, metadata, and dashboard placement.
5. Enables Cloud frontend to consume generated taxonomy instead of maintaining a parallel hand-written TOC.
6. Enables future CI enforcement that every collector with metric contexts has explicit taxonomy coverage.

Proposed implementation

Implement in batches, not as one huge unreviewable PR.

Suggested phases:

1. Inventory existing Cloud frontend TOC

   • Read cloud-frontend/src/domains/charts/toc/.
   • Extract existing sections, groups, grids, context/table widgets, alternatives, dynamic selectors, and view-specific behavior.
   • Record which TOC entries map cleanly to existing collector contexts and which expose schema gaps or metadata drift.

2. Netdata taxonomy coverage

   • Find collectors/producers with metric contexts and no taxonomy.yaml.
   • Classify them by plugin family and complexity:
     • simple static-context collectors
     • dynamic-context collectors
     • generated collectors such as ibm.d
     • internal C/plugin producers
     • collectors needing product/design review for placement

3. Simple static collectors

   • Use integrations/gen_taxonomy_seed.py to seed candidate taxonomy files.
   • Review section placement, icon, titles, grouping, and owned contexts.
   • Validate with:

     python3 integrations/gen_taxonomy.py --check-only
     python3 integrations/check_collector_taxonomy.py --pr-diff origin/master...HEAD

4. Dynamic collectors

   • Add explicit dynamic declarations to metadata.yaml.metrics where needed.
   • Use context_prefix, context_prefix_exclude, or collect_plugin only when the collector really emits dynamic contexts.
   • Avoid broad selectors when explicit owned contexts are feasible.

5. Generated collectors

   • For ibm.d and similar generated metadata flows, decide whether taxonomy is manually authored as a sibling file or generated from source metadata.
   • Keep generator changes separate from routine taxonomy additions if the generator work becomes large.

6. Cloud frontend consumption

   • Add a Cloud frontend consumer for integrations/taxonomy.json.
   • Validate generated taxonomy output against the frontend rendering needs.
   • Remove duplicated legacy TOC ownership where the generated artifact is authoritative.
   • If consumption exposes schema gaps, update the Netdata schema and generator in the same coordinated work.

7. Enforcement

   • After coverage and Cloud frontend consumption are sufficiently complete, make global missing-taxonomy coverage fatal in CI.
   • Keep changed-collector taxonomy enforcement active throughout the migration.

Acceptance criteria:

• Existing Cloud frontend TOC behavior under cloud-frontend/src/domains/charts/toc/ is either represented by Netdata-owned taxonomy, explicitly rejected as obsolete, or tracked as a separate issue with evidence.
• All metric-producing collectors that should appear in the dashboard TOC have taxonomy.yaml, or have an explicit documented opt-out with reason.
• integrations/gen_taxonomy.py --check-only passes.
• integrations/check_collector_taxonomy.py --pr-diff origin/master...HEAD passes for each Netdata migration batch.
• Cloud frontend can consume integrations/taxonomy.json for migrated taxonomy surfaces.
• Dynamic context collectors declare their dynamic context ownership explicitly.
• No collector metric context is silently omitted from taxonomy due to missing ownership.
• Remaining exceptions are tracked as separate GitHub issues with evidence.