etcd Plugin

The etcd plugin registers an etcd cluster as one Konduo resource and exposes member, endpoint, alarm, proposal, MVCC DB size, peer, and network signals to the operator UI.

Highlights

• Uses both HTTP gateway and etcd v3 gRPC client paths for member, status, and alarm evidence.
• Connects member discovery, leader/learner state, endpoint health, HashKV, and NOSPACE alarms to diagnostics.
• Supports Prometheus mapping packs and Konduo-managed metric collection.
• Protects recovery-support actions such as compact, defrag, alarm disarm, snapshot, and leader transfer with confirmation and cooldown controls.

Before Registration

• Prepare etcd client endpoints, TLS/mTLS, basic auth, and timeout settings.
• Set metric_collection_endpoints when /metrics is exposed on a separate listener.
• When Prometheus is the managed collection write target, run Prometheus with --web.enable-remote-write-receiver.
• In gRPC-only environments, only a status-derived subset may be collected; review p99 latency and histogram panel coverage.

Operations Tips

• Distinguish client URLs from peer URLs when reading member evidence.
• Treat fallback evidence as partial when gateway discovery fails.
• Confirm revision, target endpoint, and operator intent before running defrag or compact actions.

Operator Views

• The member view shows member id, name, client and peer URLs, leader/learner state, and endpoint health together.
• The alarm view exposes cluster alarms such as NOSPACE and helps decide whether disarm is appropriate.
• Diagnostics combine HashKV, proposals, DB size, quota, and peer/client latency evidence for consistency and capacity risk.
• Snapshot, compact, defrag, and leader-transfer actions are recovery helpers that run through explicit confirmation.

Diagnostics And Alerts

• etcd availability should be read through endpoint health, member quorum, leader state, and alarm state together.
• Alert rules cover etcd-domain risks such as leader loss, proposal failures, DB quota pressure, peer/client latency, and NOSPACE alarms.
• Both managed collection and Prometheus mapping packs rely on member-level labels, so endpoint/member label mismatches become partial evidence.
• HashKV differences should be checked with revision, endpoint, and member state before being treated as data corruption.

Management Boundary

• Compact and defrag can affect performance and storage state, so target member and revision must be explicit.
• Alarm disarm should happen after removing the cause; repeatedly disarming NOSPACE is not a recovery plan.
• Snapshot actions provide recovery evidence but do not replace a full backup policy.
• Member add/remove or cluster reconfiguration automation is outside the default CE management scope.

Example Workflows

• For suspected leader instability, inspect leader, learner, endpoint health, and quorum viability first.
• When DB size approaches quota, review compaction revision, defrag candidate members, and NOSPACE alarm state.
• For latency alerts, compare client request latency, peer round-trip, and proposal pending/failure evidence.
• If member HashKV values differ, align revision and endpoint state before retesting, then escalate to upstream etcd procedures when needed.

---

etcd Enterprise Overlay

The etcd Enterprise overlay adds MCP descriptors, anomaly rules, and plugin-executed detectors on top of the Community etcd plugin. Its goal is to surface cluster risk earlier by correlating quorum, leader, proposal, WAL, and fsync signals.

Highlights

• Exposes etcd resources, monitoring overview, diagnostics, metrics mapping, and anomaly rules through the MCP catalog.
• Plugin-executed anomaly detectors interpret etcd API evidence together with metric evidence.
• Declarative metric rules resolve logical metric keys through a Prometheus metric source.
• Simulator fixtures cover leader instability, quorum risk, disk latency, and proposal backlog scenarios.

Before Registration

• Community etcd connectivity and TLS settings must be healthy.
• Anomaly analysis needs a Prometheus metric source and mapping pack linkage.
• MCP users need read scopes and resource access.

Operations Tips

• Interpret leader changes, proposal backlog, and fsync latency together with quorum state instead of as isolated signals.
• When plugin detector and declarative metric results differ, check metric-source coverage and etcd API permissions first.

Operational Scenarios

• During control-plane incidents, inspect leader stability, quorum member health, and proposal apply backlog together to judge write-path risk.
• When disk latency rises, separate WAL fsync and backend commit delay to distinguish storage bottlenecks from consensus bottlenecks.
• MCP catalogs give incident-analysis agents a read-only entry point for etcd state, metric coverage, and anomaly rules.

Boundaries

• Quorum interpretation and anomaly metadata stay in the EE overlay; shared etcd connectivity and base health behavior stay in the CE plugin.
• Plugin-mode detectors run only for rules that need etcd API evidence. Metric-threshold rules are evaluated by the core declarative evaluator.