Select Page

# Advanced Search

ZettaLogs features advanced search capabilities backed up with its powerful Elasticsearch back-end. The query syntax follows the Apache Lucene query syntax (explained below). ZettaLogs converts unstructured log lines into structured documents. The documents are indexed and stored for efficient and interactive search capability. The documents have fields which can be searched individually. By default a search is run on the body field which contains the raw log.

You may write any kind of text into the search bar and it will be searched as free text inside the body of logs. Once you hit the enter, all of the logs in your project will be searched for the words you put in the search bar. The results found will be shown in tabular form with the query words highlighted.

The time span of the search may be adjusted from the date dialog to the right of search bar. The document count matching the query may be observed as a bar chart with respect to time. The chart may be zoomed in with dragging the mouse pointer over the region of interest.

A new search will be triggered zooming in to the time span selected.

The time span of the search may be adjusted precisely from the date dialog. Two types of date selection is possible: absolute and relative. With absolute date selection, the exact start and end time of the region of interest may be specified using a calender input.

Relative date input may be used to define time spans that start at a specific period before now. It is very useful when watching logs arrive live.

## Query Syntax

ZettaLogs uses Elasticsearch which in turn is built on Apache Lucene. Thus the query syntax is inherited from Apache Lucene query syntax. The query syntax is also explained in Elasticsearch query string document.

A query is broken up into terms and operators. There are two types of terms: Single Terms and Phrases. A Single Term is a single word such as “test” or “hello”. A Phrase is a group of words surrounded by double quotes such as “hello test”. Multiple terms can be combined together with Boolean operators to form a more complex query.

### Fields

When performing a search you can either specify a field, or use the default field. You can search any field by typing the field name followed by a colon “:” and then the term you are looking for. As an example, let’s search for logs from host “fethiye”:

• hostname:fethiye

or let’s search for logs parsed as apache format:

• hostname:fethiye AND format:apache

This brings us all the documents from host fethiye that are parsed as apache format. Let’s also only bring those apache log lines with response length greater than 10000:

• hostname:fethiye AND format:apache AND apache.bytes:>10000

### Boolean operators

By default, all terms are optional, as long as one term matches. A search for “foo bar baz” will find any document that contains one or more of foo or bar or baz. Boolean operators can be used to provide more control.

The preferred operators are + (this term must be present) and – (this term must not be present). All other terms are optional. For example, this query:

• quick brown +fox -news

states that:

fox must be present
news must not be present
quick and brown are optional

The familiar operators AND, OR and NOT (also written &&, || and !) are also supported. However, the effects of these operators can be more complicated than is obvious at first glance. NOT takes precedence over AND, which takes precedence over OR. While the + and – only affect the term to the right of the operator, AND and OR can affect the terms to the left and right.

### Grouping

Multiple terms or clauses can be grouped together with parentheses, to form sub-queries:

• (quick OR brown) AND fox

### Special characters

If you need to use any of the characters which function as operators in your query itself (and not as operators), then you should escape them with a leading backslash. For instance, to search for (1+1)=2, you would need to write your query as $$1\+1$$\=2.

The reserved characters are: + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /

Failing to escape these special characters correctly could lead to a syntax error which prevents your query from running.

### Wildcards

Wildcard searches can be run on individual terms, using ? to replace a single character, and * to replace zero or more characters:

• qu?ck bro*

Note that a wildcard at the beginning of a word (eg “*own”) is not allowed.

### Regular expressions

Regular expression patterns can be embedded in the query string by wrapping them in forward-slashes (“/”):

name:/joh?n(ath[oa]n)/

The supported regular expression syntax is explained in Elasticsearch’s regular expression syntax.

### Ranges

Ranges can be specified for date, numeric or string fields. Inclusive ranges are specified with square brackets [min TO max] and exclusive ranges with curly brackets {min TO max}.

All days in 2015:

• date:[2015-01-01 TO 2015-12-31]

Numbers 1..10

• count:[1 TO 10]

Tags between alpha and omega, excluding alpha and omega:

• tag:{alpha TO omega}

Numbers from 10 upwards

• count:[10 TO *]

Dates before 2015

• date:{* TO 2015-01-01}

Curly and square brackets can be combined:

Numbers from 1 up to but not including 5

• count:[1 TO 5}

Ranges with one side unbounded can use the following syntax:

• age:>10
• age:>=10
• age:<10
• age:<=10

## Multi-Search

One of the properties that makes ZettaLogs unique and powerful is its multi-search capability. Upto four independent queries may be run at the same time. The results will be displayed on the same screen with different and customizable colors for each result. This makes the correlative analysis of different log sources a breeze. The output is visually appealing and easy to interpret.

A new search bar may be inserted by pressing the “+” sign to the left of the main search bar. Completely different queries may be input to each search bar. The color of the query result may be adjusted using the color select widget which is the small colored circle. For example, in the picture above we have two searches targeting two different but related logs. First we search for the word “ban”. It is found inside the fail2ban logs which indicates that an IP is banned because of too many failed login attempts. The second query finds words “failed” and “password”. These are found in ssh logs showing failed user login attempts. The result is shown sorted according to timestamp which reveals the relationships between log events with respect to time. As it can be seen, after ssh log reports six failed password attempts from the same IP, fail2ban log reports that same IP was banned. This clearly shows that our fail2ban settings are functioning properly.

The result sets of multiple independent searches may intersect. The multi-search table is powerful enough to handle these kind of situations. The following figure shows three different search queries colored with three different colors. The results belonging to single search are in single solid color. However, results belonging to two or three searches are shown with two or three stripes of color, respectively.