Host Plugin

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.
• 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.
• 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.

---

Host Enterprise Overlay

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.

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.