This guide covers how to use the Search input box located at the bottom of the page in the LogDNA web app.

Before we begin, keep in mind that searches are performed in conjunction with filters and time queries. Any specified timeframes, sources, apps, and log levels are respected in addition to the search query itself.

Simple search

The simplest type of search is a single term string search.

Include

To perform a simple include search, just type the word you want to see in your results.

healthcheck

This will return all log lines with the word healthcheck in them.

Exclude (NOT)

To perform a simple exclude search, prepend a dash to exclude results with that word.

-healthcheck

This will return all log lines that do not contain the word healthcheck.

Compound search

Multiple search terms and operators can help you quickly find a specific set of log lines. Please note that the AND and OR operators are case sensitive and must be entirely capitalized.

AND operator

By default, multiple search terms are AND'd together.

healthcheck -successful

This will return all log lines that contain the word healthcheck and not the word successful

OR operator

Specifying the OR operator will return results with either term.

healthcheck OR ping

This will return all log lines that contain the word healthcheck or contain the word ping.

Chained operators

By default, adjacent terms are AND'd together first.

healthcheck -successful OR ping

This will return all log lines with the word healthcheck and not the word successful, as well as all log lines with the word ping in it.

Parentheses

To explicitly specify operator order for your search terms, use parentheses.

healthcheck (-successful OR ping)

This will return all log lines with the word healthcheck and without the word successful, as well as all log lines with the word healthcheck and with the word ping.

Field search

For parsed log lines, you can specify a value for a given field in that log line.

Parsing

When a log line is parsed, you can search directly for a specific field value. We currently automatically parse the following types of log lines:

• Apache/Nginx
• AWS ELB
• AWS S3
• Cron
• HAProxy
• Heroku
• JSON
• Logfmt
• MongoDB
• Nagios
• PostgreSQL
• Ruby/Rails
• Syslog
• Tomcat
• Windows Events

JSON Parsing

As long as the log message ends in a }, your JSON object will be parsed, even if the JSON object does not span the entire message. If do not want your JSON object to be parsed, you can simply append an additional character after the ending } such as . a period.

If your JSON contains a message field, that field will be used for display and search in the log viewer. We also parse out (and override any existing) log levels if you include a level field.

Root level field search

To search for a field with a particular value, use a colon to separate the field and value.

response:404

This will return all parsed log lines with the field response with a value of 404.

Nested field search

To search for a nested field, use periods to separate each nested field.

user.id:12345

This will return all log lines containing the following key value structure { "user": { "id": 12345 }}

Filters

With the same field search syntax, you can also set filters directly in the search bar.

host:myawesomehost -app:mycoolapp

This will return all log lines that originate from the source myawesomehost and not from the app mycoolapp.

Metadata

With the REST API or Node.JS library, you can upload a metadata object as part of a log line's context. To search for field values contained in the metadata object, use the meta prefix.

meta.status_code: 404

This will return all log lines containing the context object with the following key value structure { "status_code": 404}

Field comparison operators

We support the following comparison operators for numeric parsed fields:

• =
• <
• >
• <=
• >=

Field comparison search

To search for parsed fields matching comparison operators, use a colon followed by the comparison operator.

response:>=400

This will return all log lines with the field response with values greater than or equal to 400.

Compound field comparison search

To form a compound field search query using comparison operators, use a colon followed by parentheses.

response:(>=400 <500 -404)

This will return all log lines with the field response with values greater than or equal to 400, less than 500, and not 404.

Case-sensitive field search

To search for a case-sensitive parsed field, use a colon followed by the equal sign (=).

name:=camelCasedName

This will return all log lines with the field name with the case-sensitive string value camelCasedName.

Existence field search

To search for the existence of a parsed field, use a colon followed by the asterisk (*).

user:*

This will return all log lines with the field user.

Exact match field search

By default, we perform a prefix search for all string fields. To search for an exact match for a field value, use ==.

name:==bob

This will return all lines with the exact name field value of bob, and will not match bobby.

Exact match case-sensitive field search

By default, we perform a prefix search for all string fields. To search for an exact match for a field value, use ===.

name:===Bob

This will return all lines with the exact name field value of Bob, and will not match bob or Bobby.

Special characters

There are a few behaviors for special characters to be aware of.

Spaces

Due to the implicit AND'ing behavior described in the Compound Search section, searching for strings with spaces in them requires quotes.

"job failed"

This will only return log lines with the exact case-insensitive phrase job failed.

Symbols

By default, if you include a symbol in your query, we will match your query exactly.

%VARIABLE%

This will return all log lines with %VARIABLE% in them.

Colons

Since the colon is a reserved character for field search, quotes are required when searching for strings with colons in them.

"response:"

This will return all log lines with the string response: in them.

Caveats

Line Ordering in the Viewer

By default, the lines inside the log viewer are displayed in the order in which they were logged and ingested. But, due to the distributed nature of how logs are sent and received, there are some important points.

• A timestamp is not granular enough to uniquely identify a line. Lines can be logged in the same millisecond, or even the same microsecond, but we still need to uniquely distinguish between these lines. We call this value a 'line identifier'.
• This line identifier is assigned at the time each line is ingested, and used by our web application to order lines in the viewer.
• The local time between log sources and our system clocks may differ, with values ranging from milliseconds to days (sometimes even months). Some of our ingestion methods also include a 'now' timestamp to determine this difference. We call this value 'time drift'.
• The time drift value is applied to the timestamp of each of lines in that request, ensuring that time is standardized across your logs.

We understand that in certain cases you may wish to order your line by timestamp instead of the unique line identifier. To enable this, go to Settings -> User Preferences -> Viewer Options and check Chronological ordering. However, be aware that this setting may result in certain undesirable behaviors, including:

• When scrolling in the web viewer, lines may insert at both the top and bottom of the viewer, creating a jittery rendering effect
• Lines that were previously displayed together in the web viewer may no longer be sorted this way.