Redis Plugin
TLS settings location
TLS modes, CA/client certificates and keys, server names and verification options are grouped under Security > TLS. Endpoint/port fields keep their original location. Grouping does not change field keys, saved values, defaults, sensitive handling, visibility or validation.
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.
TLS
Set tls_enabled=true for TLS. Supply a private CA in tls_ca_cert (PEM) to verify the Redis server, and optionally set tls_server_name when the certificate's DNS name differs from the connection address. If Redis requires mutual TLS, enter both tls_client_cert and tls_client_key (PEM). tls_insecure_skip_verify disables server certificate verification while retaining encryption; it defaults to false and needs no CA.
Chart value semantics
Binary availability remains a state, now declared through the shared display contract with localized labels. Counts stay integer; percent gauges use 0–100. Multi-query panels retain distinct series instead of inventing a combined summary. CPU time remains CPU seconds per second, not machine capacity percent.
Four traffic/performance trends share one row. Node/keyspace comparisons use two columns; the three stability trends share one row. Current service values remain in their compact row. Existing saved layouts and query definitions remain unchanged.
Overview groups cluster and memory/cache summaries in one compact row, followed by traffic trends. Memory/keyspace and stability trends have a separate detail page. All 15 panels and saved layouts retain their metric meanings and cluster/standalone prerequisites.
When maxmemory is zero or unavailable, the memory panel displays used memory in byte units and explains that utilization cannot be calculated. It does not show a utilization gauge or infer memory health from an unset capacity. The panel matches usage and limits per node before aggregation. Mixed unlimited and limited nodes, missing limits, or mismatched node samples display observed used memory instead of a misleading cluster percentage.
Eligible single-metric stat panels show a lower sparkline. The current value keeps its instant query; a separate history request asks for at most 160 samples per series per queried interval. Categorical states and compound calculations are excluded. A history failure preserves the current value and displays “Trend unavailable”.
The Redis plugin registers standalone, primary/replica, and Redis Cluster deployments as one Konduo resource and exposes status, metrics, diagnostics, and bounded management workflows.
Highlights
- Discovers cluster node IDs and member addresses from the seed endpoint and represents them as target evidence within one resource instance.
- Provides logical metrics for memory, keyspace, command throughput, clients, evictions, fragmentation, replication, and blocked clients.
- Supports both Prometheus mapping packs and Konduo-managed Redis metric collection.
- Runs key scan, streams, CLI, memory inspection, and server operations through bounded jobs and confirmation boundaries.
Before Registration
- Prepare seed host/port and password or ACL user credentials.
- For clustered deployments,
cluster_instancescan provide a fallback member list. - Prepare Prometheus redis_exporter mapping or a managed collection write target for metric-backed views.
- When Prometheus is the managed collection write target, run Prometheus with
--web.enable-remote-write-receiver.
Operations Tips
- Do not treat seed endpoint failure as whole-cluster failure without checking other discovered members.
- Interpret memory fragmentation, evictions, and blocked clients together with workload changes.
- Key and stream scans can add load; review limits, cursor behavior, and job status before running them.
- Bulk-key, import, and big-key job results are temporary in-memory evidence, not audit history. Completed results disappear automatically after their bounded viewing window and all such results are lost when the plugin restarts.
- Deep-diagnostics results, CLI execution streams/history, and server-operation status are also bounded process-local evidence. CLI snippets and favorites are user configuration and are not removed by execution-result cleanup.
Operator Views
- The server view shows standalone, primary/replica, and cluster members inside one resource instance while distinguishing the seed endpoint from discovered members.
- The key view uses cursor-based scan jobs to inspect bounded key lists, TTL, type, and estimated memory.
- The Streams view exposes stream, group, consumer, pending backlog, and idle-time evidence as read-only operational data.
- CLI and server-operation views run only selected triage commands behind confirmation and safe-mode controls.
Diagnostics And Alerts
- Diagnostics are grouped by topology, memory/keyspace posture, workload attribution, durability/replication, and metric-backed risk.
- Alert rules cover cluster health, replication link state, replication lag, fragmentation, blocked clients, evictions, and cache hit-rate risk.
- Managed collection converts Redis command evidence into redis_exporter-compatible samples and isolates them with the resource identity label.
- Missing metric evidence should lead operators to inspect mapping packs, scrape state, or managed-write status instead of assuming Redis is healthy.
Management Boundary
- Arbitrary Redis API browsing and unbounded
KEYSscans are outside the CE operating boundary. - Key deletion, server operations, and CLI execution are mutating actions that require intent confirmation, permissions, and audit evidence.
- Mutating stream workflows such as trim, claim, or ack are not provided without separate guardrails.
- When seed endpoints or cluster member identities change, refresh both resource configuration and cluster evidence to avoid stale discovery.
Example Workflows
- For memory alerts, compare used/max memory, fragmentation, eviction rate, keyspace growth, and big-key scan results.
- For replication lag, review primary/replica role, link state, replication offsets, and network evidence together.
- For cluster-slot issues, inspect member reachability, cluster-nodes evidence, slot completeness, and failover progress.
- For stream delay, check pending count, consumer idle time, last-delivered id, and retention policy in order.
Cache-hit ratio is defined only when hits plus misses is positive. Idle traffic or a missing operand is unavailable, while observed traffic consisting entirely of misses is a real 0%. The cluster and per-node panels follow the same rule; do not interpret an idle interval as a cache outage.
Redis Enterprise Overlay
TLS settings location
TLS modes, CA/client certificates and keys, server names and verification options are grouped under Security > TLS. Endpoint/port fields keep their original location. Grouping does not change field keys, saved values, defaults, sensitive handling, visibility or validation.
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.
TLS
Set tls_enabled=true for TLS. Supply a private CA in tls_ca_cert (PEM) to verify the Redis server, and optionally set tls_server_name when the certificate's DNS name differs from the connection address. If Redis requires mutual TLS, enter both tls_client_cert and tls_client_key (PEM). tls_insecure_skip_verify disables server certificate verification while retaining encryption; it defaults to false and needs no CA.
Chart value semantics
Binary availability remains a state, now declared through the shared display contract with localized labels. Counts stay integer; percent gauges use 0–100. Multi-query panels retain distinct series instead of inventing a combined summary. CPU time remains CPU seconds per second, not machine capacity percent.
Four traffic/performance trends share one row. Node/keyspace comparisons use two columns; the three stability trends share one row. Current service values remain in their compact row. Existing saved layouts and query definitions remain unchanged.
Overview groups cluster and memory/cache summaries in one compact row, followed by traffic trends. Memory/keyspace and stability trends have a separate detail page. All 15 panels and saved layouts retain their metric meanings and cluster/standalone prerequisites.
Eligible single-metric stat panels show a lower sparkline. The current value keeps its instant query; a separate history request asks for at most 160 samples per series per queried interval. Categorical states and compound calculations are excluded. A history failure preserves the current value and displays “Trend unavailable”.
The Redis Enterprise overlay adds MCP descriptors, Enterprise dashboards, diagnostic analysis jobs, key scans, bulk jobs, import/export, streams, CLI console, and anomaly detectors to the Community Redis plugin.
Metric interpretation
When maxmemory is zero or unavailable, the memory panel displays used memory in byte units and explains that utilization cannot be calculated. It does not show a utilization gauge or infer memory health from an unset capacity. The panel matches usage and limits per node before aggregation. Mixed unlimited and limited nodes, missing limits, or mismatched node samples display observed used memory instead of a misleading cluster percentage.
Highlights
- Exposes monitoring overview, topology summary, diagnostics, metrics catalog, and alert/anomaly rules through MCP.
- Plugin-executed anomaly detectors interpret INFO evidence for memory pressure, blocked clients, and replication link down.
- Big key scans, stream inspection, bulk TTL/delete, import/export, and CLI execution run as bounded jobs.
- Log evidence blueprints connect OOM, failover, connection refused, and slowlog patterns to an Enterprise log source.
Before Registration
- Community Redis connectivity, ACLs, cluster discovery, and metric-source mapping must be healthy.
- Review operator permissions and audit requirements before enabling key scan or CLI workflows.
- Connect an OpenSearch log source when richer diagnostic evidence is needed.
Operations Tips
- Do not treat seed endpoint failure as whole-cluster failure without checking other discovered members.
- Interpret memory fragmentation, evictions, and blocked clients together with workload changes.
- Key and stream scans can add load; review limits, cursor behavior, and job status before running them.
- Import/export and bulk jobs can add load in large estates. Review limits, dry-run mode, and job status.
- Bulk-key, import, and big-key job results are temporary in-memory evidence, not audit history. Completed results disappear automatically after their bounded viewing window and all such results are lost when the plugin restarts.
- Deep-diagnostics results, CLI execution streams/history, and server-operation status are also bounded process-local evidence. CLI snippets and favorites are user configuration and are not removed by execution-result cleanup.
- Use MCP descriptors as read-oriented context; mutating jobs must keep existing action routes and authorization boundaries.
Operational Scenarios
- For suspected memory pressure, review INFO evidence, big-key scans, eviction, fragmentation, and slowlog or log evidence together.
- For stream backlog or consumer-group issues, use stream inspection and topology summaries to narrow the delayed processing point.
- Run import/export or bulk TTL/delete only after checking operator intent, dry-run output, job progress, and audit trail.
Boundaries
- CLI console, bulk jobs, and import/export are powerful operational features and must stay behind action routes separate from MCP read-only descriptors.
- Redis plugin-mode anomaly detection focuses on INFO evidence; log correlation is connected through OpenSearch log source mappings.
Cache-hit ratio is defined only when hits plus misses is positive. Idle traffic or a missing operand is unavailable, while observed traffic consisting entirely of misses is a real 0%. The cluster and per-node panels follow the same rule; do not interpret an idle interval as a cache outage.
MCP argument and result contracts
Summary and history tools accept lookback or lookback_window and optional metric_source_id. Detail accepts check_key, check, or section; omission selects connectivity_topology. Monitoring overview describes optional db. Metric resolution describes its supported instance and label selectors.
Argument-bearing routes retain compatible dynamic filters where the plugin passes an open query filter map; the advertised properties describe useful inputs without removing existing aliases. Unknown fields are rejected for explicitly argument-free tools.
Results contain route-specific diagnostic evidence, vendor inventory, optional fields, and availability states. These dynamic result shapes intentionally omit outputSchema; clients should inspect the returned structured content and status rather than assume a fixed success-only result. Tools and resources use the same instance scope, authorization, and masking. Resource-only catalogs remain available through resources/read; tools-only clients can inspect tool-backed operational routes but need resource support for the remaining metadata catalogs.