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: Combining age groups for demographic analysis

This example demonstrates how to merge customers from different age segments into a unified dataset. It combines young and adult customers into a single result set and adds categorization labels for further analysis:

| multisearch [search source=accounts
| where age < 30
| eval age_group = "young"
| fields firstname, age, age_group] [search source=accounts
| where age >= 30
| eval age_group = "adult"
| fields firstname, age, age_group]
| sort age

The query returns the following results:

Example 2: Segmenting accounts by balance tier

This example demonstrates how to create account segments based on balance thresholds for comparative analysis. It separates high_balance accounts from regular accounts and labels them for easy comparison:

| multisearch [search source=accounts
| where balance > 20000
| eval query_type = "high_balance"
| fields firstname, balance, query_type] [search source=accounts
| where balance > 0 AND balance <= 20000
| eval query_type = "regular"
| fields firstname, balance, query_type]
| sort balance desc

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=accounts
| where age < 30
| eval young_flag = "yes"
| fields firstname, age, young_flag] [search source=accounts
| where age >= 30
| fields firstname, age]
| sort age

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.