A practitioner guide to OpenSearch Dashboards in 2026: Discover, visualizations, workspaces, DQL/PPL/SQL query languages, alerting, anomaly detection, and how it differs from Kibana.
OpenSearch Dashboards started life as a fork of Kibana 7.10, the last Apache-2.0 release before Elastic relicensed in January 2021. Five years on, calling it "the Kibana fork" undersells it. The 2.x and 3.x lines have grown their own surface area: workspaces for scoping use cases, native multi-data-source connectivity, PPL and SQL as first-class query languages, and an LLM-backed assistant. If you run OpenSearch and treat Dashboards as a read-only viewer, you are using a fraction of what it does.
This guide covers the parts that matter to people running OpenSearch in production: how to explore data in Discover, build visualizations and dashboards, pick the right query language, wire up alerting and anomaly detection, and decide where Dashboards stands against Kibana in 2026.
What OpenSearch Dashboards Is and How It Fits Together
OpenSearch Dashboards is the open-source visualization and management layer for an OpenSearch cluster. It is a Node.js server that talks to the cluster over REST and serves a React single-page app to the browser. The browser never queries the cluster directly; every Discover search, every dashboard panel, and every Dev Tools call routes through the Dashboards server.
Three pieces make up the runtime. The OpenSearch cluster holds your data and runs the queries. The Dashboards server runs the plugin system and persists its own state (saved searches, visualizations, dashboards, index patterns) as saved objects in a dedicated system index, historically .kibana and now .opensearch_dashboards. The browser app renders results and sends user actions back as REST requests.
A few primitives recur throughout the product:
- Index patterns define which indices, data streams, or aliases a view reads from, plus the time field used for range filtering. OpenSearch Dashboards kept this term; Kibana renamed the same concept to "data views" several versions ago. The label differs, the idea is identical.
- Saved objects are the portable unit of work. Searches, visualizations, dashboards, and index patterns export and import as NDJSON, so they version in Git and promote across clusters.
- Dashboards compose saved visualizations into panels with shared time ranges, filters, and interactive controls.
Versioning is strict: the Dashboards version always matches the OpenSearch engine version one-to-one. Run Dashboards 2.17 against a 2.17 cluster, not a 2.13 one. Minor releases land roughly every six weeks, with patch releases for CVEs in between.
Installation, Connecting Clusters, and Multi-Data-Source
For local work, the Docker image opensearchproject/opensearch-dashboards paired with an OpenSearch container via Docker Compose is the fastest path. For servers, tarball, RPM, and DEB packages are available, and there is a community Helm chart plus the OpenSearch Kubernetes Operator for clusters. If you would rather not run the control plane yourself, Amazon OpenSearch Service (both provisioned and serverless), Aiven, and Instaclustr all bundle Dashboards.
In the simplest setup, you point Dashboards at one cluster through opensearch.hosts in opensearch_dashboards.yml. The more interesting capability is multi-data-source, which lets a single Dashboards instance connect to several OpenSearch clusters and some external sources, with per-source authentication.
Multi-data-source lets one OpenSearch Dashboards instance query and visualize data from multiple OpenSearch clusters and supported external sources, each with its own credentials, without standing up a separate Dashboards deployment per cluster.
That matters in two situations: a federated view across prod, staging, and dev from one console, and cross-account AWS clusters where each source authenticates with its own SigV4 or IAM role. A basic-auth dev cluster and a SigV4 managed cluster can sit side by side.
One practical tip on index patterns: model them around logical data streams, not physical indices. A logs-* pattern over daily rollover indices is far easier to live with than one pinned to a single index name. Keep logs-*, metrics-*, and traces-* separate so Discover and your visualizations stay aligned to the shape of the data.
Exploring Data in Discover
Discover is where most investigations start. You pick an index pattern, set a time range, and query. The search bar accepts three languages, and knowing which to reach for saves time.
DQL (Dashboards Query Language) is the default. It is the everyday syntax: status:500, bytes >= 1024, host:web-*, field existence with field:*, and boolean combinations with and/or/not. It has autocomplete and field suggestions, which makes it forgiving for ad-hoc filtering.
Lucene is the power-user fallback. Switch to it when you need regular expressions (message:/error.*timeout/), proximity ("error timeout"~5), or per-term boosting. DQL does not cover those.
PPL (Piped Processing Language) brings a Unix-pipe mental model to log exploration. Instead of nesting clauses, you chain stages:
source = logs-* | where status >= 500 | stats count() by host | sort - count()
For anyone coming from Splunk SPL, PPL will feel familiar. It shines for aggregation-heavy triage where DQL would force you out to a visualization. For a deeper set of working queries, see our OpenSearch PPL examples.
Beyond the query bar, Discover lets you add and reorder columns, expand individual documents, view surrounding documents around a hit, and save a search for reuse. A saved search is not just a bookmark; it becomes a building block you can drop into visualizations and dashboards. A typical incident workflow looks like this: narrow the time range to the spike, filter by service with a DQL clause, switch to PPL to count errors by host, then pivot on a trace ID to follow a single request. Results export to CSV when you need offline analysis, subject to a row cap you can raise in Advanced Settings.
Visualizations, Dashboards, and Workspaces
Most charts in Dashboards are aggregation-based. You choose a chart type, then define bucket aggregations (terms, date histogram, ranges, filters) and metric aggregations (count, average, sum, percentiles, unique count). Supported types cover the usual set: vertical and horizontal bar, line, area, pie and donut, data table, metric, gauge, and goal.
When the classic wizard is more clicks than you want, VisBuilder offers a drag-and-drop builder with live preview. It supports a focused set of chart types: area, bar, line, metric, and data table. It does not yet cover every visualization the classic editor does, so treat it as a faster path for common charts rather than a full replacement.
For anything the aggregation editor cannot express, Vega and Vega-Lite give you a full grammar of graphics inside Dashboards. You write a spec, pull data through the %opensearch% data source, and control marks, signals, and layout directly. This is the route for multi-series layouts and custom chart types like a three-dimension bubble chart. We walked through exactly that pattern in building a bubble chart with Vega, and the spec carries over to OpenSearch Dashboards with minimal change. Two legacy time-series tools, TSVB and Timeline (Timelion), came over in the 7.10 fork and still work, but they are de-emphasized. For new work, prefer aggregation-based charts or Vega.
A dashboard assembles these panels with shared time ranges and filters, plus a controls panel for interactive dropdowns and range sliders. Click-through drilldowns let a user click a bar segment and land in a filtered Discover view or another dashboard.
Workspaces are the larger organizational shift. Introduced in 2.12 and matured across the 2.x line, a workspace gives a team an isolated container of saved objects, scoped navigation, and use-case-specific configuration (Observability, Security Analytics, Search, Essentials, or Analytics). A "Security" workspace and a "Platform Engineering" workspace can live in the same Dashboards instance without their saved objects colliding.
Workspaces are not the same as the Security plugin's multi-tenancy, and the difference is worth stating plainly:
| Capability | Workspaces | Security plugin multi-tenancy |
|---|---|---|
| Isolation unit | Saved objects per workspace | Saved objects per tenant |
| Enforced by | UI-level scoping | RBAC, backed by roles |
| Setup weight | Lighter, UI-driven | Heavier, role-mapping driven |
| Best for | Team-level organization | Strict access boundaries |
Use multi-tenancy when you need hard RBAC boundaries between groups who must not see each other's objects. Use workspaces to keep teams' work organized within a tenant. They compose: workspaces sit inside the access model the Security plugin defines.
Choosing a Query Language
OpenSearch Dashboards exposes four query languages, and they are not interchangeable. Every visualization ultimately compiles to Query DSL, the JSON query language the cluster runs. You rarely write it by hand, but when a dashboard is slow, open the panel inspector to read the generated DSL: a runaway high-cardinality terms aggregation or an unbounded date range is usually visible there.
SQL rounds out the set. OpenSearch supports a SQL interface with SELECT, JOINs, subqueries, and aggregations, exposed through the SQL/PPL Workbench in Dashboards along with JDBC and ODBC drivers for BI tools. SQL is the bridge when a stakeholder wants OpenSearch data in Tableau, Grafana, or Excel.
Here is how to choose:
| Use case | Reach for | Why |
|---|---|---|
| Dashboard and Discover filters | DQL | Default syntax, autocomplete, fast to type |
| Regex, proximity, boosting | Lucene | DQL does not support these |
| Ad-hoc log triage and aggregation | PPL | Pipe model, Splunk-like, no viz needed |
| Joins, BI tool connectivity | SQL | ANSI-style SQL plus JDBC/ODBC drivers |
| Debugging a slow panel | Query DSL | See exactly what the cluster runs |
The short version: DQL for everyday filtering, Lucene when DQL runs out, PPL for interactive log analytics, SQL for joins and external tools, and Query DSL when you need to know what is actually hitting the cluster.
Analytics Add-ons: Alerting, Anomaly Detection, and the Assistant
Dashboards is also the control surface for OpenSearch's analytics plugins.
Alerting runs monitors that evaluate on a schedule and fire actions. Monitor types include per-query, per-bucket, per-document, and composite. Triggers carry severity levels and route to Slack, email, webhooks, or SNS. A useful rule of thumb: per-document monitors fit security events where you care about each matching record, and per-bucket monitors fit SLO breaches where you care about an aggregate crossing a threshold.
Anomaly Detection uses high-cardinality anomaly detection (HCAD), a Random Cut Forest model that learns normal behavior. One detector tracks thousands of entities at once. You define features as aggregations over a detector interval, and results come back with an anomaly grade and a confidence score that you can overlay on time-series panels.
Anomaly Detection in OpenSearch uses high-cardinality detectors built on Random Cut Forest, letting a single detector track anomalies across thousands of entities, each scored with an anomaly grade and confidence value.
OpenSearch Assistant is the natural-language layer. It can turn questions into PPL, summarize alerts, and explain log patterns. Two caveats matter before you promise it to anyone. It is not on by default: you enable it in opensearch_dashboards.yml (for example assistant.chat.enabled: true), and some capabilities such as text-to-visualization remain behind experimental flags. It also requires an ML Commons connector to an external LLM (Amazon Bedrock, OpenAI, Cohere, SageMaker, and similar), which means you must register a trusted connector endpoint and accept that prompts and context leave the cluster for that provider. Treat data privacy as a design decision, not an afterthought.
Beyond these, the Observability plugin covers Trace Analytics (OpenTelemetry via Data Prepper), metrics, and PPL-driven event analytics, while Security Analytics provides a SIEM-style experience with Sigma-based detection rules, findings, and correlation rules. If you are weighing how all this lands on managed AWS, the plugin surface differs between provisioned and serverless, which we cover in AWS OpenSearch Service architecture and best practices.
OpenSearch Dashboards vs Kibana in 2026
The two share DNA, so Discover, Visualize, and Dashboard feel familiar in both. The divergence is now real enough to drive a decision.
| Area | OpenSearch Dashboards | Kibana |
|---|---|---|
| License | Apache 2.0, fully open source | Elastic License / commercial tiers |
| Drag-and-drop builder | VisBuilder (subset of chart types) | Lens (polished, production-grade) |
| Piped query language | PPL (also SQL) | ES|QL |
| Multi-cluster UX | Native multi-data-source, no paid tier | Cross-cluster, parts behind tiers |
| ML / models | ML Commons, deploy any model, open | Built-in ML in Platinum+ |
| AI assistant | OpenSearch Assistant, LLM-agnostic | Elastic AI Assistant |
| Workspaces | Native, UI-driven scoping | Spaces |
| SIEM | Security Analytics, open source | Elastic Security, commercial features |
Where Kibana leads: Lens is a more mature visualization builder than VisBuilder, and ES|QL is a tightly integrated piped query language with momentum. Several of Elastic's strongest pieces, including advanced ML and security tooling, sit in commercial tiers.
Where OpenSearch Dashboards leads: workspaces, multi-data-source, PPL, SQL, ML Commons, Security Analytics, and the Assistant are all available without a license gate. If avoiding vendor lock-in and paid tiers is a priority, that is the differentiator.
Migration is mostly tractable. Saved objects exported from Kibana up to the 7.10 schema import cleanly; later objects often need rework. KQL maps almost directly to DQL. ES|QL and PPL are different languages, so those queries are a rewrite. We go deeper on the engine-level tradeoffs in OpenSearch vs Elasticsearch compared.
Key Takeaways
- OpenSearch Dashboards is the open-source visualization and management layer for OpenSearch: a Node.js server plus a React app, talking to the cluster over REST, with saved objects as the portable unit of work.
- It retains the term "index patterns"; "data views" is Kibana-only terminology.
- Four query languages serve different jobs: DQL for everyday filtering, Lucene for regex and proximity, PPL for piped log analytics, SQL for joins and BI tools, with Query DSL underneath everything.
- VisBuilder is a drag-and-drop builder covering a subset of chart types; reach for Vega when aggregation-based charts fall short. TSVB and Timeline are legacy.
- Workspaces (introduced in 2.12, matured across 2.x) scope saved objects per team; the Security plugin's multi-tenancy enforces RBAC boundaries. They serve different needs and compose.
- OpenSearch Assistant is not on by default and needs an ML Commons connector to an external LLM, which carries data-privacy implications.
- Against Kibana, OpenSearch Dashboards trades Lens and ES|QL maturity for fully open-source workspaces, multi-data-source, PPL/SQL, ML Commons, and Security Analytics with no paid tier.
If you are standing up OpenSearch Dashboards in production, the work that pays off is up front: workspace and RBAC design, query-language conventions for your teams, and a saved-object promotion pipeline. That is exactly the kind of architecture review and migration work we do day to day.
