multisearch

The multisearch command runs multiple subsearches and merges their results. It allows you to combine data from different queries on the same or different sources. You can optionally apply subsequent processing, such as aggregation or sorting, to the combined results. Each subsearch can have different filtering criteria, data transformations, and field selections.

Multisearch is particularly useful for comparative analysis, union operations, and creating comprehensive datasets from multiple search criteria. The command supports timestamp-based result interleaving when working with time-series data.

Use multisearch for:

• Comparative analysis: Compare metrics across different segments, regions, or time periods.
• Success rate monitoring: Calculate success rates by comparing successful to total operations.
• Multi-source data combination: Merge data from different indexes or apply different filters to the same source.
• A/B testing analysis: Combine results from different test groups for comparison.
• Time-series data merging: Interleave events from multiple sources based on timestamps.

Syntax

The multisearch command has the following syntax:

multisearch <subsearch1> <subsearch2> [<subsearch3> ...]

The following are examples of the multisearch command syntax:

| multisearch [search source=table | where condition1] [search source=table | where condition2]
| multisearch [search source=index1 | fields field1, field2] [search source=index2 | fields field1, field2]
| multisearch [search source=table | where status="success"] [search source=table | where status="error"]

Parameters

The multisearch command supports the following parameters.

Example 1: Comparing errors with debug logs

This example merges error logs with debug logs side by side. This is useful when investigating whether debug-level logs from the same services provide clues about the root cause of errors:

| multisearch [search source=otellogs
| where severityText = 'ERROR'
| eval env = 'errors'
| fields env, `resource.attributes.service.name`, body] [search source=otellogs
| where severityText = 'DEBUG'
| eval env = 'debug'
| fields env, `resource.attributes.service.name`, body]
| sort env, `resource.attributes.service.name`

The query returns the following results:

Example 2: Segmenting logs by severity tier

This example separates critical and non-critical logs for comparative analysis:

| multisearch [search source=otellogs
| where severityNumber >= 17
| eval tier = "critical"
| fields severityText, severityNumber, tier] [search source=otellogs
| where severityNumber < 17 AND severityNumber >= 13
| eval tier = "warning"
| fields severityText, severityNumber, tier]
| sort - severityNumber

The query returns the following results:

Example 3: Merging time-series data from multiple sources

This example demonstrates how to combine time-series data from different sources while maintaining chronological order. The results are automatically sorted by timestamp to create a unified timeline:

| multisearch [search source=time_data
| where category IN ("A", "B")] [search source=time_data2
| where category IN ("E", "F")]
| fields @timestamp, category, value, timestamp
| head 5

The query returns the following results:

Example 4: Handling missing fields across subsearches

This example demonstrates how multisearch handles schema differences when subsearches return different fields. When one subsearch includes a field that others don’t have, missing values are automatically filled with null values:

| multisearch [search source=otellogs
| where severityText = 'ERROR'
| eval needs_page = "yes"
| fields severityText, `resource.attributes.service.name`, needs_page] [search source=otellogs
| where severityText = 'WARN'
| fields severityText, `resource.attributes.service.name`]
| sort `resource.attributes.service.name`
| head 5

The query returns the following results:

Limitations

The multisearch command has the following limitations:

• At least two subsearches must be specified.
• When fields with the same name exist across subsearches but have incompatible types, the system automatically resolves conflicts by renaming the conflicting fields. The first occurrence retains the original name, while subsequent conflicting fields are renamed using a numeric suffix (for example, age becomes age0, age1, and so on). This ensures that all data is preserved while maintaining schema consistency.