OpenSearch 3.7 lets Dashboards query your existing Prometheus servers with native PromQL - no data migration, no query translation. Here is how to set it up, what the new Explore Metrics experience does, and how it differs from the Prometheus exporter plugin.
OpenSearch 3.7, released on June 9, 2026, ships native Prometheus integration: OpenSearch Dashboards connects directly to your existing Prometheus servers as a data source and runs PromQL against them, alongside your logs and traces, without migrating any data. That one sentence carries two claims worth unpacking. First, the PromQL is native - OpenSearch executes your query as-is rather than translating it into PPL or some internal dialect, so anything you build in Dashboards stays portable back to Grafana or promtool. Second, this is a query-side integration, not an exporter. Your metrics stay in Prometheus; OpenSearch becomes a place to look at them.
That second point trips people up, so let's state it plainly before the walkthrough: OpenSearch 3.7 does not add a scrape endpoint for monitoring OpenSearch itself. If you want Prometheus to scrape your cluster's JVM and indexing metrics, you still need the Prometheus exporter plugin, covered at the end of this post.
What actually shipped, and when
The feature landed incrementally over three releases. OpenSearch 3.5 (February 2026) introduced a new Discover experience for Prometheus metrics with PromQL autocomplete. OpenSearch 3.6 (April 2026) launched the Observability Stack, a docker-compose bundle wiring together an OpenTelemetry Collector, Data Prepper, OpenSearch, Prometheus, and Dashboards. OpenSearch 3.7 is where the pieces became a headline feature, per the release announcement and release notes:
| Feature | Status in 3.7 | What it does |
|---|---|---|
| Prometheus data source with native PromQL | Release highlight | Query Prometheus from Dashboards next to logs and traces |
| Explore Metrics | Release highlight | Guided metric-to-labels-to-functions navigation that generates valid PromQL live |
| Dashboard variables | Release highlight | $name / ${name} substitution placeholders in dashboards |
| Data transformation | Release highlight | Limit, sort, filter, computed fields, and aggregations on results, with cross-query PromQL support |
| Unified alerts view | Experimental | One inbox for OpenSearch monitors and Prometheus/Alertmanager rules, with a read-only view of your routing tree |
| SLO catalog | Experimental | Ranks SLOs by remaining error budget, with burn-rate alerts and multi-window evaluation |
Under the hood this builds on the SQL plugin's Prometheus connector, which has existed since OpenSearch 2.4 but only spoke PPL. Single servers, HA pairs, and federated Prometheus setups all work, as does Amazon Managed Service for Prometheus. Your recording rules and Alertmanager routing keep running untouched.
Step 1: Turn on the feature flags
The Metrics experience lives inside the workspaces-based Dashboards UI, so four flags need to be on in opensearch_dashboards.yml (per the official docs):
workspace.enabled: true
data_source.enabled: true
explore.enabled: true
explore.discoverMetrics.enabled: true
Restart Dashboards after editing. Then create a workspace of type Observability - the Metrics page only appears in that workspace type, under Discover > Metrics. This is the one part of the setup that feels unfinished: the release blog presents the feature as a highlight, yet the docs still gate it behind explicit flags rather than shipping it on by default.
Step 2: Connect your Prometheus server
In Dashboards, go to Data Administration > Data sources > Create data source, pick Prometheus, give it a name, and point it at your server's HTTP endpoint, for example http://prometheus-server:9090. Three authentication modes are available: none, basic auth, and AWS Signature V4 for Amazon Managed Service for Prometheus. You can also mark the connection as restricted and bind it to a role, so not every Dashboards user can query it.
Prefer automation? The same connection can be created through the SQL plugin's data source API:
POST _plugins/_query/_datasources
{
"name": "my_prometheus",
"connector": "prometheus",
"properties": {
"prometheus.uri": "http://localhost:9090"
}
}
For AMP, add "prometheus.auth.type": "awssigv4" plus the region and credentials. Note there is no scrape_config to write anywhere - OpenSearch pulls from Prometheus's HTTP API, not the other way around.
Step 3: Query with PromQL in Explore Metrics
Open Discover > Metrics in your Observability workspace. Explore Metrics auto-detects Prometheus data sources and walks you from metric name to labels to aggregation to functions, generating valid PromQL at every step. The builder and the raw editor stay in sync, so you can start guided and drop to raw text when the query gets hairy.
A minimal sanity check:
up{job="prometheus"}
From there the editor gives you label autocomplete, syntax highlighting, and both instant and range queries. Several PromQL queries separated by ; run together with combined output. Results render as raw JSON, a table, or line, bar, pie, and gauge charts, and the new transformation pipeline lets you sort, filter, and add computed fields on top - across queries. There's a public playground if you want to poke at all of this without deploying anything.
If you're already shipping traces to OpenSearch, this closes the loop we described in our OpenTelemetry with OpenSearch guide: logs, traces, and now Prometheus metrics behind one interface and one authentication context.
Optional: alerts and SLOs (experimental)
Two 3.7 additions are behind their own flags, both off by default:
observability.alertManager.enabled: true
observability.slo.enabled: true
The unified alerts view (PR #2653) merges OpenSearch monitors and Prometheus alerting rules into a single severity-sorted inbox and renders your Alertmanager routing tree read-only - your pipeline keeps firing exactly as before. The SLO catalog (PR #2676) ranks every SLO by remaining error budget and supports burn-rate alerts with multi-window evaluation. Both are experimental; expect rough edges and treat them as previews, not production tooling.
The other direction: monitoring OpenSearch with Prometheus
The inverse problem - getting OpenSearch's own metrics into Prometheus - is still solved by the exporter plugin, which has moved from Aiven's community repo into the official opensearch-project org. Install the matching version (3.7.0.0 for OpenSearch 3.7) on every node you want scraped, then scrape /_prometheus/metrics on port 9200:
- job_name: opensearch
scrape_interval: 10s
metrics_path: "/_prometheus/metrics"
static_configs:
- targets: [node1:9200, node2:9200, node3:9200]
You get opensearch_-prefixed families covering cluster health, JVM, indexing, search contexts, circuit breakers, and more. One caveat from the README worth repeating: index-level metrics can produce high-cardinality labels in Prometheus, and prometheus.indices: false turns them off. The plugin is version-locked, so plan to reinstall it on every upgrade. For a broader look at cluster monitoring options, see our Amazon OpenSearch monitoring comparison.
Key takeaways
- OpenSearch 3.7 (June 9, 2026) queries your existing Prometheus servers with native, portable PromQL - data stays in Prometheus, and there's no migration or query translation.
- Setup is four Dashboards feature flags, an Observability workspace, and a data source pointing at your Prometheus HTTP endpoint (basic auth and SigV4 supported).
- Explore Metrics generates valid PromQL as you navigate from metric to labels to functions, with the builder and raw editor kept in sync.
- The unified alerts view and SLO catalog are experimental in 3.7 and disabled by default.
- This feature does not expose OpenSearch's own metrics. For that, install the version-matched Prometheus exporter plugin on every node and watch out for high-cardinality index-level labels.
