# Query Filter Syntax and Best Practices ## Overview The [Dashboard](/console-walkthrough/analytics/dashboard.md) and [Events Log](/console-walkthrough/analytics/events-log.md) pages display data based upon user queries. These queries are entered into the text box at the top of each page. A query is essentially a filter; it instructs Link11 WAAP which data should be displayed, with all other data excluded. Admins should understand the syntax of these filters, and how to create them. The discussion below explains: * How to quickly and efficiently build filters to display the desired data * The syntax and operators available for this process ## Filter structure Individual filters include a field name, operator, and value. Example: `status=200` Multiple filters can be combined; these are delimited with a comma, and evaluated with a logical AND. Example: `status>=200,status<=299` Strings are encapsulated with double quotes. Regex can be used; see the examples in the [Operators](#query-operators-and-examples) section below. ## Quickly Creating a Filter Simple filters can be entered directly into the query box. However, admins will frequently need to create complex filters, e.g. when investigating attacks or trends. {% hint style="info" %} For a full discussion and examples of how to use L11WAAP's tools to investigate and explore traffic data (such as discovering anomalies, diagnosing False Positive alarms, and more), see this page: [Understanding and Diagnosing Traffic Issues](/using-the-product/best-practices/dealing-with-false-positive.md). {% endhint %} L11WAAP provides the ability to build and add filters to the box automatically. In the Dashboard or Events Log, admins can right-click on analytics data and then select "Show Matching" (to add an inclusionary filter) or "Hide Matching" (to add an exclusionary filter). Afterwards, the filter string can be manually edited if desired. ### Example 1: Dashboard In this screenshot, the Dashboard is displaying all traffic data from a specific time period. The admin wishes to display only requests that originated from China and were blocked for a specific reason. Going to the [Top Metrics section](/console-walkthrough/analytics/dashboard.md#top-metrics) at the bottom of the Dashboard, the admin finds the **Countries** list and right-clicks on **China**:

Selecting `Show Matching` adds the appropriate filter to the query box:

Next, the admin goes to the **Blocked & Monitored** list, finds the blocking reason of interest, and right-clicks on it:

Selecting `Show Matching` adds another filter to the query box:

... and running the query will then display the desired results. ### Example 2: Events Log The process described above could also be run from the Events Log, with only a few minor differences: * Since the Events Log does not contain a Top Metrics section, filters can be added when viewing specific events, and built from the individual event parameters of interest. * The `Show Matching` and `Hide Matching` filters will be created from the specific parameter that was clicked on. In the example below, selecting `Show Matching` will create a filter to show all events with the Result of `Blocked by origin`.

### Example 3: Manually Editing Filters Sometimes it is necessary to manually edit filter strings after they are built. When viewing the Events Log, sometimes it is difficult to find an event that includes the exact characteristics that are desired for the filter. In this situation, admins can build the filter from an event that is similar (thus allowing the system to construct the correct syntax and format automatically), and then edit it manually. In other cases, the filter strings are too specific, because the admin wants something broader. This is especially true when building filters from Events Log entries, for example when selecting a `Blocking Reason` or `Monitoring`Reason. In these situations, the admin can create the filter, then edit it appropriately. For example, a specific instance of XSS will produce a filter that looks like this: `reason="Block - content filter xss[lvl3] - default contentfilter - [URI argument a==]` This can be edited to show all requests blocked for XSS: `reason~"xss"` ## Query Operators and Examples

Symbol	Meaning	Data Types	Examples
=	Equals (exact and full match.) `reason=“ACL”` only matches requests when `reason` exactly equals `ACL`.	String Number Boolean Date/Time	method=“GET” reason=“ACL” country="United States" blocked=true status=300
!=	Does not equal (doesn't match exactly). `reason!=“ACL”` only matches requests when `reason` does not exactly equal `ACL`.	String Number Boolean Date/Time	status!=200 reason!=“ACL”
~	Contains (i.e., partial match). `reason~“ACL”` only matches requests when `reason` contains `ACL`.	String	method~“GET” reason~“ACL”
!~	Does not contain (no partial match was found). `reason!~“ACL”` only matches requests when `reason` does not contain `ACL`.	String	method!~“GET” reason!~“ACL”
~=	Regex match	Regex	method~=“^(GET\|POST\|METHOD)$”
!~=	No Regex match	Regex	method!~=“^(GET\|POST\|METHOD)$”
header[key] cookie[key] argument[key]	Header, cookie, or argument has the key with specified value. `header[~“arg1”]=“foo”` only matches requests with a header key that contains `arg1` and value that exactly equals `foo`.	String	Exact match in key: header[=“arg1”]=“foo” Contained in key: header[~“arg1”]=“foo” Regex in key: header[~=“arg1”]=“foo”
>	Greater than	Number	status>399
<	Less than	Number	status<400
>=	Greater than or equal to	Number	status>=300
<=	Less than or equal to	Number	status<=399
in	In: Request has a field within the specified values	Number String	status in (200,201,203)
between	Between: Request has a field with a value equal to or between the two given values	Number and number, or Date/time and Date/time	status between 200 and 299

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://waap.docs.link11.com/reference-information/query-filter-syntax-and-best-practices.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.