You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Contents

 

CardioLog Analytics Architecture

We recommend installing the CardioLog Analytics application on a dedicated server, and the CardioLog Analytics database on a dedicated SQL Server instance. The CardioLog Analytics application and database can be installed on-premise, on physical servers or virtual machines, or hosted on Microsoft Azure virtual machines (IaaS) which meet the system requirements and with the required ports and permissions.

The following architecture diagrams display a typical implementation of CardioLog Analytics hosted on-premise, or on Microsoft Azure virtual machines (IaaS):

CardioLog Analytics Hosted On-Premise

CardioLog Analytics hosted on Microsoft Azure


When hosting CardioLog Analytics on Microsoft Azure virtual machines (IaaS) and tracking a SharePoint on-premise farm, a site-to-site VPN is required.

CardioLog Analytics System Components

The CardioLog Analytics solution includes the following components:

 

User Interface

A web application for configuring and viewing the web analytics reports.

Database

A repository (SQL database) for storing all tracking and reporting data.

Website Tree Service 

A web service which provides the structure of the monitored website to CardioLog.

Tracking Agent  

A JavaScript tag which is included in all website pages, monitors site usage and personalizes site content. 

Event Collector

A web service which sends tracking data from the tracking agent to the CardioLog database.

CardioLog Scheduling Service 

A Windows service that runs scheduled jobs, including usage data processing, website tree structure syncing and user information syncing.

CardioLog Diagnostics Service

A Windows service used to run regular health checks on the CardioLog system.

 

The CardioLog Scheduling Service includes the following components:

  1. Usage Data Processing - Processes incoming tracking data from the Event Collector every hour.
  2. Portal Tree Updates - Retrieves the structure of the portal (ie., Monitored environments). This is done by creating an XML file which outlines the hierarchical structure of the portal, and then translates the XML data into relational data. This structure is the basis for data aggregations.
  3. Report Scheduling - Responsible for the automatic generation of all scheduled reports, and their distribution and publication.
  4. Active Directory Updates - Retrieves the list of all users and groups directly from Active Directory for use with visitor segmentation and other user targeted features.
  5. User Categories Updates - Retrieves the list of custom user categories from specific designated web services for use with visitor segmentation and other user targeted features.

The Data Collection Process

  1. Download Tracking Code - The JavaScript tracking code is added to SharePoint using the SharePoint feature and is downloaded to the client's browser with each page request.
  2. Personalize Content (Optional) - Information based on visitor segments is downloaded to the client's browser with each page request. The JavaScript code hides the content of the page, adds or modifies relevant page elements and then displays the custom page according to visitor segments.
  3. Track UsageData - Information about user actions on website pages is sent to the CardioLogAgent web application via asynchronous JavaScript calls (AJAX).
  4. Store Usage Data - The CardioLogAgent web application passes on the usage tracking information via HTTP/S web requests to the EventCollector web application, which writes the data into the CardioLog database.
  5. Process Usage Data - The Usage Data Processing service processes incoming tracking data from the EventCollector application. By default, this occurs hourly.
  6. View Usage Data - The processed data is visible in the Report Center and Analysis Center. 

The data collected by CardioLog includes page URL, query string, user name, date and time, browser type, operating system, workstation IP and WFE server IP. Tracking of usage data operates in a non-invasive transparent manner and should not affect the monitored website's overall performance and response time. It is asynchronous to the monitored website's execution and user activity, and therefore has no direct impact on the monitored environment. The product has a marginal footprint on the website and can be turned off instantly should you require any site diagnosis.

 

JavaScript Tracking Code

Website usage tracking is performed by the Tracking Agent, which is a 150KB block of JavaScript code, half which is optional. The code is added to all relevant website pages.

CardioLog Agent File

Bytes Sent

Bytes Received

/CardioLogAgent/AgentEmbed.aspx

/CardioLogAgent/ca.aspx (optional)

/CardioLogAgent/caUser.aspx (optional)

425

391

808

77668

70139

387

/CardioLogAgent/tunnel.aspx

1681

410

The download time for the Tracking Agent JavaScript code is dependent upon multiple factors including network connectivity and band width. Generally, the download time is negligible. The Tracking Agent JavaScript code is loaded on page document ready, and sends usage data to the CardioLog server asynchronously. It can also be loaded on window onload. The calls to the CardioLog server do not affect the page response time. If there is a connection error, the tracking agent tries to reconnect after 60 seconds in order to send usage data. The page will be displayed without modifications, assuming any were available, after 5 seconds of no response. For more information see Tracking Agent Configuration. Intlock encourages each customer to run their own performance tests.

Data Collected by CardioLog Analytics

CardioLog Analytics collects data from various sources, including:

  1. Page tagging: Page URL; query string; date and time; user ID; session ID; browser type and operating system; IP address. 
  2. Active Directory or SharePoint user profiles: User name; email; department; location, etc. (Configurable)
  3. Social Activity from SharePoint or Yammer: Ratings; likes; follows; comments; groups and group activity, etc.
  4. Website tree service: Page ID; URL; title; content type; template; owner; editor; date created; date updated; size; and additional optional meta data fields.
  • No labels