Skip navigation
Share:|

EUEM makes extensive use of filters. These are used in the following manners to name a few:

 

1) To include or exclude subsets of your traffic data with regards to what gets processed by EUEM

2) To control what gets included into the data for specific Watchpoints

3) To control where to apply rules.

 

While one could write filters completely from scratch, the Filter Expression Builder makes the work far easier by allowing you to make selections from dropdown boxes to unlock the full power of the filter expressions. Filters can be quite generic, using a single condition or very specific relying on a series of conditions to be met. With regards to Watchpoints, a complex, multi-condition filter can be handled either by a single complex filter or by several independent filters where one can control whether all or any of the filters must be met for traffic data in question to be included or the rule in question to be acted upon.

 

Single filter rule:

single-rule.png

Multiple filter rules:

multi-rule.png

Next, we can focus on how breaking up a URI into its components allows us to capture multiple matches by leveraging the various string operators and how to use them most efficiently. For matters of simplicity, we are going to focus on strings and the parts of the URI.

 

A URI such as: www.example.com/wonder/access_form.aspx?q1=test&q2=blue can be broken down as follows:

 

URI Host = www.example.com (This is the name of the application in question)

 

URI Stem = /wonder/access_form.aspx (This is the name and path to the specific resource in question)

 

Query Parameters = ?q1=test&q2=blue (Query parameters are a way to pass information in the URI call that may affect the details of the resource that is returned)

 

By focusing on say just the URI Host, we can grab all of the traffic related to the application in question. If we instead focus only on the URI stem, we can grab data related to a specific resource that may exist on multiple applications that we might be monitoring.

 

Because the paths to the location might not be the same from application to application, that's where the string operators come in. We'll start with the simplest of these operators:

 

  • Is equal to (=) This means that the part in question in the traffic must exactly match what is in the filter
  • Starts With This means that the part in question in the traffic must start with the same characters defined in the filter
  • Ends With This means that the part in question in the traffic must end with the same characters defined in the filter
  • Contains This means that the part in question in the traffic must contain the string defined in the filter
  • Is in comma-seperated list means that the string in the traffic must match one of the strings in the comma-separated list defined in the filter.

 

For example if one application has the access_form.aspx resource here in one application: /wonder/access_form.aspx and here in another application: /glue/membership/access_form.aspx we could capture this same resource in both applications using (url.stem_string endswith "access_form.aspx" ignorecase).

 

In the same way, if we wanted to focus only on the web servers for our multiple applications, we could use something like (url.host startswith "www").

 

The operator that requires the least amount of resources is the Is equal to operator because the comparison is very straightforward. The string for the part in question either is or is not what is defined in the filter. For operators like Contains, EUEM must search through the part in question.

 

Sometimes we might want to match more than one condition, hence the Grouping & Chaining Operators: AND, OR & NOT

 

AND is used when multiple conditions must exist simultaneously in the traffic. OR is for when at least one of the conditions in question must be true. For example, a single request can only be addressed to a single URI Host, so if we are looking for traffic to either Application A, B or C, this is where the OR operator is used. NOT is used to exclude traffic where the string in question is seen.

 

When creating a complex filter expression with more than one condition, we can choose to add the new conditions to the expression using: AND, OR, AND NOT, OR NOT.

 

Lastly, we can create filter expressions where say the URI Host must be one of three choices while at the same time, the URI Stem must match a specific string condition. In order to make this happen, the conditions and arguments must be grouped. For this example, the filter expression might look like this:

 

((url.host is "animal.example.com")  OR  (url.host is "mineral.example.com")  OR  (url.host is "vegetable.example.com"))  AND  (url.stem_string endswith "qualities.html" ignorecase)

 

The additional brackets make it clear where the choice is and where the conditions (or groups of conditions) must both be true.

 

Creating efficient filters means reducing repetition and fully leveraging the string operators in question. By creating efficient filters, we free up resources to handle more traffic volume.

 

Please feel free to rate this blog or leave us any questions or comments as we are always looking to improve our documentation.

 

To see more blogs like this, see:

TrueSight App Visibility Manager

Share:|

In this blog, we will cover how to ensure that DNS Is properly configured for End User Experience Management (EUEM) so that calls to external services can be correctly routed.

 

Workstations and other client devices get their DNS server and IP settings automatically through DHCP when joined to a network, but servers which are accessed by many devices need to have fixed addresses, and hence, static IP configuration.  Because these networking settings are entered manually, there is no call made out to get these parameters from DHCP. As such, the IP addresses for services such as DNS and NTP must also be entered manually.

 

On Linux systems, the DNS servers that the system uses for name resolution are defined in the /etc/resolv.conf file. Each nameserver line in the resolv.conf file defines a DNS server.  The entries are prioritized by the order they are found in the file, so the primary DNS server would be the first line, the secondary would be the second, tertiary third and so on. At the bottom of the file, we have a search line which is used to complete fully qualified domain names if only the host name is given. For example, if I have “search bmc.com” and I pinged “docs” , the system would assume that I am referring to “docs.bmc.com”.

 

For example:

 

nameserver <IP_of_primary_DNS_server>

nameserver <IP_of_secondary_DNS_server>

nameserver <IP_of_tertiary_DNS_server>

search bmc.com

 

 

Lastly, the DNS servers defined by the resolv.conf file must be identified by IP and not name for the simple fact the system won’t know how to handle domain names until after it knows how to reach the DNS servers.

 

Please feel free to rate this blog or leave us any questions or comments as we are always looking to improve our documentation.

 

To see more blogs like this, see:

TrueSight App Visibility Manager 

Filter Blog

By date:
By tag: