Host Plugin

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.

Chart value semantics

Every built-in and catalog chart declares its latest-value summary policy. Percent gauges use a fixed 0–100 range; counts remain integers and unbounded quantities are not given an invented gauge maximum. Multiple series are retained rather than silently averaged.

Four capacity gauges share one compact row. CPU, memory, disk-space and process trends fill two three-chart rows. Network throughput and errors share a comparison row; drop comparisons retain full width. Existing saved layouts and query definitions remain unchanged.

The Host plugin registers servers, VMs, and network-node style targets as Konduo resources. It provides a common infrastructure view for CPU, memory, filesystem, network, and process pressure through standard dashboards and diagnostics.

Highlights

• Maps host exporter and Zabbix-style telemetry into logical host metrics.
• Groups CPU run-queue, memory and swap pressure, root filesystem, network transfer, and blocked process evidence into diagnostics.
• Treats SSH access as an operator access path, not a background automation engine.
• Provides a stable host model that can act as a placement anchor for other resources.

Before Registration

• Prepare host address, SSH port, authentication mode, and host-key policy.
• terminal_timeout_seconds (default 5) covers the complete SSH connection and shell setup. Canceling creation stops unfinished setup; completed terminals keep their session lifetime.
• Terminal capacity includes pending creation and active sessions. When a limit is reached, creation is rejected before the server contacts SSH.
• Link Prometheus node_exporter or Zabbix item mappings for metric-backed dashboards.
• Periodic health checks are conservative by default and avoid login attempts or command execution.

Operations Tips

• Prioritize repeated or sustained pressure over short spikes.
• Keep service-specific restart and recovery semantics in the plugin that owns the service.
• Align host metric labels with the host identity used in resource placement metadata.

Operator Views

• Dashboards show CPU, load, memory, swap, filesystem, network, and process pressure from a general infrastructure perspective.
• The network row compares receive and transmit throughput, errors, and drops in paired throughput/error charts and a full-width drop chart. Interface labels and the selected time range remain attached to both direction queries.
• Fresh dashboards use 13 of 19 catalog presets. The six former direction-specific network panels remain available for saved layouts and manual personalization.
• Evidence and Inventory views show the configured evidence profile and optional read-only SSH inventory when enabled.
• Diagnostics separate host reachability from metric evidence so access issues and resource pressure are not confused.
• Relation views show approved placement evidence for resources hosted on the same machine.
• SSH access is an operator access path and should not become automated remediation or service-specific orchestration.

Diagnostics And Alerts

• Alert rules cover host-domain risks such as CPU saturation, memory pressure, disk utilization, filesystem availability, network errors, and process/blocking pressure.
• Host metrics help identify common infrastructure causes across services, but individual service liveness remains owned by each resource plugin.
• Zabbix and Prometheus mappings can use different label models; review coverage after applying mapping packs.
• Without a metric source, health checks provide limited reachability evidence and resource utilization should remain unavailable.

Evidence Collection Modes

• Metric-only evidence is the default and does not require host shell access.
• Optional read-only SSH probes are enabled per Host resource with read_only_probe_enabled.
• Probe profiles are minimal, inventory, and diagnostics; read_only_probe_allowlist can narrow the fixed probe set.
• Read-only probes are independent from terminal access. A configured terminal does not automatically allow background probes.
• Community probes never require sudo and never run restart, cleanup, patch, reboot, or arbitrary shell commands.

Read-only Probe Profiles

Profile	Included probes
minimal	Host facts (facts)
inventory	Host facts, filesystems, block devices, and network interfaces
diagnostics	inventory probes plus failed services (failed_services) and process state summary (process_summary)

• When read_only_probe_allowlist is set, it takes precedence over the profile default and only the listed fixed probes run.
• The inventory probe status table shows display names such as Host facts, Filesystems, Block devices, and Network interfaces instead of internal keys like facts.
• Zero failed-service rows are healthy and are shown as "No failed services found."
• Process state summary aggregates ps -eo state= or ps -eo stat= output into state counts. Zero rows are shown as no_data, not healthy, so missing evidence is visible.

Management Boundary

• The Host plugin focuses on general server observation and access-path support.
• Reboot, package installation, service restart, and firewall changes are not default CE management actions.
• SSH credentials and private keys stay inside the secret boundary and must not appear in diagnostics or logs.
• Placement relations are operator-approved metadata; discovery alone should not create authoritative relationships.

Example Workflows

• When several resources fail together, compare shared host relations and CPU, memory, disk, and network pressure first.
• For disk alerts, review filesystem utilization, inode usage, mount state, and service write errors together.
• For memory pressure, check swap, reclaim behavior, OOM evidence, and service latency instead of only used/free memory.
• For network issues, combine interface throughput, errors/drops, host reachability, and downstream service connection failures.

Prometheus and Zabbix host.up use the same binary 0/1 state. Memory, root filesystem, and inode utilization require a positive capacity; invalid or missing capacity is unavailable instead of being clamped to one. A known disabled swap configuration (total and free both zero) continues to report zero swap use.

---

Host Enterprise Overlay

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.

Chart value semantics

Every built-in and catalog chart declares its latest-value summary policy. Percent gauges use a fixed 0–100 range; counts remain integers and unbounded quantities are not given an invented gauge maximum. Multiple series are retained rather than silently averaged.

Anomaly analysis requires SSH credentials and, in fingerprint mode, a verified registered host key. Pending trust is reported as analysis unavailable; it does not resolve existing anomalies or make unrelated resources unhealthy. Verify and register the host fingerprint to restore analysis; keys are never trusted automatically. The anomaly summary includes the latest evaluation availability and last successful observation time. Missing or invalid rule inputs preserve existing anomalies as unavailable observations. Runnable processes are collected from /proc/stat along with CPU, memory and filesystem inputs; missing data is never filled with zero.

Four capacity gauges share one compact row. CPU, memory, disk-space and process trends fill two three-chart rows. Network throughput and errors share a comparison row; drop comparisons retain full width. Existing saved layouts and query definitions remain unchanged.

Fresh dashboards select 13 of 19 catalog panels. A paired throughput/error row and a full-width drop chart compare receive/transmit directions with the original interface labels and units. All six former single-direction panels remain available to saved layouts and personalization.

The Host Enterprise overlay adds MCP descriptors and plugin-executed anomaly detectors to the Community Host plugin. It correlates CPU, memory, disk, network, and process signals so host pressure is more contextual than a single metric threshold.

Highlights

• Exposes host metadata, monitoring overview, diagnostics, metrics catalog, and anomaly rules through MCP.
• Exposes read-only Host inventory, fleet summary, relation impact, and privilege-based check descriptors through MCP.
• Plugin detectors combine multiple resource-domain signals to evaluate memory pressure, disk saturation, CPU steal, and network pressure.
• Terminal and diagnostics workflows keep their existing RBAC and audit boundaries.
• Optional privilege-based probes are separated from Community read-only inventory and require explicit allowlists.

Before Registration

• Community Host agent or exporter connectivity must be healthy.
• Anomaly analysis needs host logical metric coverage and metric-source mapping.
• MCP access should be limited to read-oriented operator scopes.
• terminal_timeout_seconds (default 5) covers the complete SSH connection and shell setup. Canceling creation stops unfinished setup; completed terminals keep their session lifetime.
• Terminal capacity includes pending creation and active sessions. When a limit is reached, creation is rejected before the server contacts SSH.

Operations Tips

• Treat host pressure as a sustained multi-domain pattern, not a single metric spike.
• Terminal capability is an operational action separate from MCP lookup. Review permissions and audit logs together.
• Keep Community read-only probes enabled only for inventory and diagnostics that do not need sudo.

Operational Scenarios

• When several services fail together, compare shared host relations with CPU, memory, disk, and network pressure to narrow the common cause.
• Use infrastructure signals such as CPU steal, swap pressure, and filesystem saturation as early warnings that service-specific plugins may not expose.
• MCP descriptors let operator agents read host diagnostics and metric coverage; they do not replace terminal execution.
• Fleet summary and relation impact routes structure operator-approved placement evidence without creating or changing relations.

Fleet And Relation Context

• host/fleet/summary returns read-only Host group rollups, evidence freshness, and links to diagnostic routes.
• host/relations/impact summarizes resources hosted on the Host and the Host pressure signals that may affect them.
• These routes are advisory context surfaces; relation creation, approval, and deletion stay in the core relation workflow.

Privilege-Based Check

• privileged_evidence_enabled must be explicitly enabled per Host resource.
• privileged_evidence_sudo_policy must be non_interactive; password prompts are treated as permission denied.
• privileged_evidence_profile selects the privilege-based check scope. Presets run fixed probe groups; custom is only for policy-specific probe keys.
• privileged_evidence_allowlist is used only with the custom profile and accepts comma-separated keys such as sudo_capability, reboot_required, package_posture, and journal_summary.
• Results are shown in the Host manage/diagnostics Privilege-Based Check tab and are also available from the host/evidence/privileged route or MCP privileged_evidence descriptor.
• Privilege-based checks are read-only, audited, and separate from terminal sessions and Community read-only probes.
• Permission denied, unsupported platform, timeout, and no-data states are reported as evidence states rather than hidden.

Boundaries

• Terminal and diagnostic actions are permissioned, audited operations, while the MCP catalog focuses on read-oriented descriptions and lookups.
• Reboots, package installs, firewall changes, and similar system mutations are not automatically performed by this overlay.
• Privilege-based checks do not run arbitrary shell commands and do not perform restart, cleanup, patch, or reboot operations.

Prometheus and Zabbix host.up use the same binary 0/1 state. Memory, root filesystem, and inode utilization require a positive capacity; invalid or missing capacity is unavailable instead of being clamped to one. A known disabled swap configuration (total and free both zero) continues to report zero swap use.

MCP diagnostic execution effects

The run_diagnostics tool changes diagnostic execution and cooldown state. Its descriptor declares operation_class: diagnostic_lifecycle; MCP advertises readOnlyHint=false, destructiveHint=false and idempotentHint=false. Diagnostic queries retain read-only hints. Both queries and actions continue to require mcp:invoke and the existing resource permissions/audit checks. Safety hints do not change authorization or guarantee safe retries.

MCP tool input contracts

Host terminal inspection and static catalogs accept {}. Fleet and relation tools declare supplied rollup counts, grouping tags, hosted resource IDs, pressure state, and relation confidence. History and connectivity expose lookback; metric linkage exposes metric_source_id and metric_label_filters. Privileged evidence inspection declares the reviewed profile, custom probe allowlist, service unit, and bounded probe timeout/output limits; omitted values use stored settings or plugin defaults, and operator permission, auditing, and plugin privilege checks still apply.

The advertised JSON Schema is checked before plugin dispatch. Omitted optional values retain plugin defaults. Arguments do not replace resource-instance authorization; stored connection credentials are supplied by Konduo. Open schemas are retained only for existing dynamic filters or aliases, and each advertised property describes its caller-facing meaning. Plugin result shapes can vary with product/version, available evidence, and partial failures; no stable outputSchema is promised for these dynamic responses. Client and resource coverage rules are defined in enterprise/backend/docs/plugin-contract.md in the Enterprise source repository.