Searching in LogDNA is designed to be as easy and straightforward as possible. Just type in your search terms, and LogDNA will return your results almost instantaneously. For cases where you need to perform a more advanced search, or where you need greater control over your search results, LogDNA provides a number of features that can help you find exactly what you’re looking for.
In this article, we’ll walk through some of the expert-level features of LogDNA’s search engine and how you can use them to perform in-depth searches. We’ll start by explaining the basics of how LogDNA interprets searches, then we’ll present frequently asked questions about how searching works.
When you enter a query into the search input box, LogDNA parses it into a series of terms and operators.
A term is a string consisting of a single word, or a phrase surrounded by quotes. LogDNA scans each log to see if it contains your term(s), and if so, displays the log. Terms are searched against the entire log, but can be searched on a particular field if one is specified. By default, terms are also case insensitive and treated as prefixes. For example, search
lin will return logs containing
Operators change how LogDNA interprets one or more search terms. Using operators gives you greater control over the search process in order to provide more relevant results. You can find a full list of operators with examples in the LogDNA search documentation page.
LogDNA also supports the boolean operators
NOT. Any whitespace between search terms is automatically interpreted as
AND. For example, searching
warning error returns logs containing both
error. The only exception is when using lists, which treat whitespace as a part of the search term. For example, searching
message:[file, exists] will only search for instances of
exists that are preceded by a space.
Lastly, you can use parentheses to group operations that should be evaluated first. For example, the query
source:node1 AND (file:/var/log/syslog OR ERROR) searches first for logs scanned from
/var/log/syslog or that contain the word
ERROR, then limits the results to
node1. You can also use parentheses to group operations on a single field. For example, the query
status:(>100 AND <= 503) returns logs where the value stored in the
status field is greater than 100 and less than 503.
You may find that one of your queries doesn’t return the results you expected, or displays a warning or error message. Here are some common pitfalls you may run into, and how to resolve them.
The most common problem with developing queries is not getting the results you expect. This is commonly due to search queries that are too vague, or queries that return a significant number of matches. LogDNA searches work best when they are specific. For example, searching for
the or another common word would result in an excessive number of results, and not all of them will be displayed. For this reason, LogDNA doesn’t support single-character searches.
To avoid this problem, try using the exact match operator (
:==) instead of the prefix match operator (
:). You should also search on a specific field, instead of the entire log. Lastly, if you know exactly how your search term appears in your logs, enable case sensitivity by using the
After running a search, you may see results that don’t appear to match your query. LogDNA doesn’t just search visible fields, but also internal fields. These fields aren’t visible in the LogDNA web UI, but contain additional information such as metadata and the raw log message. Your query could match on these “invisible” fields, resulting in the log appearing in the results.
You can override this by specifying the field to search. For example, if your logs contain a
level field and you want to find error-level logs, enter
level:error as your query instead of just
If your query contains whitespace and doesn’t contain quotes, LogDNA treats the whitespace as an
AND operator. For example, the query
file does not exist will return any log containing all four words, regardless of their order. It could match
file "myfile.txt" does not exist, but it could also match
Could not open file: does it exist? To search for the exact phrase, surround it in double quotes.
The only exception is when searching in lists. With lists, whitespace is treated as part of the list item that it’s next to. For example,
message:[file, exists] searches for logs where
exists is preceded by a space. To avoid this, remove any whitespace between list items.
LogDNA provides visual feedback based on whether your query is properly formatted. A properly formatted field search will appear highlighted, as shown in this screenshot:
Well-formatted non-field searches won’t appear highlighted, but will still run without problems. However, if your query is improperly formatted or contains errors, the help icon on the right-hand side of the search box will turn into an alert explaining the problem in detail. In this screenshot, we’re trying to use a comparison operator on a string field, which is invalid:
A common issue is using symbols in your query, such as inequality signs. This displays the warning “Unsupported visualization query: symbols.” This warning is only relevant when using graphs or the timeline feature, but it doesn’t affect normal queries. The following example will still return results containing
If the warning persists, or if you’re not getting the expected results, you can escape the problematic characters by adding a backslash “\” before them. For example, the following query searches for a specific phrase containing quotes:
message:"Host "logdna-host" not found"
This search is valid, but won’t return the expected results. Instead, you would use:
message:"Host \"logdna-host\" not found"
You can learn more in the LogDNA search documentation.
LogDNA’s search engine allows for a great deal of flexibility and control. It’s important to be aware of how LogDNA interprets each part of your query, especially for complex searches. Fortunately LogDNA offers some of the fastest search results in the industry, so if at first you don’t succeed, you can try again right away!
Updated over 1 year ago