Reference · built on requestConnectorDatabases & warehouses

OpenSearch

Documents, aggregations, and SQL or PPL query results from OpenSearch clusters through their REST API.

Request accessPricing ↗

About

OpenSearch is a search and analytics engine governed by the OpenSearch Software Foundation. It keeps JSON documents in indices and answers requests over a REST API. The Search API takes Query DSL at /_search. The SQL plugin answers SQL at _plugins/_sql and PPL at _plugins/_ppl, and its _explain endpoint shows the DSL a query becomes. The Bulk API takes newline-delimited JSON at /_bulk. The Alerting plugin runs monitors on a schedule and fires triggers. The Security plugin authenticates every request.

Through Fibric, an operator runs the queries you write, in DSL, SQL, or PPL, over the indices you name and reads the hits, rows, and buckets that return. When a write is warranted, it proposes a bulk request or a new monitor for your approval, and the connector sends it once.

This is a reference listing. It documents what Fibric would read from OpenSearch and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Hits from Query DSL searches through GET or POST /{index}/_search, with from, size, and sort
  • Rows and a schema from SQL sent to POST /_plugins/_sql, returned in jdbc, csv, raw, or json format
  • Results of PPL pipelines sent to _plugins/_ppl in jdbc, csv, or raw format
  • Consistent pages read through a point in time created at /{index}/_search/point_in_time with a keep_alive
  • The Query DSL a SQL or PPL statement translates to, from the _explain endpoint
  • Monitors and their alerts through the Alerting API at _plugins/_alerting/monitors

Proposed actions

  • Target capability: propose index, create, update, or delete actions on documents in one NDJSON request to POST /_bulk
  • Target capability: propose a query-level monitor with a schedule, trigger condition, and action through POST _plugins/_alerting/monitors
  • Target capability: propose a conditional overwrite of a document using if_seq_no and if_primary_term in a bulk action

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Watch for a sensor stream that goes quiet

    Device readings land in a daily index. The operator runs a PPL stats query for the latest timestamp per device id and names the devices that have stopped reporting.

    With Data Freshness, Sensor Health

  • Quiet a monitor that flaps

    The operator reads alerts from the Alerting API, groups the ones that fire and clear within minutes, and proposes throttle settings or a wider trigger window. You approve, and the record shows the old and new condition.

    With Alert Noise

  • Trace a failure across log indices

    After an outage, the operator runs a SQL query over the log indices for the window, orders by timestamp, reads the first errors, and attaches them to the incident draft.

    With Root Cause, Uptime Response

Requirements

  • An OpenSearch cluster reachable on its REST port, with the Security plugin configured for at least one authentication backend
  • A user or role permitted to read the indices you name. Point in time reads have their own permissions
  • The SQL plugin for _plugins/_sql and _plugins/_ppl, and the Alerting plugin for monitors
  • For writes, a role with write permission on the target indices and, for monitors, the backend roles the Alerting plugin checks
Authentication
Credentials for the Security plugin: HTTP basic authentication against the internal user database, a JSON Web Token, a client certificate, or an OpenID Connect, SAML, LDAP, proxy, or Kerberos backend you configure.

Limits

  • from and size stop at 10,000 results. Larger reads use scroll, search_after, or a point in time
  • SQL pagination with fetch_size works for basic queries in jdbc format only. Queries with aggregation or JOIN do not paginate
  • SQL JOIN runs on a best-effort basis, cannot aggregate the joined result, and stops after 60 seconds unless a hint extends it
  • Bulk document _id values must be 512 bytes or less, and each action in a bulk request succeeds or fails on its own

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request OpenSearch ↗

Questions and answers

Can the connector query OpenSearch with SQL?
Yes, when the SQL plugin is installed. POST a query to _plugins/_sql and pick jdbc, csv, raw, or json with the format parameter. jdbc is the default. PPL goes to _plugins/_ppl. Both endpoints have an _explain variant that returns the equivalent Query DSL.
How are documents written in batches?
Through the Bulk API at POST /_bulk or /{index}/_bulk. The body is newline-delimited JSON: an action line, then a source line for index, create, or update. OpenSearch processes each action on its own and reports per-action success or failure in the response.
How does OpenSearch authenticate requests?
The Security plugin authenticates through the backends you enable: HTTP basic against the internal user database, JSON Web Token, OpenID Connect, SAML, Active Directory and LDAP, proxy headers, client certificates, or Kerberos. Basic authentication with challenge set to true returns 401 when the Authorization header is missing.
Ask about OpenSearch

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with OpenSearch through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy