Filters allow you to reduce and control the data returned by a query, showing only the records that meet specific conditions. They are one of the most important tools in the query builder, as they help you move from large volumes of logs to concrete, understandable information.
Each filter is applied to a field in the selected collection and uses an operator that defines how the field's value is compared with the value you enter.
How filters work
A filter always consists of three parts:
- Field: which data you are filtering on (IP, status code, domain, date, user, etc.)
- Operator: how the value is compared (equals, contains, greater than, etc.)
- Value: what you want to search for or exclude
Example:
- Field: status code
- Operator: =
- Value: 500
Result: only records with error 500 are shown.
How filters are combined
All filters in ConnectiLogs work as a cumulative condition (logical AND):
- A record is only shown if it meets all filters at the same time
Example:
- status code = 500
- domain = mydomain.com
Result: you will only see 500 errors from that specific domain.
Types of filters
Equals filter (=)
The equals (=) operator is the most basic filter and also one of the most important in ConnectiLogs. It is used to select only records whose value exactly matches the value you have defined, without allowing variations, partial matches, or interpretations.
It is a strict comparison operator: what you type is exactly what is searched for.
When you apply a filter with the equals operator, ConnectiLogs scans all records in the selected field and returns only those that meet this exact condition:
- field value = filter value
Differences in format, additional text, extra spaces, or variations are not allowed.
Basic example:
If you are working with the access logs collection and want to see only server errors:
- Field: status code
- Operator: =
- Value: 500
The result will be:
You will only see records whose status code is exactly 500.
The following are automatically excluded:
- 404 (not found)
- 200 (ok)
- 301 (redirect)
- any other value
Characteristics
- Exact match (100%)
- Does not allow variations or patterns
- Does not recognize "partially correct"
- Reduces the dataset in a very controlled manner
Common mistakes when using "="
When working with this operator, some common mistakes are often made:
- Thinking it includes partial matches (it does not)
- Not considering format differences (www vs no www, uppercase, etc.)
- Using it when you actually need a "like" type filter
- Forgetting that the value must exactly match the one stored in the collection
Not equals filter (!=)
The not equals (!=) operator is the direct complement of the equals operator. It is used to exclude all records whose value exactly matches the value you specify, showing only those that are different.
It is a negative filtering operator: instead of defining what you want to see, you define what you want to remove from the result.
How does it work?
When you apply a filter with !=, ConnectiLogs evaluates each record in the selected field and includes it only if:
- field value != filter value
In other words, any exact match with the specified value is automatically excluded from the query.
Basic example:
If you are analyzing status codes in access logs:
- Field: status code
- Operator: !=
- Value: 500
The result will be:
You will see all records except those with 500 error.
This includes:
- 200 (ok)
- 404 (not found)
- 301 (redirect)
- any other code other than 500
Characteristics:
- Exact exclusion of values
- Works as an inverse filter to "="
- Reduces the dataset by removing known noise
- Very useful for comparative analysis
- Does not allow partial matches
Common mistakes when using !=
- Using it when you actually want to exclude several values (better to use not in)
- Confusing it with partial filters (it does not work with "like" type matches)
- Forgetting that it only excludes exact matches, not variations of the value
Contains filter (like) and not contains (not like)
The like and not like operators are used to filter text fields when you are not looking for an exact match, but rather patterns or text fragments within a value. They are especially useful in ConnectiLogs because many fields (such as domains, paths, users, or user agents) contain structured information where you do not always know the complete value.
How do they work?
Unlike the equals operator (=), which requires an exact match, like allows partial matches, i.e., finding records where the text appears within the field's value.
- like: includes matches that contain the pattern
- not like: excludes matches that contain the pattern
Using the % wildcard
The behavior of like and not like is controlled by the % symbol, which acts as a wildcard. This indicates that any text can exist in that position.
This allows you to define three types of searches:
Contains text in any position
- Pattern: %text%
Searches for records where "text" appears anywhere in the value.
Example:
- filter: domain like %mydomain%
Result:
- mydomain.com
- api.mydomain.net
- test.mydomain123.es
Starts with text
- Pattern: text%
Searches for values that start exactly with that text.
Example:
- filter: domain like mydomain%
Result:
- mydomain.com
- mydomain.net
- mydomain-api.com
Would not include:
- api.mydomain.com
- testmydomain.com
Ends with text
- Pattern: %text
Searches for values that end with that text.
Example:
- filter: domain like %mydomain
Result:
- api.mydomain
- test.mydomain
- logs.mydomain
Would not include:
- mydomain.com
- mydomain.net
What does not like do?
The not like operator works exactly the same as like, but in reverse: it excludes all records that contain the specified pattern.
Example of not like
- Field: user agent
- Operator: not like
- Value: %bot%
Result:
All records where the user agent contains "bot" will be excluded, for example:
- googlebot
- bingbot
- any crawler or automated script
And the following will be kept:
- real browsers
- human traffic
- other agents not related to bots
When to use like and not like?
Use like when:
- You don't know the exact value of the field
- You want to group variants of the same concept
- You are analyzing structured texts (domains, paths, logs)
- You need to search for patterns in long fields
Use not like when:
- You want to remove noise from the data
- You need to exclude known patterns (bots, spam, tests…)
- You are cleaning results for more precise analysis
- You want to keep "human" or relevant traffic
Important differences from other operators
- =: exact match
- like: partial match (pattern)
- !=: exact exclusion
- not like: exclusion by pattern
Common mistakes
- Forgetting to use % and not getting expected results
- Using like when you actually know the exact value (better to use =)
- Overusing not like and removing too much useful data
- Not considering that small text variations change the result
In filter (in) and not in filter (not in)
The in and not in operators are used when you need to work with lists of values, rather than comparing against a single value. They are especially useful in ConnectiLogs because they allow you to simplify multiple filters into a single condition, making queries easier.
How do they work?
These operators compare a field's value against a set of options:
- in: the record is included if its value is in the list
- not in: the record is included if its value is NOT in the list
In operator (in)
The in operator returns all records whose value matches any of the items in the defined list.
Basic example:
If you are analyzing status codes:
- Field: status code
- Operator: in
- Values: 404, 500
Result:
Only records whose status code is:
- 404
- 500
Everything else is excluded from the query.
Not in operator (not in)
The not in operator does the opposite: it excludes all records whose value is in the specified list.
Basic example
- Field: status code
- Operator: not in
- Values: [200, 301]
Result:
All records will be shown except:
- 200 (OK)
- 301 (redirect)
This is useful when you want to focus on errors or anomalous behavior.
When to use in and not in?
Use in when:
- You want to filter several specific values at the same time
- You are working with limited states, codes, or categories
- You need to simplify multiple OR conditions into a single rule
- You want to focus on a specific set of events
Use not in when:
- You want to exclude several known values
- You are cleaning noise (bots, internal traffic, tests…)
- You need to analyze "everything except…"
- You want to reduce results without losing overall context
Common mistakes
- Using in when there is only one value (better to use =)
- Confusing in with like (there are no partial matches here)
- Including too many values without a clear criterion
- Not validating that all values in the list actually exist in the data
Greater than (>), greater than or equal to (>=), less than (<), and less than or equal to (<=) filters
These operators are used for numeric or temporal comparisons within ConnectiLogs. They are important when you need to work with thresholds, ranges, or limits, especially in fields such as dates, response times, file sizes, or any quantifiable value.
Unlike text filters, these operators do not look for exact matches or patterns, but rather order relationships between values.
How do they work?
All these operators compare a field's value with a reference value:
- > (greater than): the field's value must be strictly greater
- >= (greater than or equal to): the field's value must be greater than or equal
- < (less than): the field's value must be strictly less
- <= (less than or equal to): the field's value must be less than or equal
Greater than (>)
The > operator returns only records whose value is greater than the indicated value, without including it.
Example
- Field: response time
- Operator: >
- Value: 1
Result:
Records with response time greater than 1 second will be shown:
- 1.2s
- 2s
- 5s
Does not include:
- exactly 1s
Greater than or equal to (>=)
The >= operator is similar to the previous one, but it does include the limit value.
Example
- Field: size
- Operator: >=
- Value: 4000
Result:
All records with size:
- 4000 KB
- 4500 KB
- 10000 KB
Less than (<)
The < operator returns records whose value is less than the indicated value, without including it.
Example
- Field: response time
- Operator: <
- Value: 1
Result:
Only records with response times less than 1 second will be shown:
- 0.2s
- 0.5s
- 0.9s
Does not include:
- exactly 1s
Less than or equal to (<=)
The <= operator includes all values that are less than or equal to the defined value.
Example
- Field: size
- Operator: <=
- Value: 1000
Result:
Records with size will be included:
- 1000 KB
- 800 KB
- 200 KB
Combined use (ranges)
These operators are especially powerful when combined to create ranges of values.
Range example
- response time >= 1
- response time <= 3
Result:
Only records with response times between 1 and 3 seconds (including both ends) are shown.
This allows you to analyze behavior within a specific interval.
Key differences
- > and < → exclude the limit value
- >= and <= → include the limit value
- They only work with numeric or temporal data, not text
- They are the basis for building precise analysis ranges
Common mistakes
- Using them on text fields (not valid)
- Confusing > with >= and losing the limit value
- Not defining ranges correctly (leaving gaps between conditions)
Practical tips for using filters
In ConnectiLogs, filters are more powerful when used with a clear, progressive strategy, rather than trying to build a perfect query from the start.
It is highly recommended to always start with basic, easy-to-validate filters (for example, by domain, status code, or date range) and check that the query returns data before adding more conditions. From there, you can refine gradually until you reach the level of detail you need.
It is essential to choose the right operator according to the data type. For exact matches use =, for specific exclusions !=, for lists of values in / not in, for flexible text searches like / not like, and for numeric or temporal ranges >, >=, <, <=. Using the wrong operator is one of the most common causes of empty or unexpected results.
It is also important to understand that all filters combine with each other cumulatively (AND), which means that each condition reduces the dataset. Therefore, adding too many restrictive filters from the start can cause you to lose relevant information or even result in the query returning no results.
When working with multiple known values, use in / not in instead of repeating several equal filters, as this simplifies the query and improves readability. If you need to search for patterns within text, use like / not like carefully with the % wildcard, avoiding interpretations that are too broad or too restrictive.
In summary, the key is to balance precision and breadth: start with simple filters, validate results, and refine gradually, always ensuring you use the appropriate operator for each data type.