Instrumenting the Web Site / Web Application to be Monitored

Figure 214 clearly delineates the options available for RUM-enabling a web site/web application, and when each of those options become applicable.

Figure 214 : The options available for RUM-enabling a web site / web application and when those options become applicable

Each of the options depicted by Figure 1 are discussed briefly below:

  • Container assisted injection: If the web site / web application to be RUM-enabled is hosted on an IIS / Apache web server or any of its variants (say, IBM HTTP server or Oracle HTTP server) or is fronted by a load balancer, then you can use container assisted injection to RUM-enable that web site / web application. On IIS, this can be achieved by defining URL Rewrite rules. Refer to Instrumenting a Web Site or Web Application on IIS using URL Rewrite topic for details. On Apache, IBM HTTP, and an Oracle HTTP server, this can be achieved by following the steps detailed in Instrumenting an Apache Web Server Using Container-Assisted Injection, Instrumenting an IBM HTTP Server v9.x (and above) Using Container-Assisted Injection and Instrumenting an Oracle HTTP Server Using Container-based Injection topics. Where load balancers such as NetScaler and F5-Big IP front-end the target web site/web application, follow the procedure detailed in the Instrumenting a Web Site or Web Application Using a NetScaler Rewrite Policytopic and the Instrumenting a Web Application Using an F5 BIG-IP Load Balancer topic respectively to inject the RUM script .

    Note:

    Container-assisted RUM script injection can be used to RUM-enable only those web servers that support the mod_substitute and mod_filter modules. If a web server does not support these modules or supports only one of them, then such web servers cannot be RUM-enabled using the container-based injection method. To RUM-enable such web servers, any of the alternate approaches depicted by Figure 214 should only be used.

  • Adding JavaScript code to common header/footer/include section: If a web site / web application is not hosted on IIS, Apache, or any variants, check whether that web site / application has a common header/footer/include section. If it does, then check if the common section is editable. If so, then do either of the following:

    • Manually insert the JavaScript code into the common header/footer/include section; this way, the JavaScript will get automatically injected into each web page that uses that common header/footer/include section;
    • Manually add the JavaScript code into the application configuration; this is applicable in the case of SharePoint or PeopleSoft applications. In the case of SharePoint, you will have to insert the code in the Master page template of the application. In the case of PeopleSoft, you will have to insert the code in an Application Designer Managed Object. The steps for both the above are detailed in Instrumenting SharePoint and Instrumenting PeopleSoft topics.

    On the other hand, if the common section is not editable, then check whether the target application uses server-side templates to auto-generate the common section. If this is the case, then edit the template code to include the custom API helper class that generates the RUM script. The following helper classes are available: 

    • RUM Library for Java: Only Java-based web sites / web applications can be instrumented using this option. This library includes a specialized egrum.jar, which has to be downloaded and included in the classpath of the target site/application. To download the egrum.jar file, click the Download button alongside egrum.jar in Figure 1.3 above. Once the download is complete, you will have to edit the template code that auto-generates the common section, and add the code block that eG prescribes to that template. To know what code block needs to be inserted in the template, refer to the Instrumenting a Java-based Web Site / Web Application topic. This code block will automatically inject a JavaScript into the common section that is auto-generated from that template. This JavaScript will then be automatically injected into each of the web pages that use that common section. This script will track the requests to that web page, capture the response time metrics of these requests, and send these metrics to the collector. For the detailed procedure, refer to the Instrumenting a Java-based Web Site / Web Application topic.
    • RUM Library for DotNet: Only DotNet-based web sites / web applications can be instrumented using this option. This library includes a specialized Eg_RUM.dll, which has to be downloaded to the target web application’s host, and then included in the target web application via an assembly reference. To download this library, click the Download button alongside Eg_RUM.dll in . Then, you will have to edit the Views\Shared_Layout.cshtml or Default.masterfile and insert the code block described in the Instrumenting a DotNet-based Web Site / Web Application topic in it. This code block will automatically inject a JavaScript into all web pages that use the edited cshtml or master file. This script will track the requests to each of the web pages, capture the response time metrics, and send these metrics to the collector. The detailed procedure for using the Eg_RUM.dll is provided in Instrumenting a DotNet-based Web Site / Web Application topic.
  • Manual JavaScript injection into each web page: Any web site/web application to be monitored, regardless of the underlying development framework (be it Java, .Net, PHP, or others), can be instrumented using this option. This option is ideal in the case of web sites / web applications that does not support common header/footer/include section. In this case, you will just have to copy the JavaScript code-snippet that eG displays in the Include this line… text box in to the <head> tag of every web page that you want to monitor. Every time the web page is hit, the JavaScript runs to collect response time metrics and sends them to the collector. The detailed procedure for inserting the code snippet is provided in the Instrumenting Using the JavaScript Code Snippet topic.
  • Auto-injection of RUM script using eG Java Business Transaction Monitor (BTM): Where container-assisted RUM injection or common header-based RUM injection cannot be performed, administrators are left with the only option of manually inserting the RUM script into every page. If there are hundreds of pages to be RUM-enabled, then manually inserting the RUM script in each page involves a lot of time and effort. To save administrators the time and trouble involved in manual script insertion, eG Enterprise leverages the built-in transaction tracing capability of the eG Java Business Transaction Monitor (BTM) to automatically RUM-enable web pages. To know more about this option and how to perform this, refer to the Auto-injecting the RUM Script topic.