Template Plugin Scaffold

Basic accessibility observation

Resource overviews show accessible, inaccessible, or access unknown independently of metric sources. Successful access does not attest healthy membership, replication, partitions, or workloads; use domain diagnostics and alerts for those conditions. Existing liveness/readiness fields are domain evidence and do not drive the single core-owned access alarm. Unknown observations do not resolve firing incidents.

Configuration acceptance alone does not verify access; this plugin leaves basic access unknown until a direct access probe is implemented.

The template declares numeric display and single-series/latest summaries. State labels and identifier formatting belong in the plugin's chart_spec.display contract, not in host-specific code. Preserve this metadata in resolved panels.

The sample latency histogram is measured in seconds and converted to milliseconds in both instant and range queries before display. Keep the declared unit and query conversion aligned when replacing it.

Declare default panel width with layout.width (1–12 columns); use 3 for a single value, 6 for a few trends and 12 for many labeled series. Put compact summaries, trends, and full-width secondary details in separate rows, and collapse the detail row by default. Responsive density follows dashboard content width while saved widths remain canonical. Keep presets as the complete catalog and use default_panel_keys for the fresh layout so saved layouts can restore an older built-in panel. Declare availability only from evidence; failures remain visible.

The Template plugin is a scaffold for CE plugin development, not an operational runtime target. It collects starter examples for manifest, schema, dashboard, metric catalog, mapping packs, alert rules, and managed collection.

Highlights

• Demonstrates a resource_manager plus managed_metric_collector baseline.
• Includes host-rendered dashboard, monitoring route, metric route, and mapping-pack route skeletons.
• Provides plugin-owned i18n, schema metadata, and conformance test structure.
• Includes canonical live/history Diagnostic Finding examples and a separate operator-triggered refresh action.
• Acts as a starting point for replacing identifiers, module path, manifest data, route payloads, and collector logic.

Before Use

• Do not ship this scaffold as a runtime plugin.
• After copying it, adjust PluginMap and implemented interfaces to match the real plugin.
• Replace template sample metrics with real target-system collection logic.
• Keep the async-job sample only when results are disposable and may disappear on plugin restart; use durable storage for resumable or audit-required work.

Operations Tips

• Prefer schemas and route contributions over plugin-specific Core or frontend branches.
• Metric collection should produce samples; scheduling and remote write remain Core responsibilities.
• When testing Prometheus as the remote write target, run Prometheus with --web.enable-remote-write-receiver.
• Add README and manual source with each new plugin so operators can see the feature boundary immediately.
• Treat diagnostics/summary and diagnostics/history as read-only. Only an explicit operator action may call diagnostics/summary/run.

In-Memory Async Result Example

The scaffold includes two optional bounded background-work shapes. A side-effect job stores only short-lived completion metadata because its real effect belongs to the target system. A result-bearing job retains its payload with sliding idle expiry, an absolute expiry cap, and count/byte limits while keeping lightweight status metadata longer.

Status, result, and delete calls are scoped by both operation ID and resource instance ID. Result payloads can expire before status metadata, in which case result_available=false and result_expired=true explain the state. These records live only in plugin-process memory and are lost on every plugin restart.

What Developers Must Replace

• Replace plugin id, Go module/package path, manifest description, and implemented interface list for the real plugin.
• Redefine configuration schema around the target system connection model and secret fields.
• Rewrite dashboard, diagnostics, and monitoring routes around evidence and workflows that real operators need.
• Build metric catalog and mapping packs from actual exporter or managed-collector metric names and labels.
• Design alert rule packs for plugin-domain risk without duplicating Core availability.

Documentation Guidance

• Use README for developers and operators who need feature boundaries, routes, metrics, alerts, and extension-boundary details.
• Use manual source for end users and operators, explaining what to read in the UI and how to make operational decisions.
• Keep common plugin registration, metric-source linkage, and RBAC procedures in Core documentation; write only plugin-specific differences here.
• When edition-specific extension is needed, document common behavior and extension points separately.