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:
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.|
|Field definitions||Adding fields during data-pattern creation can make search more effective.|
|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.|
The following factors can impact your search performance:
|Broad search scopes|
It is recommended that you use:
|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.
Keep the following points in mind when you add field definitions and subsequently use them for search:
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
For more information, see Managing data patterns.
|Field case||When adding field definitions in your data pattern, remember that field names are case sensitive.|
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.
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.
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.
While deploying multiple Search components in your environment, ensure that all the Search components are operating in the same time zone. Doing this is important for scheduling notifications correctly.