Searching Peers (Distributed Search)

When you run a search query, by default, only your local Logger is searched for matching events. However, you can specify in your query to run the search on the peer Loggers

Prerequisites

To perform peer searches and view their search results, you need the following groups and permissions:

Logger Search Group with “Search for events on remote peers” enabled.
Logger Rights Group with the “View registered peers” enabled.

Follow these guidelines for searching across peers:

Specify the peer Loggers to search, as described in Constraints.
Logger supports searching up to 100 peers in the same search.
For best search performance and functionality, all peers must be on the latest version of Logger. Searches across peers are limited by the ability of the earliest version peer.
- If an operator does not exist on a peer version, the query will not run on that peer.
- Peers on earlier version will have the performance of that version, so search result for those peers will be returned more slowly.
For best performance of non-pipeline searches, do not include the regex, rex, parse, keys, transaction, extract, or lookup search operators in the query.
If the peer Loggers do not have the same storage or device group names, a search query operation skips searching for events for those groups on those peers.
If there are custom schema fields in your Logger schema, those fields must exist on all peers. A search query containing those fields will not run across peers, and will return an error. See Adding Fields to the Schema.
When a Logger becomes unavailable during a search operation, error messages are displayed. The displayed message varies depending on the error detected. This is most likely because there is a problem with the network or the peer is down. In some cases it may be because there is an issue with the peering relationship. The error messages may still display for the search that was in progress even after the problem is fixed. However, you can ignore such messages if they go away when you run a new distributed search. For more information about peers, see Peer Nodes.
Using search heads enables faster peer searches for searches that use search operators, particularly aggregation operators, such as chart, sort, top. For best search performance, specify all peers to be searched in the query and exclude the local Logger. See Setting up Search Heads for Faster Peer Searches.

Note: Peer search speed improvements gained by using search heads apply only to searches run through the user interface. Using search heads does not improve the speed of scheduled searches or searches run though Logger Web Services.

Example queries for searching across peers:

Search that sorts five fields:

_peerLogger IN [“peer1”, “peer2”, …] | sort deviceEventCategory eventId deviceCustomNumber1 deviceCustomNumber2 deviceCustomNumber3

Search with field extraction:

_peerLogger IN [“peer1”, “peer2”, …] | rex "(?<src_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})"

Search evaluating a variable:

_peerLogger IN [“peer1”, “peer2”, …] | eval (int)urllength=len(requestUrl) |sort urllength

Search with results grouped and counted as a top 50 list:

_peerLogger IN [“peer1”, “peer2”, …] | and priority > 0 | top 50 name

Search for events with a long URL:

_peerLogger IN [“peer1”, “peer2”, …] | eval n=len(requestUrl) | where n = "1023"