OpenSearch - incident.io

OpenSearch stores and searches your logs. Investigations query the index patterns you point them at to read what your services recorded around the time of an incident: the errors, the warnings, the request that failed.

You connect OpenSearch directly, with your cluster’s endpoint and credentials. It works the same whether you run OpenSearch yourself or use a managed OpenSearch service.

What we support

Investigations query OpenSearch with its Query DSL against the log index patterns you configure, in two ways:

Log searches: pull back the actual documents, whether that’s what a service logged at the time, whether errors appeared on an endpoint, or whether a message started showing up right after a deploy.
Aggregations over logs: turn matching documents into a time series, so investigations can graph trends straight from your logs, such as an error count climbing, request volume dropping away, or the frequency of a particular message across the incident window. You get a chart of what your logs were doing even where you never set up a dedicated metric for it.

Querying your index patterns

OpenSearch doesn’t expose one set of logs. It holds whatever indices and data streams you ship to it, and the useful ones differ by team. So you tell investigations which index patterns to query, for example logs-* for application logs or a security audit stream, and each pattern becomes its own queryable source you can enable or disable independently. Until you configure at least one index pattern, an OpenSearch connection has nothing to query. Add your patterns during setup, then enable the ones your responders reach for.

Learning your fields and mappings

A log document in OpenSearch can carry hundreds of fields, and a query is only as good as knowing which ones exist and what they hold. For each index pattern, investigations read its mapping to learn the fields and their types, then sample recent documents to learn which fields are actually populated, how many distinct values each holds, and the common values for the ones worth filtering on, such as a status code, a service name, or a customer. They also learn the timestamp field your index uses and how long it retains data, so queries scope to the incident window and don’t reach past what’s still there. This means investigations can filter on the fields that matter in your logs without you describing your schema by hand. How that learning works is covered in How telemetry works.

Connecting OpenSearch

Connect OpenSearch from the Investigations settings by adding a telemetry data source and choosing OpenSearch. What you’ll need:

Your cluster’s endpoint. One or more node addresses as full URLs, for example https://your-host:9200.
Credentials. A username and password.
A CA certificate (optional). Provide one if your cluster uses a self-signed or internal certificate authority.

To connect:

Enter one or more node addresses for your cluster.
Add your username and password, and a CA certificate if your cluster needs one.
Add the index patterns you want investigations to query, then test the connection.

Choose the OpenSearch connection type for an OpenSearch cluster. If you point it at an Elasticsearch cluster, the connection test tells you to use the Elasticsearch type instead.

The credentials only need read access. Grant the cluster_monitor cluster permission, and read plus indices:admin/validate/query on the index patterns you connect:

{
  "incident_io_role": {
    "cluster_permissions": ["cluster_monitor"],
    "index_permissions": [
      {
        "index_patterns": ["logs-*"],
        "allowed_actions": ["read", "indices:admin/validate/query"]
      }
    ]
  }
}

Each index pattern you add becomes its own data source. Enable the patterns your responders use during incidents.

Best practice

Connect the index patterns your team actually searches during incidents, rather than every index in the cluster. Each one is enabled independently, so keep the noisy or rarely-used ones off.
Scope index_patterns in your role to the patterns you’re connecting, so the credentials only read the indices you intend.
Use a dedicated read-only user. Investigations only ever read from OpenSearch.

Telemetry overview

How providers and data sources fit together.

How telemetry works

How investigations query your logs.

​What we support

​Querying your index patterns

​Learning your fields and mappings

​Connecting OpenSearch

​Best practice

​Related

Telemetry overview

How telemetry works

What we support

Querying your index patterns

Learning your fields and mappings

Connecting OpenSearch

Best practice

Related