Is your feature request related to a problem?
I am running OpenSearch with the opensearch-cross-cluster-replication plugin and the opensearch-prometheus-exporter plugin installed on the same nodes, and I cannot observe replication health from my existing Prometheus scrape. CCR exposes its runtime state only as on-demand REST JSON — GET /_plugins/_replication/leader_stats, GET /_plugins/_replication/follower_stats, GET /_plugins/_replication/autofollow_stats, and GET /_plugins/_replication/<index>/_status — and none of these are surfaced at /_prometheus/metrics. As a result, the most operationally important signals are not scrape-able today: paused / failed / stuck follower indices, per-follower replication lag (operations and bytes behind), autofollow rule success/failure counts and last-failed index, and leader-side load attributable to replication (ops sent, throttle time, bytes read). Today, assembling this picture requires polling multiple distinct REST endpoints and correlating their JSON responses out-of-band, which does not fit into collating stats based on prometheus metrics and is also very tedious.
What solution would you like?
CCR runtime statistics should be available in standard Prometheus exposition format at the same GET /_prometheus/metrics endpoint operators already scrape, with no new port and no new auth surface. Coverage should include the data already returned by leader_stats, follower_stats, autofollow_stats, and per-index status, modelled as opensearch_ccr* metrics with sensible labels (cluster, follower_index / leader_index, leader_alias, pattern, state). The mechanism should be optional — when the CCR plugin is not installed or replication is disabled, the existing /_prometheus/metrics output must be unchanged — and a CCR-stats failure on a single scrape must not break the rest of the metrics response.
What alternatives have you considered?
Three implementation paths look reasonable, and the main reason for filing this issue is to ask the CCR community which one they consider in scope:
- CCR plugin natively exposes Prometheus metrics. The
opensearch-cross-cluster-replication plugin registers its own collector and contributes metrics to /_prometheus/metrics (or a dedicated path). Pros: source of truth and exposition stay co-located, no extra REST hop, naming is owned by the people who own the data. Cons: couples a domain plugin to a transport-format concern, pulls Prometheus client libraries into CCR.
opensearch-prometheus-exporter adds a CCR collector. The exporter calls the existing CCR REST APIs on each scrape and converts the JSON to metrics, exactly like it already does for _nodes/stats, _cluster/health, and _cluster/settings. Pros: keeps the existing separation of concerns, degrades gracefully when CCR is absent, aligns with opensearch-prometheus-exporter#505 which already calls CCR out as a known gap. Cons: exporter must hard-code the CCR JSON schema and is sensitive to field renames; needs role mapping to call the CCR stats APIs under the security plugin.- Hybrid — CCR exposes a stable stats SPI, the exporter consumes it. CCR keeps an internal typed
StatsCollector/Metric interface; the exporter (and any other observability plugin) consumes it. Pros: best long-term separation, future plugins can plug into the same SPI. Cons: largest scope, needs SIG-level alignment across both repos and possibly OpenSearch core.
If the community confirms the request is in scope and indicates which repository should own it (this one, opensearch-project/opensearch-prometheus-exporter, or both via a shared SPI), we are willing to provide the implementation, and long-term maintenance, following that project's contribution guidelines.
Is your feature request related to a problem?
I am running OpenSearch with the
opensearch-cross-cluster-replicationplugin and theopensearch-prometheus-exporterplugin installed on the same nodes, and I cannot observe replication health from my existing Prometheus scrape. CCR exposes its runtime state only as on-demand REST JSON —GET /_plugins/_replication/leader_stats,GET /_plugins/_replication/follower_stats,GET /_plugins/_replication/autofollow_stats, andGET /_plugins/_replication/<index>/_status— and none of these are surfaced at/_prometheus/metrics. As a result, the most operationally important signals are not scrape-able today: paused / failed / stuck follower indices, per-follower replication lag (operations and bytes behind), autofollow rule success/failure counts and last-failed index, and leader-side load attributable to replication (ops sent, throttle time, bytes read). Today, assembling this picture requires polling multiple distinct REST endpoints and correlating their JSON responses out-of-band, which does not fit into collating stats based on prometheus metrics and is also very tedious.What solution would you like?
CCR runtime statistics should be available in standard Prometheus exposition format at the same GET /_prometheus/metrics endpoint operators already scrape, with no new port and no new auth surface. Coverage should include the data already returned by leader_stats, follower_stats, autofollow_stats, and per-index status, modelled as opensearch_ccr* metrics with sensible labels (cluster, follower_index / leader_index, leader_alias, pattern, state). The mechanism should be optional — when the CCR plugin is not installed or replication is disabled, the existing /_prometheus/metrics output must be unchanged — and a CCR-stats failure on a single scrape must not break the rest of the metrics response.
What alternatives have you considered?
Three implementation paths look reasonable, and the main reason for filing this issue is to ask the CCR community which one they consider in scope:
opensearch-cross-cluster-replicationplugin registers its own collector and contributes metrics to/_prometheus/metrics(or a dedicated path). Pros: source of truth and exposition stay co-located, no extra REST hop, naming is owned by the people who own the data. Cons: couples a domain plugin to a transport-format concern, pulls Prometheus client libraries into CCR.opensearch-prometheus-exporteradds a CCR collector. The exporter calls the existing CCR REST APIs on each scrape and converts the JSON to metrics, exactly like it already does for_nodes/stats,_cluster/health, and_cluster/settings. Pros: keeps the existing separation of concerns, degrades gracefully when CCR is absent, aligns withopensearch-prometheus-exporter#505which already calls CCR out as a known gap. Cons: exporter must hard-code the CCR JSON schema and is sensitive to field renames; needs role mapping to call the CCR stats APIs under the security plugin.StatsCollector/Metricinterface; the exporter (and any other observability plugin) consumes it. Pros: best long-term separation, future plugins can plug into the same SPI. Cons: largest scope, needs SIG-level alignment across both repos and possibly OpenSearch core.If the community confirms the request is in scope and indicates which repository should own it (this one,
opensearch-project/opensearch-prometheus-exporter, or both via a shared SPI), we are willing to provide the implementation, and long-term maintenance, following that project's contribution guidelines.