Once you get over a couple of hundred events, having a convention you follow for naming them helps keep things organized. Here's one I like to use when setting up events for a client. I'd like to acknowledge the contributions that Chris Utter made to these conventions, doing the original documentation of what had been an ad-hoc naming scheme, and bringing some semblance of organization to it all.
When writing other blogs that discuss how to create events to measure functional areas of an application, I will cite this blog, rather than having to explain the naming convention I use over and over.
Event names show up all over the cxImpact systems, so let me setup some background for the reasons behind some of these conventions, and also some places that demand opposing choices.
1) Event names are used in search, both Portal and RTV. In these places, most of the full name is available in the selection screens, so the length of the event name is mostly immaterial. However, the event name filter in the Portal operates in a funny way. It seems that, if you have a 'space' anywhere in the event name, that as soon as you put a space in the event name filter, it matches all of the events with a 'space' in their names. So I usually try to eliminate spaces, or, if I have a long event name, that at least some portion of it is unique enough to let me zero in on just a handful of like named events.
2) In this convention, I prefix event names with their event group, or a reasonable facsimile thereof. There are places where events are always shown alphabetically. Including the group name in the event name serves to keep the like-grouped events together.
3) When you look at comparison charts and dashboard components, especially with moving averages displayed, only about the first 10 characters of the event names are displayed. So we need to keep the group names as short as is understandable, and make the event names uniquely identifying as near the beginning of the name as possible
4) Don’t think of this as hard rules. there will always be good reasons for exceptions.
Event Name Convention
In a nutshell, the convention looks like the following:
Application Abbreviation:GroupName:Description[R|V][List][{C|P}]:[B|E|O|CS]
GroupName:: the name of the group the event belongs to. These group names are also part of the naming convention (see below) and provide a hierarchy of events that make it easier to find the one you are interested in. For example, G:Ops is Global Operations events - events like EveryHit, or StatusCode list
Description:: A short, descriptive name for the event. Free text, excluding dashes, colons, quotes (double or singe), semi-colon, and parenthesis. Child and parent events append a C or P suffix to description. In the free text, you may chose to use some conventions to indicate the event is combinatorial. In my examples, I use the ^ (read it as "and') in event descriptions, e.g "Managed 5xx^notBot", which means the event fires when the hit has any kind of 5xx error AND is Not a Robot hit. Another convention I use is "|" for OR in a few event descriptions.
Modifiers:: Here there are some standard modifiers, but you may wish to add your own.
[R|V] – meaning Request or View. I’ve written about the need to separate events into the Request for a page, and events that recognize which page gets delivered.
[List] - this event makes use of a List, and is a Value event. I don't try to identify the kind of list (numeric, text, group, external group) in the event name, but the event name will usually include or refer to the Name of the List. List events usually use the :E ReportCount, but occasionally use :O. You will often find that List events are also Child events, because you want to measure values only when specific conditions occur..
{P} - this is a Parent event. In the description of the parent, I always try to include "Child is xxx", and provide the child event's unique ID
{C} - this is a Child event. In the description of the child, I always try to include "Parent is xxx", and provide the Parent event's unique ID. his one is important. There is no way to find the parent of a child event, so remember to document it here!
EventType:
CP - this is a Compound Page Event, easily the most prevalent.
CS - this is a Compound Session Event. No ReportCount modifier is needed, as these events are always “:O”, because they only occur once in any session.
:SAEP – Session Attribute Event per Page. Usually used with the :B modifier. Using :E as the ReportCount would consume a lot of disk space (Index or Report DB), and would not be very useful.
:SAES – Session Attribute Event per Session. No ReportCount modifier is needed, as these events are always “:O”, because they only occur once in any session.
:TH - Threshold event. No ReportCount modifier is needed, as these events are always “:O”, because they only occur once in any session.
ReportCount:
:E - this event is "counted every time" (for Portal). I’ve found that trying to add a mnemonic for the Search/Indexing is too confusing to bother with.
:O - this event is "Counted once per session".
:B – This is a building block event, and not counted at all.
Group Names
The hierarchy of groups depend on the application, but I've found some common event groups at all of my clients. I'll blog about the contents of each group later, but here are some, with sparse explanation. The importance of the group name as part of the event name means that they must be mentioned here.
Global events, that are applicable no matter what the application is
G:Ops - operational events, usually those that count "everyHit". Use these with care, as they add a one-event overhead on every single hit. These G:Ops events can include status code list events, status code group events, http_host events, and reqcancelled events.
G:Err – Global error events, that can occur on any page of any application. This includes the all-inclusive G:AnyException, which is the “OR” of “Any 5xx Error” OR “AnyUnhandledException” OR “AnyManagedExcpetion”
G:Err:Status - events that count status code errors, always includes the 5xx errors, and usually includes 4xx errors.
G:Err:Sys - events that detect errors thrown by the subsystems. These are the Java.lang errors, the Oracle and SQL Server error messages, the ASP runtime errors, and any other errors that come straight from supporting subsytems when they are not caught by the application. The statuscode value of these is are usually 500.
G:Gen - events that measure page generation times across all hits of the web presence. If the application supports the Tealeaf Client User Interface (CUI) events, you may wish to put page render times and page dwell times in this group as well.
G:Bot - events that recognize search engine, automated searching, and monitor programs that contact your web presence. (Hint: Remember to exclude your XML hits from the global robots. XML applications often use the same HTTP_USER_AGENT as search engines, so be sure your robot events are smart enough to segregate them appropriately).
Next in the Group names are groups that apply to a specific application. If you have enough events that you are serious about naming conventions, odds are high that your web presence consists of multiple applications. You may be serving a combination of web pages and web services (XML). Or you may have different web applications. Hopefully, you can get away with a single character to identify each application as a prefix for the group(s) of events that work just with that application. For this blog, I'm going to use I for application "InsuranceQuotes", R for application "RetailPurchase", and X for "XML Transactions".
I:,R:,X: - Events associated with their respective application.
I:Ops:: - Events that count 'every hit' on application I. Includes the event(s) that are the definitive event (what makes a hit an "InsuranceQuote" hit). This group can be one option for placing "parent" events for the application-specific global events, the CP event that has to fire before a child event fires.
I:Err:Status::, I:Err:Sys::, I:Err:Size:: - the same events (near copies) as the global events by the same name, these slice the errors into just those coming from "InsuranceQuote"
I:Gen:: - these provide the page generation time breakdown for the specific app. One event in this group should aggregate of all pages of the application. Other events should trigger for specific pages, and provide “parent” events for the child event that buckets page generation time for a specific page. This is an appropriate place to put render time and dwell time events, too.
I:Bot:: - search engine breakdown by application I. This group is optional if you already have a BI solution (external hit database) for analyzing search engine behavior. If not, these will provide some insight into their activity.
R:Ops, R:Err:Status, R:Err:Sys, R:Err:Size ,R:Gen,R:Bot , and the X permutations are also copies of "G" versions. Note that there is no X:Bot event copies, unless you want one for validation. The robot detection rules should have eliminated any robots from this group. The X group stands for the XML services application that the site provides, and you may not want to measure so-called bot traffic here, unless your bot detection techniques are sophisticated enough to distinguish between an expected program using your services, and a bot.
I hope this gives you a starting point for creating an event naming convention for your Tealeaf implementation. Feel free to use as much or as little as you like. Comments are welcome, I’d like to hear your feedback on how others have organized and named their events. Hope you are all having fun and profitable Movie Days with Tealeaf!
No comments:
Post a Comment