When do breaker characters apply?

[mv10]

I have read the documentation about breaker characters, but within our organization there is disagreement about when they actually come into play in the main search.

The docs don't say anything about it either way, but some say we must use quotes around sourcetype, for example:

index=iis sourcetype="http_err_logs" status=500 ...etc

It goes without saying that they're needed within literal search phrases; the text of a specific error message, for example. But do they really also apply to comparisons for standard fields like index or sourcetype?

As another example, we have sourcetypes with names like "WinEventLog:Application" and "WinEventLog:System" and some are saying that colon becomes a breaker which leads to a search of the entire raw event data. We also have index names with underscores, and so on.

As a result, at this point we're playing it safe and quoting anything that has breaker characters, but is there any documentation that describes where they're actually applied or not?

[richgalloway]

I use index=_internal all the time with no indication that Splunk is searching anything else.

One way to see who is right would be to compare the litsearch for each query as shown in Job Inspector.

This document may help: https://docs.splunk.com/Documentation/Splunk/latest/Search/Eventsegmentationandsearching

[mv10]

Good idea about the job inspector, I'll have to play with it a bit.

Those are the docs I was referring to in my question. It defines major and minor breakers but never clearly explains exactly when one or the other applies. It has the "app=" example and shows the minor tokens in the table but the text doesn't mention them at all.

I wouldn't expect _internal to match against anything else unless you also had other indices with names using the word "internal" with other breakers ("accounting_internal" for example). Personally I strongly doubt "index" would ever use breakers (makes no sense), but the rest of the fields, I'm not so sure.

My sourcetype examples (such as WinEventLog:System) do seem to work as expected even without quotes, the thinking is that it's just an efficiency thing. That's one I could test, but where does it end? Extracted fields? Only free-form search text?

[yuanliu]

This is the defining document: search; I would pay special attention under Logical expression options, Comparison expression options, Quotes and escaping characters, and The implied search command.  In addition to white space and double quotation mark (") which are obvious, any unquoted occurrence of parentheses ("(" and ")", unquoted), equal (=), less-than (<), and greater-than (>) will be interpreted by SPL as part (or whole) of an operator; any unquoted occurrence of pipe (|) is interpreted as command separator; select unquoted backslash sequences are interpreted by SPL, e.g., \", \|, and \\; unquoted asterisk (*) is interpreted as wildcard.   Also look at Subsearches.  Any unquoted occurrence of left square bracket ([) is interpreted as the beginning of a subsearch; unquoted right square bracket (]) is considered the ending of a subsearch.

Other than these, any character in a string is considered a literal string.  This is why index=WinEventLog:System, or even index = WinEventLog:System is equivalent to index="WinEventLog:System".  Yes, you can even name your source WinEventLog!System, WinEventLog/System, WinEventLog\System, WinEventLog\/System, even WinEventLog@System or WinEventLog&System and not quote it.

Even in the search document itself, some examples include unquoted strings that could be unsafe in some other contexts.  For example,

The AND operator is always implied between terms and expressions. For example, web error is the same as web AND error. Specifying clientip=192.0.2.255 earliest=-1h@h is the same as clientip=192.0.2.255 AND earliest=-1h@h. So unless you want to include it for clarity reasons, you do not need to specify the AND operator. - Required arguments