Tip:
Highlight text to annotate it
X
One of the most important abilities of EUEM in helping you get to the bottom of performance
and availability problems in your traffic is being able to read into the HTTP content
of your traffic.
In order to leverage this data to help you localize the cause of your problems, we make
use of what we call Custom Fields. These are fields of data which we can use to filter
traffic, as well as determine if specific values for these custom fields seem more problematic
than others. Once we've defined a Custom field, we then need to create what we call Extraction
rules to tell the system where to pull the data from to give us a value for this Custom
field for the hit in question whether that be at the Object, Page, Session or Primitive
level.
Technically all fields of data in EUEM are Custom fields, even the System Custom Fields
(as denoted by the gear symbol) that the system MUST have defined in order to function properly.
While these Custom fields cannot be deleted, they can be modified and even broken if sufficient
care is not taken when setting up their Extraction rules.
The first step is to determine at what level you wish to create this Custom field. Object
level CFs are used to identify objects, Page level CFs are used to identify page constructs
and usually pull their information from the objects within these pages using the first,
last or all occurrences or the entry or exit points. Session level CFs operate in much
the same way but can pull their information from either the pages or objects below them.
There is a fourth type of Custom Field and that is the Primitive Custom field. These
only exist on the Collectors and monolithic appliances and their primary use to to delve
into the hits and pull out information right out of the headers and even the HTTP content
and store it. This "hit level" data can then be leveraged at the Object, Page and Session
level by using the Primitive custom field as a Data source.
Custom field data can be strings, Integers, Booleans, Decimals and IP addresses. When
defining string custom fields it is also necessary to limit the amount of characters to store
for the value. The more data stored per hit, the less of them can be stored in the database,
so it's important to keep such limits in check.
Once we've defined our Custom Field, we then need to figure out where we're going to get
the data to feed it. It is quite possible within your traffic, especially if you are
monitoring multiple applications, that you may need to define different ways of extracting
that information. This is why for every extraction rule we wish to define beyond the default
rule we must define a filter to focus on the subset of traffic for which we wish to have
that rule apply. Sometimes all you need to do is identify a subset of traffic defined
by your filter so instead of pulling data fromm the traffic, you might just have a fixed
string returned instead.
Lastly, once we've specified what traffic we want to look at and where we want to pull
the data from, we can also create transformations to turn the output into something more human
readable or at least more meaningful to your organization. These can be used to trim, prefix,
find and replace, etc., including string and IP mappings. This allows you to turn what
might essentially be unintelligeable code into clear information you can use in your
investigations.