Konduo Manual

English

한국어

English

한국어

Appearance

Milvus Plugin ​

The Milvus plugin registers vector database operations as a Konduo resource. It exposes Milvus-specific signals such as search latency, query queues, insert/write path behavior, collection load, compaction/index/import backlog, and node memory.

Highlights ​

  • Validates endpoint connectivity and TLS/auth settings with bounded health checks.
  • Reads Milvus logical metrics through a linked Prometheus metric source.
  • Focuses dashboards on search serving, collection load, write delay, background backlog, and capacity risk.
  • Groups diagnostics around serving degradation, write path delay, background backlog, and capacity risk.

Before Registration ​

  • Prepare Milvus endpoint, database, username/password or token, and TLS settings.
  • Confirm that metric label filters select only the target Milvus deployment.
  • Metric names and labels can vary by deployment; review panel coverage after applying the mapping pack.

Operations Tips ​

  • Read search latency and query queues together with collection load, segment state, and query node memory.
  • For write path delay, check insert rate, flush latency, time tick lag, and compaction backlog together.
  • Arbitrary collection mutation and data operations are outside the current CE operating boundary.

Operator Views ​

  • The overview view summarizes endpoint connectivity, metric coverage, collection load state, and major serving/write risks.
  • Dashboards visualize search latency, query-node pressure, insert throughput, flush latency, time-tick lag, and compaction/index/import backlog.
  • Collection evidence helps operators understand load state and serving impact.
  • Diagnostics split serving, write path, background tasks, and capacity risk so likely causes can be narrowed.

Diagnostics And Alerts ​

  • Milvus incidents can involve query nodes, data nodes, proxy, coordinators, and storage dependencies, so avoid single-metric conclusions.
  • Alert rules focus on search latency, query queues, write deny, ingest lag, flush latency, compaction backlog, index/import backlog, and node memory pressure.
  • Metric labels can vary by Milvus deployment and exporter version, so mapping-pack and label-filter validation is important.
  • Without a metric source, Milvus-specific performance evidence is limited to endpoint reachability and configuration checks.

Management Boundary ​

  • Collection create/drop/load/release, index build, and data import/export are outside CE plugin management scope.
  • The plugin observes operational state and risk signals; mutation remains in Milvus operating procedures and permission systems.
  • Tokens and TLS settings stay inside the secret boundary.
  • High background backlog does not automatically trigger compaction or index rebuild actions.

Example Workflows ​

  • For search latency, compare query queues, collection load, segment count, query-node memory, and CPU pressure.
  • For insert/write delay, inspect insert throughput, write deny, time-tick lag, flush-save latency, and object-storage state.
  • For compaction backlog, compare segment growth, write traffic, compaction task state, and node resource pressure.
  • For collection load issues, review load status, query-node distribution, memory pressure, and recent deployment changes.

Milvus Enterprise Overlay ​

The Milvus Enterprise overlay adds MCP descriptors, advanced diagnostics, metric mapping, and anomaly rules to Milvus resources. It explains vector database health through read-oriented evidence for collections, indexes, query nodes, and data nodes.

Highlights ​

  • Provides resource metadata, monitoring overview, topology, diagnostics, metric mapping, and alert/anomaly rules through MCP.
  • Diagnostics summarize collection, index, query node, and metric coverage evidence for operators.
  • Anomaly rules resolve Milvus logical metrics through metric sources in declarative metric mode.
  • Default behavior is read-only diagnostics; state-changing workflows need separate action routes and authorization boundaries.

Before Registration ​

  • Community Milvus connectivity and authentication must be healthy.
  • Connect a Prometheus metric source and Milvus mapping pack.
  • MCP users need resource read permission and the required scopes.

Operations Tips ​

  • Interpret search latency, index state, and query node pressure together with collection size and workload changes.
  • If diagnostics lack evidence, check metric endpoint exposure and mapping pack application first.

Operational Scenarios ​

  • When vector search latency rises, inspect query node pressure, collection size, index build state, and segment/load state together.
  • After collection or index operations, compare topology evidence and metric coverage to distinguish workload changes from infrastructure bottlenecks.
  • MCP diagnostics provide read-only Milvus context for RAG or AI service incident analysis across related resources.

Boundaries ​

  • The EE overlay adds advanced diagnostics, topology evidence, and anomaly metadata; collection or index mutation requires a separately modeled action route.
  • Without metric-source coverage, anomaly rules cannot be evaluated meaningfully and missing evidence should not be treated as healthy.