Automated Gomez Performance Monitoring Part 3 - Page Identification
In the first article in this series “Automated Gomez Performance Monitoring”, I illustrated how to create an iRule that would automatically inject the required JavaScript code into your web pages to integrate your application with the Gomez Performance monitoring system.
In part two titled “Automated Gomez Performance Monitoring Part 2 – DataCenter Identification”, I expanded on the first article by allowing you to add DataCenter specific identifiers into the Gomez script, thus enabling you to build reports for your applications running from specific geographic locations.
For this third article, I’m going show how to build a lookup table in your iRule that will allow you to give user friendly names to different application pages.
On a site like DevCentral that uses URI formats to optimize Search Engine Optimization (SEO) rankings, there can be a lot of URLs generated. Take, for instance, our tech tip page that this article is hosted on. It it really just a single application presenting tech tips but the tech tip identifier is presented as part of the URI (ie. …/ArticleView/articleId/1234/default.aspx). For a reporting system like Gomez, each page looks like a separate page. This doesn’t scale well when your report contains 10’s of 1000’s of URLs. In the site for DevCentral, we decided it would be better to report on Tech Tips as a whole and treat them as a single “page”.
The Page Identifier
Like the Group Id parameter defined in the last article, there is a Page Identifier (pgId) parameter allowed in the Gomez client code. By default, if this value is omitted, the reporting system goes by the URI of the page. But, you can put whatever you want in and that will override the URI as the key and use the supplied value.
For iRules, this turns out to be quite simple. The first step is to build a lookup table. I did this by using the TCL list command to create a basic list.
1: set GOMEZ_PAGEID_LIST [list \
2: "eq / HomePage" \
3: "eq /default.aspx HomePage" \
4: "starts_with /app1/page1 App1_SubPage1" \
5: "starts_with /app1/page2 App1_SubPage2" \
6: "starts_with /app1/page3 App1_SubPage3" \
7: "starts_with /app2/page1 App2_SubPage1" \
8: "contains /forum/tech Forums_Tech" \
9: "contains /forum/finance Forums_Finance" \
10: "contains /forum/ Forums_Unknown" \
11: "ends_with default.aspx Unknown" \
12: ];In this list are three tokens. The first is the comparison operator to use with the URI. The second is the comparison string itself, and the last is the page identifier. In the HTTP_REQUEST event, I create a lower case version of the URI and then iterate through the list and perform the requested comparisons (eq, starts_with, ends_with, contains, etc) on the values and, if a match is found, use the associated page id in the resulting injected script.
1: when HTTP_REQUEST {
2: set gws_luri [string tolower [HTTP::uri]];
3: # ---------------------------------------------------------------------
4: # Loop through the page id list and look for a match.
5: # ---------------------------------------------------------------------
6: foreach {mapping} $::GOMEZ_PAGEID_LIST {
7: 8: if { $::GOMEZ_DEBUG > 2 } { log local0. "Testing mapping ${mapping};" };
9: 10: set gws_tokens [split $mapping " "];
11: set gws_op [lindex $gws_tokens 0];
12: set gws_match [lindex $gws_tokens 1];
13: set gws_pageid [lindex $gws_tokens 2];
14: set gws_found_match 0;
15: 16: # -------------------------------------------------------------------
17: # attempt to process the comparison. Catch any exceptions and treat
18: # them like a false match.
19: # -------------------------------------------------------------------
20: set error [catch { set gws_found_match [expr \$gws_luri $gws_op \$gws_match]; }];
21: 22: if { $gws_found_match } {
23: 24: if { $::GOMEZ_DEBUG > 0 } { log local0. "Found match with ${gws_match} for uri ${gws_luri};" };
25: set gomez_page_id $gws_pageid;
26: break;
27: } 28: } 29: } 30: 31: when HTTP_RESPONSE {
32: # -------------------------------------------------------------------------
33: # Only process stream replacement if a valid page (uri) was requested and the content type is html.
34: # -------------------------------------------------------------------------
35: if { [info exists gomez_page_id] && ([HTTP::header value "Content-Type"] contains "text/html") } {
36: 37: set gomez_client [subst {<SCRIPT LANGUAGE="JavaScript"><!--
38: var gomez={gs: new Date().getTime(), acctId:'$::GOMEZ_APP_ID', pgId:'$gomez_page_id', grpId:''};
39: //--></SCRIPT>
40: <script src="/js/axfTag.js" type="text/javascript"></script>
41: } ]; 42: } 43: }The magic here is in the fact that with TCL you can evaluate expressions dynamically. In the comparison loop, I’m executing the TCL “expr” statement to evaluate at runtime the comparison defined in the list entry. Cool huh!
In the HTTP_RESPONSE event, the pgId value is inserted from the $gomez_page_id variable and is passed to the Stream filter with the STREAM::expression
1: STREAM::expression "@</head>@$gomez_client</head>@@<body>@$gomez_client<body>@";
I’ve included two expressions in the case that the “</head>” element doesn’t exist on the page. After the first match, we cancel all further matches in the STREAM_MATCHED event.
1: when STREAM_MATCHED {
2: STREAM::disable;
3: }Conclusion
Now, whether you want a minimal integration with your performance code, or you want more granular reporting with geographically different datacenters or page level identification, you can easily implement them from within the network layer. It is trivial to add support for both DataCenter (grpId) and Page level (pgId) into a single iRule to have an all encompassing solution.
Download
You can download the full script from the iRule CodeShare under GomezInjectionWithPageId.
