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. Two things in that sentence matter. 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.
To be clear: 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.
Everything below also applies to OpenSearch 3.8, released on August 4, 2026; the exporter plugin has a matching 3.8.0.0 release as well.
What actually shipped, and when
The feature landed over three releases: 3.5 (February 2026) brought the Discover experience for Prometheus metrics with PromQL autocomplete, 3.6 (April 2026) the docker-compose Observability Stack bundle, and 3.7 made it 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 |
| 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 exposed metrics through PPL and SQL rather than PromQL. Per the release blog, 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 Management > Data sources > New data source > Prometheus (the docs wording; the workspace navigation labels it slightly differently), 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 prometheus.auth.region, prometheus.auth.access_key, and prometheus.auth.secret_key; leaving out the region is the usual reason a SigV4 source fails to connect. If you created the data source outside a workspace, associate it with your Observability workspace afterwards or the Metrics page will not list it. 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. 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.
Why not just Grafana? If your team lives in Grafana, keep it; its panel ecosystem and alerting are far more mature than what Dashboards offers today. The case for Dashboards is narrower: one login, one set of roles, and one screen when you are pivoting from a trace or a log line to the metric behind it. Teams that already run OpenSearch for logs and traces get that for free. Teams that only need metric dashboards do not gain much.
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.
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, 3.8.0.0 for 3.8) 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. The README warns, and we have seen it: 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
- The native PromQL integration is query-side only: your data stays in Prometheus, and it does nothing for monitoring OpenSearch itself. That still needs the version-matched exporter plugin on every node.
- The unified alerts view and SLO catalog are experimental and off by default; the core data source and Explore Metrics are the parts to rely on.
