Search best practices

Before using the product for searching data, you need to factor all the search requirements that might affect your data collection strategy.

This topic contains the following information that you can use as search best practices:

Related topics

Where to find more information

Data collection best practices

Search tab

Search commands

Troubleshooting performance issues

Planning your data collector configurations

Searching can be easier and more effective if you think ahead and factor your search requirements into your data-collection configuration strategy. You can start by making decisions about the factors listed in the following table when doing planning your data-collector configuration:

Item	Best practice	Additional information links
Tags	Setting tags properly enables you to filter or isolate search intuitively.	Understanding fields and tags Search tab Managing data collectors
Field definitions	Adding fields during data-pattern creation can make search more effective.	Understanding fields and tags Managing data patterns
Naming conventions for data collectors	Appropriate and consistent naming of data collectors can help when you search for the data collectors and for the data from them.	Managing data collectors Search tab

Search performance

The following factors can impact your search performance:

Item

Best practice

Broad search scopes

It is recommended that you use:

Specific keywords for searching rather than a wildcard character (*) piped by search commands:
Using specific key words helps you reduce data that is irrelevant and search results contain data appearing from multiple systems. BMC recommends you to search for specific data sources, data pattern types, data collectors, application tags, and specific errors instead of searching for the wildcard asterisk (*).
Large time-range searches at the beginning of a multilevel search command:
Narrowing down on specific time and then using search commands enables faster product performance (for example, last 6 hours, 24 hours, 2 days rather than 15 days period). Certain search commands such as filter and group process each entry in the search results. Therefore reducing the time duration helps in getting faster results for these commands.

Adding too many fields

Fields are extremely useful but have a cost; therefore, it is recommended that you not add too many fields to the Fields section, available under the Filters panel on the search page.

Adding too many fields can cost a fair amount of CPU, memory, and disk I/O overhead.

Number of concurrent searches

If a large number of users are executing concurrent searches or loading dashboards, or if there are too many notifications set up for execution, you might find that your system has become too slow. For more information, see Variables that impact product performance.

If you execute a search string processing a large amount of search results and while it still processing the results, if you found what you were looking for, you can pause or stop the search from executing further results.

Using fields

Keep the following points in mind when you add field definitions and subsequently use them for search:

Item Description

Field type

Assigning an appropriate field type (such as string, integer) is important when defining fields during data-pattern creation.

To enable you to use the sum or average function while executing the stats search command, the field type must be saved as INTEGER.

For more information, see Managing data patterns.

Field case When adding field definitions in your data pattern, remember that field names are case sensitive.

Creating complex search commands

When you are building a complex search command by chaining search commands (for example, error | filter greaterthan(price,"10") | timechart span=1d count(HOST)), follow these recommendations. This is necessary because the time slicing happens after all the search results are processed. This hampers the Search component capabilities and the results appear slowly.

Use existing examples of search syntax as a starting point.

When constructing multilevel search commands, build the search incrementally, and validate one level at a time.
After you have validated the results of a search command and you are satisfied with it, save the query to create a saved search. Saving a search ensure that the same search query can be reused and leveraged by others.

Using specific time ranges for search

Search results will be much more relevant if you try to focus on the time range during which the error occurred. For example, searching a specific 15-minute time range can yield more meaningful results than searching the last 24 hours.

It is recommended that you narrow your search by providing a more specific time range.

Backing up your saved searches

It is recommended that you save important search queries to create saved searches. BMC recommends that you periodically export all of your saved searches via a content pack. Doing so ensures that you have a backup of your important search queries outside of the system.

Page tree