Splunk® Enterprise

Distributed Search

Quarantine a search peer

You can quarantine a search peer to prevent it from partaking in future searches. This is of value if the peer is experiencing problems, for example, due to a bad disk or network card. It can also be useful to quarantine a search peer while you upgrade it.

By quarantining, instead of stopping, a bad search peer, you can perform live troubleshooting on the peer.

You can override a quarantine for a specific search, if necessary. See How to override a quarantine.

What happens when you quarantine a search peer

The quarantine operation affects only the relationship between a search head and a search peer. You quarantine the search peer from the search head.

When you quarantine a search peer, the search head stops sending search requests to the search peer. This action prevents the search peer from taking part in new searches. The search peer, however, continues to service any currently running searches. The search peer also continues to receive and index incoming data in its role as an indexer.

If you need to fully halt the activities of the indexer, you must bring it down.

If the search peer is a member of an indexer cluster, it continues to replicate data from other peer nodes, in addition to continuing to index incoming data. The cluster takes no action to compensate for the loss of search capability on the search peer. If you need the cluster to maintain search capability across all buckets, you can take the peer offline temporarily instead of quarantining it. When you take a peer ofline, the cluster reassigns primary bucket copies to other peers. See Take a peer offline in the Managing Indexers and Clusters of Indexers manual.

How to quarantine a search peer

To quarantine a search peer, run this CLI command from the search head:

splunk edit search-server -auth <user>:<password> <host>:<port> -action quarantine

Note the following:

  • Use the -auth flag to provide credentials for the search head only.
  • <host> is the host name or IP address of the search peer's host machine.
  • <port> is the management port of the search peer.

For example:

splunk edit search-server -auth admin:password 10.10.10.10:8089 -action quarantine

In a search head cluster, this command affects only the search head that it is run on. To quarantine a peer for all cluster members, you must run this command on each member.

You can also quarantine a search peer through the Search peers page on the search head's Splunk Web. See View search peer status in Settings.

How to unquarantine a search peer

To remove a search peer from quarantine, run this command from the search head:

splunk edit search-server  -auth <user>:<password> <host>:<port> -action unquarantine

Note the following:

  • Use the -auth flag to provide credentials for the search head only.
  • <host> is the host name or IP address of the search peer's host machine.
  • <port> is the management port of the search peer.

For example:

splunk edit search-server -auth admin:password 10.10.10.10:8089 -action unquarantine

How to override a quarantine

When a peer is quarantined, it does not ordinarily participate in searches. You can, however, override the quarantine on a search-by-search basis. To do so, the search must target the peer directly with the splunk_server field. For example:

index=_internal splunk_server=idx-tk421-03 (log_level=WARN OR log_level=ERROR)

Note: If the peer is a member of a distributed search group, you cannot override the quarantine by specifying the splunk_server_group field of its search group. You must specify the peer directly with the splunk_server field.

Last modified on 23 February, 2021
Handle slow search peers   Distributed search error messages

This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.1.11, 8.1.12, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2, 9.4.0


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters