Konduo Manual

English

한국어

English

한국어

Appearance

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

The current check scope is TCP connectivity; it does not attest authenticated API access, search, or writes. Deployment coverage stays in the target summary.

TLS ​

Use tls_ca_pem to trust a private CA. For mutual TLS, enter both tls_client_cert and tls_client_key in PEM format. Set tls_server_name when the address differs from the certificate DNS name. tls_insecure_skip_verify retains encryption without checking the server certificate; it defaults to false.

Overview combines one compact disk-usage value with three search QPS, latency and queue-delay trends. Collections and Background Work uses paired collection/node comparisons and three-column write/backlog trends. All 11 panel keys and saved layouts remain available; collection filters, unsupported metrics and partial failures keep their existing meaning.

Counts are shown as integers; scaled byte capacities, rates, and latency keep useful fractional digits. Disk usage uses an explicit 0–100 percent gauge. Missing ratio inputs, unsupported exporter metrics, and partial queries stay unknown.

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.
  • P95 and P99 latency require histogram buckets. If buckets are missing, the percentile is unavailable; use the separately labeled search average only when an arithmetic mean answers the operational question.
  • 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.

Mapping observation policy: a measured zero request rate takes precedence over legacy candidates. A new counter without enough rate samples or an absent/stale source stays unavailable. Proxy request candidates are selected by presence; query-node fan-out counts are not substituted for client QPS, and partition counts are not substituted for segment counts. Versions exposing only success counters report successful requests through that historical candidate. Average latency and capacity ratios require a positive denominator; idle traffic does not imply zero latency.

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

The current check scope is TCP connectivity; it does not attest authenticated API access, search, or writes. Deployment coverage stays in the target summary.

TLS ​

Use tls_ca_pem to trust a private CA. For mutual TLS, enter both tls_client_cert and tls_client_key in PEM format. Set tls_server_name when the address differs from the certificate DNS name. tls_insecure_skip_verify retains encryption without checking the server certificate; it defaults to false.

Overview combines one compact disk-usage value with three search QPS, latency and queue-delay trends. Collections and Background Work uses paired collection/node comparisons and three-column write/backlog trends. All 11 panel keys and saved layouts remain available; collection filters, unsupported metrics and partial failures keep their existing meaning.

Counts are shown as integers; scaled byte capacities, rates, and latency keep useful fractional digits. Disk usage uses an explicit 0–100 percent gauge. Missing ratio inputs, unsupported exporter metrics, and partial queries stay unknown.

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.

Metric interpretation ​

  • P95 and P99 latency require histogram buckets. If buckets are missing, the percentile is unavailable; use the separately labeled search average only when an arithmetic mean answers the operational question.

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.

Mapping observation policy: a measured zero request rate takes precedence over legacy candidates. A new counter without enough rate samples or an absent/stale source stays unavailable. Proxy request candidates are selected by presence; query-node fan-out counts are not substituted for client QPS, and partition counts are not substituted for segment counts. Versions exposing only success counters report successful requests through that historical candidate. Average latency and capacity ratios require a positive denominator; idle traffic does not imply zero latency.

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 ​

The existing closed diagnostic inputs retain check_key, suspected_collection, metric_source_id, and bounded lookback choices. Topology and static rule tools accept {}. Metric resolution requires a nonempty catalog key and preserves its supported selector and time inputs; mapping resolution defaults to Prometheus.

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.