How Grafana connects to OpenSearch and Elasticsearch
If your logs or metrics already sit in OpenSearch or Elasticsearch, Grafana can query them directly and drive dashboards and alerts from the same data, without copying it elsewhere. Two supported methods cover this. The first is the Grafana OpenSearch data source plugin, which queries OpenSearch and Amazon OpenSearch Service with either Lucene or Piped Processing Language (PPL) and requires Grafana 10.4.0 or later. The second is the built-in Elasticsearch data source, which supports metrics, log, raw DSL and ES|QL queries on Elasticsearch 7.17 or later, 8.x or 9.x. Choose the method by the cluster you run, not by the query language you like best: an OpenSearch cluster uses the plugin, and an Elasticsearch cluster uses the built-in data source.
The choice of query language follows from what your teams already know and what the cluster supports. Lucene query strings suit teams migrating from Kibana or OpenSearch Dashboards searches, while PPL suits teams that want piped, SQL-like queries. On the Elasticsearch side, raw DSL remains the most complete option for complex aggregations, and ES|QL is the newer pipe-style language. Confirm which features each language supports in your Grafana version, because the OpenSearch plugin notes traces are available with Lucene only. Also confirm that your cluster version is inside the supported range before you plan dashboards around it.
DeployOpen plans and implements this connection inside your own infrastructure: the Grafana instance, the cluster network path, the service accounts and read-only roles Grafana uses, and the data source provisioning files. Scope usually includes mapping existing Kibana or OpenSearch Dashboards views to Grafana panels, setting up alert rules on search queries, and checking that query load on the cluster stays acceptable. Ask any implementation partner to confirm in writing which Grafana and cluster versions they will test against, and who owns upgrades for each side. Reviewing the Grafana OpenSearch data source documentation before scoping is a useful first step.
What you need before connecting Grafana to your search cluster
Connecting Grafana to OpenSearch or Elasticsearch touches three systems: the Grafana instance, its configuration database, and the search cluster itself. Confirm the version and access requirements for each before anyone builds a dashboard, because most connection failures trace back to one of these five items.
Grafana version for the OpenSearch plugin
The OpenSearch data source plugin requires Grafana 10.4.0 or later. Check your running version before you install anything, and plan upgrades against the Grafana release cadence if you are behind. Confirm that your target Amazon OpenSearch Service domain is supported by the plugin version you intend to install, using the plugin documentation as the reference.
Supported Elasticsearch versions
The built-in Elasticsearch data source works with Elasticsearch 7.17, 8.x and 9.x. Versions outside that range, including 7.16 and earlier, are not covered by the data source docs. Record the exact cluster version, because the query types you can use, such as ES|QL, depend on it. Ask your cluster owner whether the cluster is on a supported line before you commit to a design.
Production database for Grafana
Grafana stores its configuration in SQLite by default, but SQLite does not scale for production. Plan a MySQL 8.0 or later, or PostgreSQL 12 or later, database before you add search data sources, because dashboards, data source definitions and users all live there. Confirm backup and restore ownership for this database, since losing it means losing the dashboards your teams rely on.
Network paths and TLS certificates
Grafana's server must reach every search node or the cluster endpoint over the network, which often means firewall rules between a monitoring subnet and a data subnet. Decide whether traffic is encrypted with TLS end to end, and confirm which certificate authority signs the cluster certificates so Grafana trusts them. Test with the exact hostname Grafana will use, because certificate name mismatches are a common cause of failed connections.
Read-only service account on the cluster
Create a dedicated service account on the search cluster that can read only the indices and fields your dashboards need. Avoid reusing an administrator or a person's account, since Grafana stores the credentials in its own configuration. Use the OpenSearch Security role model or the Elasticsearch role-based access control features available on your subscription tier to restrict index patterns, and confirm with your cluster owner which features your license covers.
Choosing the OpenSearch plugin or the Elasticsearch data source
If your logs and metrics live in OpenSearch or Amazon OpenSearch Service, the Grafana OpenSearch data source plugin is the path to take. It queries with Lucene or Piped Processing Language (PPL), requires Grafana 10.4.0 or later, and supports alerting and annotations. Logs and metrics work with both query languages, but traces are supported with Lucene only, so a PPL-based trace view is not a safe assumption.
- Query languages: Lucene suits field searches and existing Kibana or OpenSearch Dashboards queries, while PPL suits pipeline-style aggregation over indexed fields.
- Traces: Plan trace panels around Lucene queries and confirm the trace fields your index mappings expose.
- Alerting: Alert rules can be built on search results, so test the threshold logic against real index volume before relying on it.
- Annotations: Annotations from log events can be added to time series panels, which helps during incident review.
- Version coupling: Check that your OpenSearch version and the plugin version match the Grafana release you run.
Confirm current feature coverage for your OpenSearch version in the plugin documentation before you commit to a query language.
If your data sits in Elasticsearch, use the built-in Elasticsearch data source. Its documented query types are metrics, logs, raw Query DSL and ES|QL, along with annotations and alerting. It requires Elasticsearch 7.17 or later, 8.x or 9.x, so older 7.x clusters need an upgrade plan before Grafana work can start.
- Query types: Metrics and log queries use the visual builder, raw DSL gives full control over the request body, and ES|QL is available for piped queries.
- Version range: Confirm your exact minor version against the supported range, since the line between 7.17 and later releases matters.
- Authoring effort: Raw DSL and ES|QL need query expertise in the team, so plan review and saved query ownership.
- Alerting: Rules can run on the query types the data source documents, and you should test each query type you intend to alert on.
- Features tied to license: Some Elastic security and anomaly features depend on subscription tiers, so verify what your cluster license allows.
Check the query types and version range against the Elasticsearch data source documentation for your Grafana release before you standardize on one.
The two plugins do not share a query model, so dashboards cannot be ported by copying queries between them. Lucene and Elasticsearch Query DSL both express field matches and aggregations, but their syntax, bucket definitions and time filter handling differ. PPL and ES|QL are also distinct pipeline languages with different function sets, so each needs its own review standard.
- Field mapping: Index mappings, keyword versus text fields and timestamp fields drive whether a query returns results at all.
- Time filters: Confirm how each plugin applies the dashboard time range so panels and alerts agree.
- Aggregation limits: Large cardinality terms aggregations can be slow or inaccurate, so set size limits deliberately.
- Saved queries: Document which team owns each query, since raw syntax is hard to review in a shared instance.
- Migration from Kibana: Dashboards built in Kibana or OpenSearch Dashboards need query translation, not a direct import.
Test each converted query against a known time window and compare results with the source interface before you retire the original view.
Feature coverage changes between plugin and Grafana releases, so the table of supported query types, alerting, annotations and trace support should be treated as a checklist to confirm rather than a fixed promise. Each item below needs a check against the documentation for the exact versions in your environment before design decisions depend on it.
- Logs and metrics: Confirm which query types return log views and which return time series for your cluster version.
- Traces: Confirm trace query support and the query language it requires in your release.
- Alerting: Confirm alert evaluation on each query type you plan to use, including how the cluster load is affected.
- Annotations: Confirm annotation query support for both logs and metrics.
- Security features: Confirm which access controls, such as document-level security, apply to Grafana queries under your identity setup.
Record the results in a short compatibility matrix that names the Grafana, plugin and cluster versions tested.
Some organizations run OpenSearch for one set of workloads and Elasticsearch for another, or are moving from one to the other. Grafana can connect to both, but each connection is a separate data source with its own plugin, query model and version constraints. Mixed estates need a clear rule for which data source a dashboard uses and who maintains it.
- Separate data sources: Create one data source per cluster, with names that show the platform and environment.
- Shared dashboards: Avoid panels that mix query languages from both platforms unless the team has tested them together.
- Migration sequencing: Move dashboards after the underlying index or cluster move is verified, not before.
- Access control: Map user roles in each cluster to Grafana permissions so access stays consistent.
- Version planning: Track both cluster and Grafana upgrade schedules, since a Grafana upgrade may change plugin requirements.
Before a migration, confirm the target platform's supported versions and the Grafana release you plan to run.
Configuring the data source step by step
This sequence takes a self-hosted Grafana from a confirmed version match with your search cluster to a working data source, a verified first panel and a first alert rule, with a check at each stage so problems surface before dashboards depend on them.
Confirm versions on Grafana and the search cluster
The platform team checks the running Grafana version and the OpenSearch or Elasticsearch version against the data source requirements. The OpenSearch plugin requires Grafana 10.4.0 or later, and the Elasticsearch data source requires Elasticsearch 7.17 or later, 8.x or 9.x. Confirm the chosen Grafana release line is still supported in the upgrade guidance, and record both versions in your change ticket. This step is done when both versions are written down and each one meets the stated minimum. If the cluster is on a version outside the listed range, stop here and plan the cluster upgrade first.
Install the OpenSearch plugin if you use it
If you connect to OpenSearch or Amazon OpenSearch Service, install the Grafana OpenSearch data source plugin on each Grafana node or in the container image, using the install method your deployment already uses. The Elasticsearch data source is built into Grafana, so this step can be skipped for Elasticsearch-only setups. Restart Grafana and open the plugin catalog to confirm the plugin loads without errors in the server log. Done when the plugin shows as installed on every node, including each node behind your load balancer.
Create a least-privilege read user on the cluster
The security team creates a dedicated cluster user for Grafana with read access limited to the index patterns the dashboards need. On OpenSearch, use the Security plugin's roles and role mappings. On Elasticsearch, use native users or roles in the security realm your subscription supports, since some role features depend on the tier. Confirm with your vendor which field-level or document-level restrictions your edition enables before relying on them. Done when a login with that user can read the target indices and is refused on an index it should not see.
Configure the data source URL, TLS and authentication
In Grafana, add the data source, enter the cluster URL, and set the TLS options so Grafana verifies the cluster certificate against your internal certificate authority. Choose basic authentication with the read user, or the authentication method your cluster accepts for service accounts, and store the password in Grafana's secure fields rather than in provisioning files in plain text. Save the data source and select the test option. Done when the data source test reports a successful connection. A failure usually points to a certificate chain, a network path, or a role that cannot see the cluster's metadata.
Set the index pattern and time field
Set the index name or pattern that matches the logs or metrics you intend to chart, and select the timestamp field that Grafana uses for time filtering. Use a pattern narrow enough to exclude indices you do not need, since broad patterns increase query load on the cluster. Confirm the field is a date type in the mapping, because a string timestamp will not filter correctly. Done when the time field appears in the field list and a query limited to the last hour returns documents with recent timestamps.
Run a test query in the query language you chose
Run a simple query in the language your team will use: Lucene or PPL for OpenSearch, and DSL or ES|QL for Elasticsearch. Start with a count of documents over a known time range, and compare the result with a count you obtain directly from the cluster using the same filter. Confirm the query also works with the time range set to the last hour and the last day. Done when the Grafana result matches the cluster count for the same filter and window. A mismatch usually comes from the time field, a timezone difference, or an index pattern that includes more indices than expected.
Build the first panel against a known count
Create a time series or stat panel from the test query, group it by a field with known values such as a service name or log level, and set the panel time range to match the window you used for the cluster count. Compare the panel totals with the numbers from the cluster for the same window and filter. Add the panel to a dashboard, save it, and reload the page to confirm the panel still returns the same values. Done when the panel totals match the cluster for at least one known window and the dashboard survives a reload.
Create the first alert rule on a search query
Create an alert rule from the same query, with a condition such as the document count above a threshold over a short evaluation window, and route it to a test contact point. Confirm the rule evaluates on schedule and that the state changes when you temporarily lower the threshold on a test copy. Check that the alert notifications reach the test contact point and that the rule is recorded in your change documentation. Done when a forced trigger produces a firing notification and the rule returns to normal once the condition clears.
Mapping fields, time, and roles between the search cluster and Grafana
This table maps the search cluster concepts you will configure in Grafana to the settings and query syntax they touch, for both the OpenSearch plugin and the Elasticsearch data source. Read each row alongside your own index templates, because field types and mappings differ between environments and must be confirmed there before you build panels or alert rules.
| Concern | What to map in Grafana | What to confirm in the cluster |
|---|---|---|
| Index patterns | Data source index or index pattern setting, matched to the indices your dashboards and alerts should read | Index naming, rollover aliases and whether wildcards would pull in unrelated indices |
| Time field | Time field name in the data source settings, which drives the Grafana time range filter on every query | The date type of the field, its timezone handling and whether ingest sets it consistently |
| Keyword fields | Exact-match filters and terms aggregations in the DSL or visual builder, using the keyword sub-field where one exists | Whether the field is mapped as keyword, and whether aggregations are blocked by high-cardinality or text-only mappings |
| Text fields | Full-text matching in Lucene query strings for OpenSearch, or match queries in raw DSL for Elasticsearch | Analyzer settings, and whether a keyword sub-field exists for exact filters on the same value |
| Log message and level | Message and level fields mapped in the logs view so Grafana shows the message body and severity column | Field names in your log pipeline, since level values may differ in case or format between sources |
| Cluster roles and access | Data source credentials and permissions set per user or team in Grafana, matched to cluster roles that allow only read access to the needed indices | Index-level read privileges, and whether document or field security in the cluster hides data Grafana users expect to see |
| Query language version | Lucene or PPL for OpenSearch, DSL or ES|QL for Elasticsearch, chosen per panel and per alert rule | Engine versions in use, since the Grafana docs set minimum versions for each data source plugin |
Securing the connection and limiting query access
A Grafana data source is only as narrow as the account behind it and the path it takes to the cluster. The cards below cover the Grafana side of the connection, the cluster-side identity and authorization options for OpenSearch and Elasticsearch, and the controls whose availability depends on your edition or license.
Read-only search users
Create a dedicated user for each Grafana data source that can read only the index patterns its dashboards use. Avoid reusing an administrator or an ingest account, because a leaked Grafana credential would then reach every index. Check that the role grants read and search rights only, and test by running a dashboard query and a write attempt with that user. Confirm how index-level permissions are named in your cluster version before you write the role.
TLS for cluster traffic
Encrypt the connection between Grafana and the cluster, and between cluster nodes, so queries and results are not sent in clear text. Confirm the certificate chain that Grafana trusts, including any internal certificate authority, and whether the data source should verify the server name. Plan certificate renewal before the first expiry, since a lapsed certificate stops every dashboard and alert that uses the data source.
Credentials in Grafana provisioning
Define the OpenSearch or Elasticsearch data source in provisioning files so the URL, user and secret are set at startup rather than typed into the UI. Keep the password in an environment variable or a secret store that your platform injects, and keep it out of files committed to Git. Review who can read the provisioning directory on the Grafana host, since that is where the secret would otherwise be exposed.
OpenSearch Security authentication and roles
The OpenSearch Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token backends, and it provides role-based access control. Map your directory groups to cluster roles so that a Grafana service account inherits only the reads it needs. Confirm which backends your OpenSearch version and distribution enable by default, since the plugin configuration differs between installations.
Document and field-level restrictions
OpenSearch Security offers document-level and field-level security along with field masking, which can hide sensitive fields such as personal identifiers from a dashboard user. Elasticsearch offers the same class of control, but its document- and field-level security sits in paid subscription tiers. Confirm the license of the specific cluster before you design a dashboard that depends on these controls, because a Grafana panel will fail to show data the role cannot see.
Elasticsearch features by subscription tier
Elastic made TLS, the native user realms and role-based access control free in the Basic tier, while single sign-on, Active Directory and LDAP authentication, and field- or document-level security remain in paid tiers. Single sign-on through SAML, OpenID Connect, Kerberos and JWT is a self-managed subscription feature. Check the subscription on your cluster before you rely on any of these features for Grafana access, and ask Elastic which tier applies if you are unsure.
Grafana hardening settings
Apply the Grafana security hardening settings that cover secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, and domain verification against DNS rebinding. Require authentication on the metrics endpoint so that Grafana internals are not visible to anonymous callers. Review these settings after each upgrade, because defaults and available options can change between releases.
Common failures when Grafana cannot query the search cluster
This table lists the failures teams hit most often when Grafana cannot read from OpenSearch or Elasticsearch, with the likely cause and first fix for each. Work through the rows in order when a panel is empty or an alert fails, because version and certificate problems block every query before any data is read.
| Failure | Likely cause | Fix |
|---|---|---|
| Data source fails to save or connect | Elasticsearch below 7.17, or an Elasticsearch or OpenSearch version outside the range the Grafana data source docs list | Confirm the cluster version against the Elasticsearch data source docs or the OpenSearch plugin requirements, and confirm the Grafana version meets the plugin minimum (10.4.0 for the OpenSearch plugin) |
| TLS certificate trust errors | The cluster certificate is issued by an internal CA that the Grafana server does not trust, or the hostname does not match the certificate | Add the CA certificate to the Grafana host trust store, match the URL hostname to the certificate subject, and test the connection from the Grafana host before editing the data source |
| Authentication failures for the read user | The read user lacks index read permissions, the password was rotated, or the role maps only to a different tenant or security realm | Create a dedicated read-only role limited to the required index patterns, confirm the user can run a search with curl from the Grafana host, and store credentials as provisioned secrets |
| Empty panels with data in the index | The time field setting does not match the timestamp field in the documents, or the index pattern does not match the index names | Set the time field to the exact mapped date field, check the index pattern against index names on the cluster, and confirm the panel time range overlaps the stored data |
| Query timeouts on wide time ranges | Large time windows with high-cardinality terms aggregations exceed the query timeout or overload data nodes | Narrow the default time range, reduce bucket counts and terms sizes, add filters on indexed fields, and raise the data source timeout only after confirming the cluster has capacity |
| Alert evaluations fail or fire twice in HA | Alerting needs additional configuration for high availability, so several Grafana nodes may evaluate the same rule or lose state after a node restart | Follow the Grafana high availability alerting guidance, confirm notifications go to one place, and test a node failover while a rule is active |
| Alerts fail after a cluster upgrade | The data source query language or response shape changed with the new cluster version, or the Grafana plugin no longer matches the cluster | Test every alert query against a staging cluster on the target version, and align the Grafana and plugin versions before upgrading the search cluster |
| Logs panel shows no fields for ES|QL or PPL queries | The query language is not enabled for that data source or Grafana version, or the query uses syntax the cluster does not support | Check the supported query types for the data source version in the Grafana docs and run the same query in the cluster's own query console to isolate the fault |
Questions teams ask before connecting Grafana to OpenSearch or Elasticsearch
Can Grafana replace Kibana or OpenSearch Dashboards views?
For many log and metric views, yes, but it is a rebuild rather than an export. Grafana reads the same indices through the OpenSearch data source (Lucene or PPL) or the Elasticsearch data source (metrics, logs, raw DSL and ES|QL), so panels, time series and log views can be recreated in Grafana dashboards. What changes is the object model: Kibana saved searches, Discover workflows, Lens visualizations and Dashboards OpenSearch saved objects do not transfer automatically, and teams should inventory the views people use daily before deciding which ones to rebuild. Plan for retraining users on Grafana's explore and dashboard navigation, and confirm that each panel type you depend on is supported by the data source version you run. Kibana alerting rules and Dashboards OpenSearch features that have no Grafana equivalent need a separate decision.
Which query language should we choose for OpenSearch or Elasticsearch?
Choose the language that matches the data source and the queries your team already writes, then keep the rest consistent. The OpenSearch plugin offers Lucene and Piped Processing Language (PPL), and Lucene is the only option for traces. The Elasticsearch data source supports metrics queries, log queries, raw DSL and ES|QL. Lucene and DSL suit teams who already maintain saved queries, while PPL and ES|QL fit analysts who prefer pipeline-style searches. Check whether each language supports the alerting, annotation and log features your dashboards need, because support differs by language. Document the choice per dashboard so engineers do not have to guess which syntax a panel uses.
Does OpenSearch or Elasticsearch licensing affect the choice?
Yes, licensing is a real governance input, and it should be checked against your own legal review. OpenSearch software is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition. Elasticsearch and Kibana are available under three licenses: Elastic License 2.0 (the default distribution), SSPL 1.0 and AGPLv3, which Elastic added in September 2024 before the 8.16 release. Elastic states that ELv2 and SSPL are not OSI-approved open source licenses. Elastic also places several security features, including single sign-on, field- and document-level security and anomaly detection alerting, in paid subscription tiers. Confirm with your procurement and legal teams which features your deployment needs and which subscription tier, if any, covers them. Grafana's own licensing is separate and is governed by its AGPLv3 terms.
What drives the effort for an OpenSearch or Elasticsearch integration?
Four factors drive most of the effort: index count, query complexity, security model and high availability. A small number of indices with a few shared dashboards is a short build. Many indices, index patterns across tenants, and dashboards that depend on joins or heavy aggregations take longer to map and tune. The security model adds work when you need per-team access, field masking or document-level restrictions, because Grafana permissions and the search cluster's roles have to agree. High availability adds work to both Grafana (two or more active-active servers behind a load balancer sharing MySQL or PostgreSQL) and the search cluster, which needs the node topology your vendor documents. Ask any partner for a written scope that lists these counts so the quote follows from them.
What does the work need from our internal team?
The work needs named people who know the data, the access model and the operating environment. Expect to provide a cluster owner who can grant read-only API users and confirm the supported versions, a data owner who can explain fields, timestamps and retention, and a security contact who approves roles and network paths. Your platform team should supply the Grafana host or Kubernetes namespace, database backing for production, secrets handling and TLS certificates. Someone must also own the dashboards after handover, which includes reviewing alert rules and retiring old Kibana or OpenSearch Dashboards views. Agree these responsibilities in the written scope so review cycles are not left to chance.
Can an internal team connect Grafana to OpenSearch or Elasticsearch without outside help?
A team with Grafana, search cluster and identity skills can do it internally, and many do. The work is easiest to keep in-house when the index count is small, the queries are already written, and one team owns both the search cluster and Grafana. Outside help tends to pay off when you need a security review of roles and network paths, a migration of many Kibana or OpenSearch Dashboards views, or alerting rules that must be tested before they page people. Whatever you choose, check that the people involved have time for the build and the handover, and ask any partner for a fixed scope before work starts. DeployOpen plans and implements these integrations in infrastructure you control, and ongoing support is available as a retainer.
Which versions must we run before connecting Grafana?
Start with the minimums documented for each data source and confirm your cluster is inside a maintained line. The OpenSearch plugin requires Grafana 10.4.0 or later. The Elasticsearch data source requires Elasticsearch 7.17 or later, 8.x or 9.x. On the OpenSearch side, versions stay in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and version 1 reached end of life on May 6, 2025. For Elastic, the EOL page lists end of maintenance for 8.x on January 15, 2027 and for the 9.x core stack on October 15, 2027. Check the current lifecycle pages before you commit, because dates move and your upgrade plan should follow the vendor's published schedule.
Should we alert on search queries from Grafana or keep Kibana alerts?
Move alerts only after you confirm the query returns the same result set in Grafana, because a changed query can silence a rule without any error. Both data sources support alerting, so you can run rules from Grafana Alerting against search results. Test each rule against historical data, confirm notification routing, and decide who receives pages before the old rule is disabled. Run both systems in parallel for a set period you agree with your operations team, and record each switchover in your change log. Keep one owner for every rule so that a later change in an index mapping does not break an alert without anyone noticing.
Which OpenSearch or Elasticsearch release line to plan around
Choose the backend release line before you choose the Grafana plugin, because the version rules differ by engine. The Grafana OpenSearch plugin requires Grafana 10.4.0 or later and queries OpenSearch and Amazon OpenSearch Service. The Grafana Elasticsearch data source requires Elasticsearch 7.17 or later, 8.x or 9.x. If your cluster is older than those floors, plan the cluster upgrade first. On the OpenSearch side, the project targets a new minor version about every eight weeks, with OpenSearch 3.8.0 released on August 4, 2026 and 3.9.0 on September 29, 2026. A version stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and maintenance releases get bug and security fixes but no new features. Version 1 reached end of life on May 6, 2025, and version 2 is maintained through the 4.0 GA release. Confirm the current end-of-maintenance dates on the OpenSearch releases page before you commit to a line.
On the Elasticsearch side, the current release lines are 9.5.5 and 9.4.8 (released October 6, 2026), with 8.19.23 still maintained. Elastic lists end of maintenance for the 8.x line on January 15, 2027, with 8.x support ending July 15, 2027, and for the 9.x core stack on October 15, 2027. Check the Elastic product end of life dates page for the line you pick, since those dates drive your upgrade calendar. Licensing also shapes the security design. Elastic's default distribution is under the Elastic License 2.0, which is not OSI-approved, and AGPLv3 was added in 2024 as an open source option. Under the Basic tier, TLS, native users and role-based access control are free, but single sign-on, LDAP and Active Directory authentication, and field- or document-level security sit in paid tiers. OpenSearch Security, under Apache 2.0, includes SAML, OpenID Connect, LDAP and document- and field-level security without a paid edition.
Before you approve a version, ask your Elastic or OpenSearch contact, or your own support channel, which security features your target line includes at your subscription level, and whether your identity provider needs a feature that Basic does not cover. Record the end-of-maintenance date next to the Grafana version you plan to run, and schedule the backend and Grafana upgrades so neither one falls out of support. Confirm the Grafana plugin's version floor for the release you choose in the Grafana Elasticsearch data source documentation as part of the same review.
How DeployOpen scopes and delivers this integration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Grafana connections to OpenSearch and Elasticsearch. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- We confirm which OpenSearch or Elasticsearch versions and editions run in your environment before choosing a plugin or data source.
- We map which indices, log streams and metrics teams need, and which Lucene, PPL, DSL or ES|QL queries replace existing Kibana or Dashboards views.
- We record the authentication, role and field-level access model Grafana must respect, and agree the scope and deliverables in writing.
How we build
- We install the Grafana data source plugin or use the built-in Elasticsearch data source, then configure it against your cluster with least-privilege read credentials.
- We build dashboards and alert rules on search queries, with query load and time ranges checked against your cluster's capacity.
- We test query results against the source system and verify alert firing and notification routing before dashboards go live.
How we hand over
- We deliver data source configuration, dashboards and alert rules as documented, reviewable definitions that your team can version and reproduce.
- We document supported versions, the query language chosen for each panel, credential handling and the steps for adding new indices.
- We walk your engineers through operating the integration and the Kibana or OpenSearch Dashboards views it replaces.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so version changes on either side are planned and tested.
- We track Grafana, plugin and cluster version lifecycles so a data source upgrade does not break a dashboard or alert.
- We confirm with your team which vendor and standards documents apply to your environment before each planned change.
