Splunk is said to be the Google of machine data. So, searching is the most important set of actions that is performed to retrieve the exact information the user is looking for from the indexes. You will now learn how to make efficient use of search commands to fetch the relevant and required information precisely from the whole set of data.
The search
command is used to search events and filter the result from the indexes. The search
command, followed by keywords, phrases, regular expressions, wildcards, and key-value pairs, can be used to fetch filtered events from the indexes.
Mentioned as follows is the syntax for a search
command instance:
<keywords> <wildcards> <key_value_pairs> or <fields> <phrases> <operators> <logical_expressions> <regular_expressions> <time_specifiers>
The parameter description for the preceding parameters is as follows:
keywords
: A keyword can be any string or strings that are to be searched in the data. Depending on the data and the requirement, the keywords can be anything. If the data in the Splunk index is of a website login transaction, then the keywords can be Login
, failed
, authenticated
, error
, and so on.wildcards
: If the user wants to find the information of all the users whose IP address starts with 192.168, then the 192.168.*
wildcard can be used.key_value_pairs
/ fields
: Key-value pairs are fields that are either automatically extracted by Splunk or user extracted. Key-value pairs can be server="America"
, android_version=5.1
, and so on, depending on the data and the requirement.phrases
: The search
command can be followed by phrases to be searched in indexes. Phrases are nothing but a set of keywords, and they are to be specified in quotes ("
) after the search
commands, such as login failed
, request timeout
, and incorrect password
.operators
: Operators such as OR
and AND
can be used to filter the search resultslogical_expression
: Splunk accepts the usage of logical expressions such as <
, >
, <=
, >=
, =
, and !=
.regular_expression
: The search
command can be specified with a regular expression to search in the data, and the events with the specified regular expression will be returned in the search results.time_specifiers
: Time range can be specified in the search
command to restrict the search to the said time range only. Only those events that fall in the given time range will be displayed in the search result. Time can be specified using parameters such as starttime
, endtime
, earliest
, and latest
. Time format can also be specified using the timeformat
parameter.The following are examples of a search
operation with two different scenarios:
index=web_server error 404 index=web_server IP=192.168.* AND IP=10.20.* | search "login failed" OR "incorrect password"
In the first example, all the events that have an error and 404
will be shown in the search result. Here, we have used the keyword (error
and 404
) to be searched in the index. In the second example, the query will result in all the events that have IP (192.168.*
and 10.20.*
). We have used the AND
Boolean operator along with wildcard (*
) for the IP address to filter the required result. In the later section of the second example, after pipe (|
) phrases in quotes (login failed
and incorrect password
) are used along with the Boolean operator OR
to get all the events that have either failed to log in or used an incorrect password.
The sendmail
command is used to send the search result over e-mail. The search results can be sent inline in the e-mail or as a PDF attachment. This command can be used in the scripts or while scheduling reports to run search queries with the specified filters and keywords. Then, the results are to be e-mailed to the specified recipient(s).
The syntax for the sendemail
command is as follows:
sendemail to=<email_id(s)> from=<email_id(s)> cc=<email_id(s)> bcc=<email_id(s)> subject=<enter_subject_for_email> format=csv/ raw / table inline= true/false sendpdf=true/false server=<email_server>
The parameter description of the sendemail
command is as follows:
email_id(s)
: List of e-mail ID(s) can be specified for the to
, from
, cc
, and bcc
parameters.subject
: Subject of the e-mail can be specified, for example, hourly report of login failures, daily report of errors occurred, and so on.format
: This parameter is used to specify how the report is to be formatted for inline e-mails. It specifies whether the result is to be displayed in a CSV, table, or in raw format in the inline e-mail.inline
: If set to true
, then the results are sent inline in the e-mail.sendpdf
: If set to true
, then the results are sent as a PDF attachment in the e-mail.server
: The SMTP server address through which the e-mail is to be sent. If the SMTP server is configured on the same host, there is no need to specify the server, as the local host is set as the default SMTP server.Refer to the following example for a better understanding:
index=_internal error | head 10 | [email protected] [email protected] subject="Top 10 errors of this hour" sendpdf=true inline=true format=raw
The preceding search query will send an e-mail to <[email protected]>
, which will be Cced to <[email protected]>
with the subject Top 10 errors of this hour
having a PDF attachment (sendpdf=true
). The PDF will contain the top 10 errors of the _internal
index events in the raw (format=raw
) format, and this information will also be available inline (inline=true
) in the e-mail.
Splunk is generally deployed in a distributed architecture, and it can have many indexers and search heads in a real deployment environment. Whenever a search is run on a search head, the results are fetched from all the indexers of the distributed architecture. If the user wants to run the search on only local indexers and does not require data from all the other remote indexes, then the localop
command can be used.
The syntax for the localop
command is as follows:
|localop
Refer to the following example for better lucidity:
Index=web_server error |localop | userIP
The preceding search
query will return userIP
only from the local indexer and error from the local as well as remote indexers of Index=web_server
.
3.141.193.158