OpenSearch Plugin

The OpenSearch plugin registers an OpenSearch cluster as a Konduo resource and connects cluster health, node, shard, index, JVM, thread pool, search, and indexing signals to the operator UI.

Highlights

• Uses HTTP APIs for health checks and diagnostics.
• Maps exporter metrics to logical metrics through a Prometheus mapping pack.
• Focuses dashboards on cluster health, index health, shard movement, indexing/search throughput, JVM/GC pressure, disk watermarks, and thread pool queues/rejections.
• Separates diagnostics for connectivity, authentication, metric coverage, shard/index risk, JVM/disk pressure, and snapshot repository readiness.

Before Registration

• Prepare OpenSearch endpoint, credentials, TLS verification policy, and timeouts.
• Confirm exporter scraping and label filters before relying on metric dashboards.
• Use a read-only operating account that can query cluster health, cat/index, node stats, and snapshot repository APIs.

Operations Tips

• Read yellow or red health together with shard allocation, disk watermarks, and node availability.
• JVM heap pressure, GC, search/indexing latency, and thread pool rejections often appear together.
• Read unassigned/initializing/relocating shard movement together with red/yellow index counts to separate recovery activity from user-facing risk.
• Destructive index operations and arbitrary query execution are outside the current CE operating boundary.

Operator Views

• The cluster view shows health, node count, shard state, relocating/initializing shards, and master-eligible evidence.
• Index and shard views expose index health, shard allocation, replica risk, and unassigned-index counts as read-only evidence.
• The resource-pressure view combines JVM heap, GC, and disk watermark low/high/flood-stage posture.
• The snapshot repository view uses GET /_snapshot evidence to show repository count, types, and sample repository names.
• Metric dashboards include index health counts, shard movement, GC collection rate, disk-watermark node counts, search/indexing latency, and thread-pool queue/rejection panels.
• Diagnostics separate cluster API evidence from metric-source evidence so API access problems and performance risk are not conflated.

Diagnostics And Alerts

• Diagnostics split connectivity, authentication, cluster health, shard allocation, index health, JVM/disk pressure, snapshot repository readiness, thread-pool rejection, and metric coverage.
• Alert rules focus on cluster-health degradation, unassigned shards, JVM heap pressure, thread-pool rejection, and indexing/search pressure.
• Exporter labels can mix cluster, node, and index dimensions, so review panel coverage and label filters after applying mapping packs.
• Yellow health is not always an immediate outage, but replica safety plus node and disk state determine risk.

Management Boundary

• The CE plugin does not provide destructive actions such as index delete, close/open, force merge, or snapshot restore.
• Arbitrary search/query execution, log search, log evidence collection, and correlation workflows are outside CE operational diagnostics scope and belong in EE overlays.
• Read-only API permission gaps appear as partial evidence; API authorization issues remain meaningful even when metrics are present.
• Security configuration, role mapping, and index-template changes are outside the current plugin management boundary.

Example Workflows

• For yellow or red cluster health, check unassigned shards, node availability, disk watermarks, and replica count in order.
• For search latency, compare search thread-pool queues/rejections, heap/GC, hot indexes, and query traffic changes.
• For indexing delay, review indexing rate, refresh/merge pressure, disk IO, and translog evidence.
• For suspected shard imbalance, compare index shard sizes with node-level disk pressure.

---

OpenSearch Enterprise Overlay

The OpenSearch Enterprise overlay turns OpenSearch resources into the Enterprise log source provider. MCP descriptors, log query validation, field catalogs, log evidence mapping, diagnostics, and anomaly rules connect operational logs to incident analysis.

Highlights

• Provides log source profiles, field catalogs, mapping packs, diagnostics, and alert/anomaly rules through MCP.
• Supports bounded log search, around-event lookup, query resolution, log evidence collection, correlation summaries, and diagnostic history reads.
• Log evidence mapping links other resource diagnostics, such as Redis and PostgreSQL, to a configured log source.
• Log routes use limited windows and result counts to avoid leaking secret-like message fragments or bypassing safeguards.

CE-Based Operations Diagnostics

• The Community-based views provide read-only evidence for cluster health, shard allocation, index health, JVM/GC pressure, disk watermarks, thread-pool queues/rejections, search/indexing latency, and snapshot repository readiness.
• The EE overlay does not replace those diagnostics. It adds log evidence and metric/log correlation models for the same diagnostic keys.

Before Registration

• Prepare OpenSearch endpoint, index pattern, authentication, and TLS settings.
• Confirm field mappings and timestamp field for log source usage.
• Review RBAC so only intended operators can use MCP and log query workflows.

Operations Tips

• Start incident evidence searches with short lookback windows and explicit resource context.
• OpenSearch anomaly rules are metric-source based; log evidence is connected as analysis context.

Operational Scenarios

• Link diagnostic timestamps and resource identity from Redis, PostgreSQL, Kafka, and other resources to OpenSearch searches through log evidence mappings.
• Use around-event lookups and field catalogs to narrow incident logs instead of starting with broad searches.
• Use logs/evidence and correlation/summary to inspect log and metric evidence together for diagnostic keys such as shard allocation, JVM GC, disk watermarks, and thread-pool rejections.
• MCP log descriptors let agents request log evidence while preserving window, result-count, and redaction boundaries.

Boundaries

• OpenSearch is the EE log source provider, and log retrieval remains a bounded read-only workflow.
• Log evidence explains metric anomalies and diagnostics; it does not replace anomaly evaluation itself.