Network Experience Monitoring

Overview

Citrix Network Experience Monitoring (NEM) service (formerly called Netscope) enables service providers, enterprises, ISPs, and third party service providers to access detailed Radar measurement logs, and standard reports in the form of summarized actionable data. NEM offers several standard logs and reports that customers can use to measure the quality of their services.

This solution includes “raw” Radar Measurement delivery and access to the Citrix ITM Data API. NEM provides both the granular data (as either raw measurements or data aggregates) and data threshold alerts. These services help with discovery, isolate platform availability, and performance issues in platform peers and the underlying ISPs.

Radar “Raw” Measurements: Radar measurements provide per-event granular information that is batched daily. Radar measurements include public community and private measurement data collected by the tag. Data such as availability, response time, throughput for HTTP and HTTPS measurements are included. The following data fields are provided:

  • Provider ID, resolver IP, obfuscated (/28) client IPs
  • Obfuscated referrer header, user agent, end-user ASN
  • Geo data for resolver and client fields

Radar Metrics that are available in the “Raw” Measurements are:

  • Availability, Response Time, and Throughput (when measured)
  • DNS Lookup Time (optional), TCP Connect Time (optional), and Secure Connect Time (optional)
  • Latency (optional)
  • Download Time (optional)

Radar Measurements are available to allow customers to do their own analysis of collected data. The data set includes information on provider performance and availability (errors) for a range of communication protocols.

Log file data is available for 7 days, from an AWS S3 or Google Cloud Storage bucket. Customers can retrieve log files of community and private data using standard bucket access methods.

Real-time Radar “Raw” Measurements (optional): Raw Radar measurements are delivered in real-time to an AWS S3 bucket. These logs are generally available within 5 minutes of collection. They provide as much granularity as the Radar Raw Measurements noted earlier.

Data API: The Citrix ITM Radar data API provides aggregates of the Radar public community and private measurement data. Data is updated continuously, and batched approximately every 60 seconds for retrieval by the API. The data API is provided to allow customers to integrate Radar data into their own reports and dashboards.

Log Sharing and Delivery

  • Radar logs can be delivered real-time and daily.
  • Reports run daily.
  • Results are saved to AWS S3 (S3) or Google Cloud Storage (GCS).
  • Logs and reports both have a 7-day retention period and are automatically deleted one week after creation.
  • Reports are usually in TSV (tab-separated value) or JSON format depending on the type of report.

Customers are given login information to access the S3 and GCS buckets. A command line tool like s3cmd or the AWS CLI for S3 or the gsutil for GCS can be used to log in. The S3cmd config file recognizes the access keys received via the Portal UI and helps the user connect to the S3 bucket.

The AWS CLI needs to be installed in the customer’s computer to connect to S3 and access the logs. For GCS, the customer receives the access key file as a download via the Portal UI which can be used with the gsutil tool. For more information refer to the FAQ.

Customers receive email notifications as and when reports are available.

Platform Settings

You must configure your platform to support and produce the data required for Netscope NEM. Before you start, make sure that the following settings are enabled for your platform:

  • For Anonymous Best reports, enable Radar Probe Settings.
    • For Anonymous Best RTT, enable Response Time, and Availability.
    • For Anonymous Best Throughput, enable Throughput, and Availability.
  • For Cache Node ID reports, enable Radar Probe Settings; and in Advanced Radar Settings, enable Node ID.
  • For Resource Timing Details enable Include Timestamps in Advanced Radar Settings.

From the main menu select Netscope NEM. The Network Experience Monitoring Configuration page opens.

Navigation

Platforms and Networks

Select required Platforms or Networks (or both) to start the configuration process.

NOTE:

Logs and Reports can be configured and generated only if at least one Platform or Network is selected.

The summarized data that the customer receives include Radar measurements of selected Platforms (for all associated networks), or selected Networks (for all associated platform measurements).

Selecting Platforms

For content service providers or enterprises, select platforms such as CDNs, clouds, data centers, or other end-points. Select platforms for which measurements are required.

Platforms

Selecting Networks

For ISPs, select the Networks from the list associated with different platforms or endpoints for which measurements are required.

NOTE:

If you don’t find the required platform on the list, you can configure it in the Platform section of the portal. For unavailable Networks, contact the support team.

Networks

Platform Reports

There are four types of Platform Reports:

  1. Anonymous Best for Round Trip Time (RTT)
  2. Anonymous Best for Throughput
  3. Cache Node ID
  4. Hourly by Country/ASN

For log descriptions go to Radar Log Descriptions and Reports for Service Providers and Enterprises.

Enable Platform Reports

Click the toggle button to enable or disable the reports you want to receive. If you disable an existing report, new logs aren’t generated but old reports stay in the current location.

Platform Reports

Anonymous Best Report for Platforms

  • These reports help providers compare their performance to that of other platforms within their peer group i.e.within the same country, region, or ASN.
  • The performance data of the top 15 providers in the peer group is aggregated based on the same categories. The best is listed next to the specific provider’s best value.
  • Anonymous Best Report for SSL Platforms is available so that their performance can be compared with other SSL platforms.
  • The client IPs are truncated to /28.
  • The results of the “best” provider helps clouds/CDNs focus performance efforts on high volume or business-critical ASNs that are competitively weak to their peers.
  • The report provides details on performance broken down by DNS resolver IP, Client IP /28, and the caching Node that served the objects. The same is compared with the “best” platform for the same criteria.

Available for RTT and Throughput.

Cache Node ID Report for Platforms

  • This report is used to identify the specific server or data center that responded to a request and help diagnose server issues.
  • It provides the ID of the data center or machine that responded to a specific request.
  • It helps to understand why the performance through a specific node (POP or machine, or node ID), was good or bad.
  • The performance consists of response time, throughput, availability (probe type), the DNS resolver IP, Client IP /28, and the caching Node that served the objects.
  • For log descriptions refer to [Radar Log Descriptions and Reports for Service Providers and Enterprises] (#radar-log-descriptions-and-reports-for-service-providers-and-enterprises)

Hourly by Country/ASN

Network Reports

There are three types of Network Reports:

  1. Anonymous Best for Round Trip Time (RTT)
  2. Anonymous Best for Throughput
  3. Subnet

For log descriptions refer to Radar Log Descriptions and Reports for ISPs.

Enable Network Reports

Click the toggle button to enable or disable the reports you want to receive. When disabled, new logs stop generating but old reports are in place. To generate a subnet report, enter the specific subnets of your networks. If there aren’t any subnets entered, reports are generated using the ASN CIDR block as the default subnet.

Network Reports

Anonymous Best Report for ISPs

  • In the Anonymous Best report for ISPs, a peer group is used for the “best” comparison. The peer group is based on the location of the ISP. It’s usually the 10 most measured ISPs in a specified country, with a minimum of over 1,000 sessions.
  • The results of the “best” ISP helps ISPs focus performance efforts on high volume or business-critical Platforms and areas that are competitively weak to their peers.
  • The report provides details on performance broken down by geography and Platform, and compares it with the “best” ISP for the same criteria.
  • Available for RTT and Throughput.
  • For log descriptions refer to Radar Log Descriptions and Reports for ISPs.

Subnet Report for ISPs

  • This report provides ISPs with information on how the specific subnets of their networks are performing for users through the platforms that we measure.
  • It provides information about the service provider that responded to a specific request.
  • It helps to understand the performance by a network subnet.
  • The performance consists of response time, throughput, availability (probe types), the DNS resolver IP, Client IP /28, and the subnet of the user.
  • For log descriptions refer to Radar Log Descriptions and Reports for ISPs.

Radar Logs

  • Radar logs are available for Platforms and Networks.
  • They include a subset of the fields available in the raw logs, with some data anonymized: client IP /28, Referer MD5 hashed.
  • Every measurement taken for public platforms is provided, regardless of the page that generated the measurement.

NOTE:

NEM never exposes full client IPs. Instead, it exposes the /28. For example, an IP of 255.255.255.255 is shown in a report as 255.255.255.240/28.

Log Frequency

Radar Logs can be generated daily (every 24 hours) i.e.end of day, UTC time. Logs can also be generated in real-time (minute by minute).

File Format

Choose TSV or JSON to receive logs and reports in either of these formats.

Measurement Type

You can configure logs for the following measurement types: Availability, Response Time, and Throughput. In the report, 1: Availability, 0: HTTP Response Time, and 14: HTTP Throughput.

Resource Timing Details

You can choose to also include Resource Timing details by clicking the Yes or No buttons.Resource timing details include,

  • DNS Lookup Time
  • TCP Connection Time
  • Secure Connection Time
  • Download Time

For log descriptions refer to Radar Log Descriptions and Reports for Service Providers and Enterprises.

Log Configuration

Log Frequency

Navigation Timing Logs can be generated daily (every 24 hours) that is, end of day, UTC time. Logs can also be generated in real-time (minute by minute).

File Format

Choose TSV or JSON to receive Navigation Timing logs in either of these formats. For log descriptions refer to Navigation Timing Log Descriptions.

Navigation Timing Logs

Openmix Logs

Log Frequency

Openmix logs are generated in real-time (that is, minute by minute). These logs provide real-time measurements taken for Openmix customers.

File Format

Choose TSV or JSON to receive Openmix and HTTP Openmix logs in either of these formats. JSON is however the recommended format.

For log descriptions refer to Openmix Log Descriptions.

Openmix Logs

Cloud Service Delivery

This option allows you to select the mode of delivery. You can choose to receive logs and reports in either the AWS S3 bucket or in the Google Cloud Storage (GCS) bucket. You can access the S3 and GCS buckets with the login information provided and use s3cmd or the AWS CLI for S3. and gsutil command line for GCS.

AWS S3

For logs and reports to be delivered to the AWS S3 bucket, select AWS S3.

Location

The Location represents the bucket in AWS S3 where the logs and reports are saved.

IAM Keys

If you select the Generate Keys button under AWS S3, the AWS IAM Keys (Access and Secret keys) are generated and displayed under IAM Keys. Be sure to record the keys because they aren’t stored anywhere for viewing later.

NOTE:

The pair of access and secret keys are the only copy of the private keys. The customer must store them securely. Regenerating the new keys invalidate the existing ones. The S3cmd config file recognizes the access keys (received via the Portal UI) and helps the customer connect to the S3 bucket. The AWS CLI needs to be installed in the customer’s machine to connect to the S3.

For info on how to use the access and secret keys with s3cmd to download reports from the S3 bucket, refer to the FAQ.

AWS S3

Google Cloud Storage

For logs and reports to be delivered to GCS, select Google Cloud Storage.

Location

The Location represents the bucket in Google Cloud Storage where logs and reports are saved.

IAM Keys

When you select the Generate Key File button, the Google Service Account Key File is downloaded to your machine.

NOTE:

This key file serves as the only copy of the private key. Take note of your service account’s email address and securely store the service account’s private key file. Regenerating a new key file invalidates the existing file.

This Key File can be used with the gsutil tool to download logs and reports from the GCS bucket. For details on how to use the Key File to download log files, refer to the FAQ.

GCS

Radar Log Descriptions and Reports for Service Providers and Enterprises

Radar Logs for Providers

  • These logs provide Radar measurements for benchmark partners.
  • They provide every measurement taken for public platforms, regardless of the page that generated the measurement.
  • Radar logs include a subset of the fields available in the raw logs, with some data anonymized: client IP /28, Referer MD5 hashed.
  • Here is a sample Platform Radar Log Share in TSV file format.

NOTE:

  • NEM never exposes full client IPs. Instead, it exposes the /28. For example, an IP of 255.255.255.255 is shown in a report as 255.255.255.240/28.
  • The client’s GEO information is extracted based on the client’s IPv4 which is more detailed.

Log Descriptions

The following are the columns headers and descriptions for the Radar Logs. The fields appear in the following order in the output files:

Log Description
Timestamp It is the UTC time of the request in YYYY-MM-DDTHH:MI:SSZ format. The actual value (down to the second) in the log tables is rounded to the nearest hour (2018-03-30T23:00:00Z) or day (2018-03-30T00:00:00Z) in the hour/day tables, respectively. Timestamp is always in UTC in all datasets.
Unique Node ID Also known as cache node ID. It’s an arbitrary value. Typically, an IP that the CDN Edge Servers return to help CDNs internally identify which server handled a particular request.’’ (empty string): Comes from Radar clients that do not support UNI detection.0: The user agent does not support the features needed for UNI detection.1: The client encountered an error during UNI detection, such an HTTP 404 or other unsuccessful response.2: UNI detection was attempted but resulted in an error.
Provider ID Internal ID of the platform that is being measured.
Probe Type The probe type being measured (e.g.1: HTTP Connect Time, 0: HTTP Response Time, 14: HTTP Throughput, and so on). To indicate that the service is available, use the information returned successfully within the allowed time.
Response Code Result of the measurement.e.g.0: success, 1: timeout, 4: error. For availability calculations the percent of measurements is taken with a 0 (success) response versus the overall number of measurements (total, regardless of response). For other probe types (RTT and throughput), the filter must only consider RTT data points with a 0 success code when calculating statistics on the RTT. Same for throughput.
Measurement Value The recorded measurement value, the meaning of which varies by probe type. It represents availability (1)/ Response Time (0) measurements in milliseconds, and Throughput (14) in kbps.
Resolver Market The market of the DNS resolver that handled the request. Generally the continent where the DNS resolver is located, where, 0: Unknown (XX), 1:North America (NA) 5: Africa (AF), 3: Europe (EU), 4: Asia (AS), 2: Oceania (OC), 6: South America (SA).
Resolver Country The country of the DNS resolver that handled the request.IDs can be mapped to names at https://community-radar.citrix.com/ref/countries.json.gz
Resolver Region The region of the DNS resolver that handled the request.IDs can be mapped to names at https://community-radar.citrix.com/ref/regions.json.gz Note: Not all the countries of the world have defined regions.
Resolver State The state of the DNS resolver that handled the request.IDs can be mapped to names at https://community-radar.citrix.com/ref/states.json.gz Note: Not all the countries of the world have defined states.
Resolver City The city of the DNS resolver that handled the request.Resolver city is added by looking up a resolver IP address.IDs can be mapped to names at https://community-radar.citrix.com/ref/cities.json.gz
Resolver ASN The Autonomous System Number (ASN) of the DNS resolver that handled the request. Generally the ASN that has the DNS resolver IDs can be mapped to names at https://community-radar.citrix.com/ref/asns.json.gz
Resolver IP The IP address of the DNS resolver from which our infrastructure received the DNS request.
Client Market The market of the end user that generated this measurement. Generally the continent where the client IP is located; where, 0: Unknown (XX), 1:North America (NA) 5: Africa (AF), 3: Europe (EU), 4: Asia (AS), 2: Oceania (OC), 6: South America (SA).
Client Country The country of the end user that generated this measurement.IDs can be mapped to names at https://community-radar.citrix.com/ref/countries.json.gz
Client Region The region of the end user that generated this measurement. Generally the geographic region where the client IP is located.IDs can be mapped to names at https://community-radar.citrix.com/ref/regions.json.gz Note: Not all the countries of the world have defined regions.
Client State The state of the end user that generated this measurement. Generally the state where the client IP is located.IDs can be mapped to names at https://community-radar.citrix.com/ref/states.json.gz Note, that not all the countries of the world have defined states.
Client City The city of the end user that generated this measurement. Generally the city where the client IP is located.IDs can be mapped to names at https://community-radar.citrix.com/ref/cities.json.gz
Client ASN The Autonomous System Number (ASN) of the end user that generated this measurement. Generally the ASN that contains the client IP.IDs can be mapped to names at https://community-radar.citrix.com/ref/asns.json.gz
Client IP The IP of the end user that generated this measurement.
Referer Host MD5 The Referer information (Protocol, Host, and Path) comes from the Referer Header of the HTTP request to Radar. The Referer Host is MD5 hashed.
User Agent It’s the user agent string from the browser page that is hosting the tag. For example, if you use Chrome and browse a page with the Radar tag, the radar measurements in the background records the user agent from your Chrome browser. The measurements include Chrome browser, version of Chrome, information about the OS that Chrome is running on, and so on.
DNS Lookup Time (Optional) With the Resource Timing API, the difference between the Domain Lookup End and the Domain Lookup Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as domainLookupEnd - domainLookupStart.
TCP Connect Time (Optional) With the Resource Timing API, the difference between the Connect End and Connect Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as connectEnd - connectStart.
Secure Connect Time (Optional) With the Resource Timing API, the difference between the Connect End and Secure Connection Start is calculates. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as connectEnd - secureConnectionStart.
Latency (Optional) With the Resource Timing API, the difference between the Response Start and Request Start is calculated. It calculates when both the values aren’t null and the response start-time is greater than the request start-time. It’s calculated as responseStart - requestStart
Download Time (Optional) With the Resource Timing API, the difference between the Response End and Response Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as responseEnd - responseStart.
Client Profile This field helps to identify if the data is coming from mobile apps or browsers. It also allows us to differentiate between iOS, Android apps, and browsers. A number is used to identify each client profile. The values for this field are: null, 0, 1, 2, 3, 4. Where, null: Generally implies an older Radar client that does not support sending the client_profile value. 0: Browser; 1: iOS - Radar runner for iOS app written in Swift; 2: Android; 3: Browser on mobile version of website; 4: iOS - Radar Runner for iOS app written in Objective-C.
Client Profile Version The client profile version tells us what version of the Radar Runner code (for iOS) or AndroidRadar SDK (for Android) was used in the mobile app. This field is intended for internal use only.
Device Category All devices are categorized into one of the following: Smartphone, Tablet, PC, Smart TV, and Other. ‘Other’ is used as the default value if the parser is unable to determine the value for any of the fields.
Device The type of device the user is on, for example an Apple iPhone. The user agent string detects it from the browser running on the page that is hosting the Radar tag.
Browser The type of browser that the user is using, for example Mobile Safari UI/WKWebView 0.0.0. The user agent string detects it from the browser running on the page that is hosting the Radar tag.
OS The operating system used. For example, iOS 11.0.3. the user agent string detects it from the browser running on the page that is hosting the Radar tag.
Reporting Client IP This IP is the masked /48 public IP of the user making the measurement. It can be either IPv4 or IPv6 (when supported).

Anonymous Best Report

  • Anonymous best reports help providers compare their performance to the other platform’s peer group that is, within the same country, region, or ASN.
  • The performance data of the top 15 providers in the peer group is aggregated based on the same categories. The best is listed next to the specific provider’s best value.
  • Anonymous Best Report for SSL platforms is available so that their performance can be compared with other SSL platforms.
  • The client IPs are truncated to /28.
  • The results of the “best” provider helps clouds/CDNs focus performance efforts on high volume or business-critical ASNs that are competitively weak to their peers.
  • The report provides details on performance consists of DNS resolver IP, Client IP /28, and the caching Node that served the objects. It’s compared with the “best” platform for the same criteria.
  • Available for RTT or Throughput.
  • The following is a sample Platform Anonymous Best Report for RTT in TSV file format.

Log Descriptions

The following are the columns headers and descriptions for the Anonymous Best Report. The fields appear in the following order in the output files.

Log Description
Resolver Country The country of the DNS resolver that handled the request.
Resolver Region The region of the DNS resolver that handled the request.
Resolver State The state of the DNS resolver that handled the request.
Resolver ASN ID The Autonomous System Number of the DNS resolver that handled the request. Generally the ASN that has the DNS resolver.
Resolver ASN Name The name of the ASN.
Resolver IP The IP address of the DNS resolver from which our infrastructure received the DNS request.
Client Country The country of the end user that generated this measurement.
Client Region The region of the end user that generated this measurement.
Client State The state of the end user that generated this measurement.
Client ASN ID The Autonomous System Number (ASN) number of the end user that generated this measurement. Generally the ASN that has the client IP.
Client ASN Name The name of the ASN of the end user that generated the measurement.
Client IP The IP of the end user that generated the measurement.
Successes Total number of measurements that were successful.Tip: Success / Total == Availability.
Timeouts The number of measurements that timed out.
Errors The number of measurements that were errors.
Total The total number of measurements.
Mean The average of all the measurements values for that row.
Best Mean The best mean out of the top 15 providers in the peer group.
Best Mean Measurements Total number of measurements that produced the best mean count.
Median The 50th percentile value is the middle value of the measurements for a particular provider, when the measurements are listed in order.
Best Median The best 50th percentile value (below which 50 percent of the measurements is found) of the top 15 providers in the peer group.
Best Median Measurements Total number of measurements that produced the best_median
5th The 5th percentile value for the provider.
Best 5th The best 5th percentile value out of the top 15 providers in the peer group.
Best 5th Measurements Total number of measurements that produced the best_5th
10th The 10th percentile value for the provider.
Best 10th The best 10th percentile value out of the top 15 providers in the peer group.
Best 10th Measurements Total number of measurements that produced the best_10th
90th The 90th percentile value for the provider.
Best 90th The best 90th percentile value out of the top 15 providers in the peer group.
Best 90th Measurements Total number of measurements that produced the best_90th
95th The 95th percentile value for the provider.
Best 95th The best 95th percentile value out of the top 15 providers in the peer group.
Best 95th Measurements Total number of measurements that produced the best_95th
Stdev The standard deviation for the provider
Best Stdev The best standard deviation out of the top 15 providers in the peer group.
Best Stdev Measurements Total number of measurements that produced the best std.dev.
Availability The availability in percentage for the provider. Availability is the probe Success rate i.e.Successes / (Successes + Fails + Timeouts)
Best Availability The best availability value out of the top 15 providers in the peer group.
Best Availability Measurements The number of measurements that produced the best availability
Importance Synthetic values generated to help find actionable data.
Unique Node IDs These IDs are a comma-separated list of the Unique Node IDs for the measurements of that row.
Measurement Type The recorded measurement value, the meaning of which varies by probe type. It’s HTTP_COLD (Availability), HTTP_RTT (Round Trip Time), or HTTP_KBPS (Throughput).
Provider ID The internal NetScaler ITM ID number for that provider.

Cache Node ID Report (previously Multi-Service Provider Report)

This report is used to identify the specific server or data center that responded to a request and help diagnose server issues.

  • It provides the ID of the data center or machine that responded to a specific request.
  • It helps to understand why the performance through a specific node (POP or machine, or node ID), was good or bad.
  • The performance consists of response time, throughput, availability (probe type), the DNS resolver IP, Client IP /28, and the caching Node that served the objects.
  • The following is a sample Platform Cache Node ID Report in TSV file format.

Log Descriptions

The following are the columns headers and descriptions for the Cache Node ID Report. The fields appear in the following order in the output files:

Log Description
Provider Name It’s the name of the provider that is being measured.
Measurement Value The recorded measurement value, the meaning of which varies by probe type. It’s connect (1)/RTT (0) measurements in milliseconds, and throughput (14) measurements in kbps.
Unique Node ID It’s known as cache node ID. An arbitrary value, typically an IP that CDN Edge Servers return to help CDNs internally identify which server handled a particular request.’’ (empty string): Comes from Radar clients that do not support UNI detection.0: The user agent does not support the features needed for UNI detection.1: The client finds an error during UNI detection, such an HTTP 404 or other unsuccessful response.2: UNI detection was attempted but resulted in an error.
Resolver Country The country of the DNS resolver that handled the request.
Resolver Region The region of the DNS resolver that handled the request.
Resolver State The state of the DNS resolver that handled the request.
Resolver ASN The Autonomous System Number of the DNS resolver that handled the request. Generally the ASN that has the DNS resolver.
Resolver ASN Name The name of the ASN.
Resolver IP The IP address of the DNS resolver from which our infrastructure received the DNS request.
Client Country The country of the end user that generated this measurement.
Client Region The region of the end user that generated this measurement.
Client State The state of the end user that generated this measurement.
Client ASN The Autonomous System Number (ASN) number of the end user that generated this measurement. Generally the ASN that has the client IP.
Client ASN Name The name of the ASN of the end user that generated the measurement.
Client IP The IP of the end user that generated the measurement.
Success Total number of measurements that were successful.Tip: Success / Total == Availability.
Timeout The number of measurements that timed out.
Error The number of measurements that were errors.
Total The total number of measurements.
Mean The average of the measurement values for each row.
Median The 50th percentile value is the middle value of the measurements for a particular provider, when the measurements are listed in order.
5th The 5th percentile value for the provider.
10th The 10th percentile value for the provider.
90th The 90th percentile value for the provider.
95th The 95th percentile value for the provider.
Stdev The standard deviation for the provider.
Availability The availability in percentage for the provider.
Importance Synthetic values generated to help find actionable data.

Hourly by Country/ASN Report

  • This report helps to verify if your providers’ performance varies significantly during a day.
  • It shows the time when the measurements were taken truncated down to the hour, for example 2018-03-11T23:00:00.
  • The following is a sample Platform Hourly by Country/ASN Report in TSV file format.

Log Descriptions

The following are the columns headers and descriptions for the Hourly by Country/ASN Report. The fields appear in the following order in the output files:

Log Description
Timestamp 60 minutes The UTC time when the measurements were taken truncated down to the hour, for example2018-03-11T23:00:00.
Provider Name It’s the name of the provider that is being measured.
Measurement Type The recorded measurement value, the meaning of which varies by probe type. It’s HTTP_COLD (Availability), HTTP_RTT (Round Trip Time), or HTTP_KBPS (Throughput).
Client Country The country of the end user that generated this measurement.
Client ASN The Autonomous System Number (ASN) number of the end user that generated this measurement. Generally the ASN that has the client IP.
Client ASN Name The name of the ASN of the end user that generated the measurement.
Success Total number of measurements that were successful.Tip: Success / Total == Availability.
Timeout The number of measurements that timed out.
Error The number of measurements that were errors.
Total The total number of measurements.
Mean The average of the measurement values for each row.
Median The 50th percentile value is the middle value of the measurements for a particular provider, when the measurements are listed in order.
5th The 5th percentile value for the provider.
10th The 10th percentile value for the provider.
90th The 90th percentile value for the provider.
95th The 95th percentile value for the provider.
Stdev The standard deviation for the provider.
Availability The availability in percentage for the provider.
Importance Synthetic value generated to help find actionable data.
Provider ID The internal NetScaler ITM ID number for that provider.

Radar Log Descriptions and Reports for ISPs

Radar Logs for ISPs

Radar logs enable ISPs to measure their performance against global platforms in detail. ISPs can use this data to find areas where improvements must be made or to verify the expected performance.

  • Provides access to Radar measurements.
  • Provides measurements taken from ISPs on public platforms, regardless of the page that generated the measurement.
  • Radar logs include a subset of the fields available in the raw logs, with some data anonymized: client IP /28, referer MD5 hashed.
  • The log files are in TSV format.
  • The following is a sample Network Radar Log Share in TSV file format.

Log Descriptions

The following are the columns headers and descriptions for the Radar logs for ISPs. The fields appear in the following order in the output files.

Log Description
Timestamp It’s the UTC time of the request in YYYY-MM-DDTHH:MI:SSZ format. The actual value (down to the second) in the log tables is rounded to the nearest hour (2018-03-30T23:00:00Z) or day (2018-03-30T00:00:00Z) in the hour/day tables, respectively. The timestamp is always in UTC in all datasets.
Provider ID Internal ID of the platform that is being measured.
Probe Type The probe type being measured (e.g.1: HTTP Connect Time, 0: HTTP Response Time, 14: HTTP Throughput, and so on). The information that it returned successfully within the allowed time is used to indicate that the service is available.
Response Code Result of the measurement.e.g.0: success, 1: timeout, 4: error. For availability calculations the percent of measurements is taken with a 0 (success) response versus The overall number of measurements (total). For other probe types (RTT and throughput), the filter must only consider RTT data points with a 0 success code when calculating statistics on the RTT. Same for throughput.
Measurement Value The recorded measurement value, the meaning of which varies by probe type. It’s availability (1)/ Response Time (0) measurements in milliseconds, and Throughput (14) in kbps.
Resolver Market The market of the DNS resolver that handled the request. Generally the continent where the DNS resolver is located, where, 0: Unknown (XX), 1:North America (NA) 5: Africa (AF), 3: Europe (EU), 4: Asia (AS), 2: Oceania (OC), 6: South America (SA).
Resolver Country The country of the DNS resolver that handled the request IDs can be mapped to names at https://community-radar.citrix.com/ref/countries.json.gz
Resolver Region The region of the DNS resolver that handled the request IDs can be mapped to names at https://community-radar.citrix.com/ref/regions.json.gz. Not all the countries of the world have defined regions.
Resolver State The state of the DNS resolver that handled the request IDs can be mapped to names at https://community-radar.citrix.com/ref/states.json.gz. Not all the countries of the world have defined states.
Resolver ASN The Autonomous System Number (ASN) of the DNS resolver that handled the request. Generally the ASN that has the DNS resolver IDs can be mapped to names at https://community-radar.citrix.com/ref/asns.json.gz.
Resolver IP The IP address of the DNS resolver from which our infrastructure received the DNS request.
Client Market The market of the end user that generated this measurement. Generally the continent where the client IP is located; where, 0: Unknown (XX), 1:North America (NA) 5: Africa (AF), 3: Europe (EU), 4: Asia (AS), 2: Oceania (OC), 6: South America (SA).
Client Country The country of the end user that generated this measurement.IDs can be mapped to names at https://community-radar.citrix.com/ref/countries.json.gz
Client Region The region of the end user that generated this measurement. Generally the geographic region where the client IP is located. IDs can be mapped to names at https://community-radar.citrix.com/ref/regions.json.gz. Not all the countries of the world have defined regions.
Client State The state of the end user that generated this measurement. Generally the state where the client IP is located. IDs can be mapped to names at https://community-radar.citrix.com/ref/states.json.gz. Not all the countries of the world have defined states.
Client ASN The Autonomous System Number (ASN) of the end user that generated this measurement. Generally the ASN that has the client IP. IDs can be mapped to names at https://community-radar.citrix.com/ref/asns.json.gz
Client IP The IP of the end user that generated this measurement.
Referer Host MD5 The Referer information (Protocol, Host, and Path) comes from the Referer Header of the HTTP request to Radar. The Referer Host is MD5 hashed.
User Agent It’s the user agent string from the browser page that is hosting the tag. For example, if you use Chrome and browse a page with the Radar tag, the radar measurements in the background records the user agent from your Chrome browser. The measurements include Chrome browser, version of Chrome, information about the OS that Chrome is running on, and so on.
DNS Lookup Time (Optional) With the Resource Timing API, the difference between the Domain Lookup End and the Domain Lookup Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as domainLookupEnd - domainLookupStart.
TCP Connect Time (Optional) With the Resource Timing API, the difference between the Connect End and Connect Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as connectEnd - connectStart.
Secure Connect Time (Optional) With the Resource Timing API, the difference between the Connect End and Secure Connection Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as connectEnd - secureConnectionStart.
Latency (Optional) With the Resource Timing API, the difference between the Response Start and Request Start is calculated. It calculates when both values aren’t null and the response start time is greater than the request start time. It’s calculated as responseStart - requestStart
Download Time (Optional) With the Resource Timing API, the difference between the Response End and Response Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as responseEnd - responseStart.
Client Profile This field helps to identify if the data is coming from mobile apps or browsers. It also allows us to differentiate between iOS, Android apps, and browsers. A number is used to identify each client profile. The values for this field are: null, 0, 1, 2, 3, 4. Where, null: Generally implies an older Radar client that does not support sending the client_profile value. 0: Browser; 1: iOS - Radar runner for iOS app written in Swift; 2: Android; 3: Browser on mobile version of website; 4: iOS - Radar Runner for iOS app written in Objective-C.
Client Profile Version The client profile version tells us what version of the Radar Runner code (for iOS) or AndroidRadar SDK (for Android) was used in the mobile app. This field is intended for internal use only.
Device Category All devices are categorized into one of the following: Smartphone, Tablet, PC, Smart TV, and Other. ‘Other’ is used as the default value if the parser is unable to determine the value for any of the fields.
Device The type of device the user is on, for example an Apple iPhone. The user agent string detects it from the browser running on the page that is hosting the Radar tag.
Browser The type of browser that the user is using, for example Mobile Safari UI/WKWebView 0.0.0. The user agent string detects it from the browser running on the page that is hosting the Radar tag.
OS The operating system that is being used, for example iOS 11.0.3. The user agent string detects it from the browser running on the page that is hosting the Radar tag.

Subnet Report for ISPs

  • The report provides ISPs with information on how the specific subnets of their networks perform for their users through the measured platforms.
  • It provides information about the service provider that responded to a specific request.
  • It helps to understand the performance by the network subnet.
  • The performance consists of response time, throughput, availability (probe type), the DNS resolver IP, Client IP /28, and the caching Node that served the objects.
  • The following is a sample Network Subnet Report in TSV file format.

Log Descriptions

The following are the columns headers and descriptions for the Subnet Report for ISPs. The fields appear in the following order in the output files:

Log Description
ASN Name The name of the Autonomous System from where the measurement was taken.
Measurement Value The recorded measurement value, the meaning of which varies by probe type. It’s connect (1)/RTT (0) measurements in milliseconds, and throughput (14) measurements in kbps.
Subnet The subnet of the user from where the request originated.
Resolver ASN The Autonomous System Number of the DNS resolver that handled the request. Generally the ASN that has the DNS resolver.
Resolver IP The IP address of the DNS resolver from which our infrastructure received the DNS request.
Client ASN The Autonomous System Number (ASN) number of the end user that generated this measurement. Generally the ASN that has the client IP.
Client IP The IP of the end user that generated the measurement.
Platform ID The ID of the Service Provider platform to which the query was done.
Platform Name The name of the Service Provider platform to which the query was done
Success Total number of measurements that were successful.Tip: Success / Total == Availability.
Timeout The number of measurements that timed out.
Error The number of measurements that were errors.
Total The total number of measurements.
Mean The average of the measurement values for each row.
Median The 50th percentile value is the middle value of the measurements for a particular provider, when the measurements are listed in order.
5th The 5th percentile value for the provider.
10th The 10th percentile value for the provider.
90th The 90th percentile value for the provider.
95th The 95th percentile value for the provider.
Stdev The standard deviation for the provider.
Availability The availability in percentage for the provider.
Importance Synthetic values generated to help find actionable data.
Measurement Type The recorded measurement value, the meaning of which varies by probe type. It’s HTTP_COLD (Availability), HTTP_RTT (Round Trip Time), or HTTP_KBPS (Throughput).

Anonymous Best Report for ISPs

  • In the Anonymous Best report, a peer group is used for the “best” comparison. The peer group is based on the location of the ISP. It’s usually the 10 most measured ISPs in a specified country, with a minimum of over 1,000 sessions.
  • The results of the “best” ISP helps ISPs focus performance efforts on high volume or business-critical platforms and areas that are competitively weak to their peers.
  • The report provides details on performance broken down by geography and Platform, and compares it with the “best” ISP for the same criteria.
  • Available for RTT and Throughput.
  • The following is a sample Network Anonymous Best Report for RTT in TSV file format.

Log Descriptions

The following are the columns headers and descriptions for the Anonymous Best Report. The fields appear in the following order in the output files.

Log Description
Measurement Type The recorded measurement value, the meaning of which varies by probe type. It’s HTTP_COLD (Availability), HTTP_RTT (Round Trip Time), or HTTP_KBPS (Throughput).
Client Country The country of the end user that generated this measurement.
Client Region The region of the end user that generated this measurement.
Client State The state of the end user that generated this measurement.
Client ASN ID The Autonomous System Number (ASN) number of the end user that generated this measurement. Generally the ASN that has the client IP.
Client ASN Name The name of the ASN of the end user that generated the measurement.
Resolver Country The country of the DNS resolver that handled the request.
Resolver Region The region of the DNS resolver that handled the request.
Resolver State The state of the DNS resolver that handled the request.
Platform ID The ID of the Service Provider platform to which the query was attempted.
Platform Name The name of the Service Provider platform to which the query was attempted.
Successes Total number of measurements that were successful.Tip: Success / Total == Availability.
Timeouts The number of measurements that timed out.
Errors The number of measurements that were errors.
Total The total number of measurements.
Mean The average of all the measurements values for that row.
Best Mean The best mean out of the top 15 providers in the peer group.
Best Mean Measurements Total number of measurements that produced the best mean count.
Median The 50th percentile value is the middle value of the measurements for a particular provider, when the measurements are listed in order.
Best Median The best 50th percentile value (below which 50 percent of the measurements is found) of the top 15 providers in the peer group.
Best Median Measurements Total number of measurements that produced the best_median
5th The 5th percentile value for the provider.
Best 5th The best 5th percentile value out of the top 15 providers in the peer group.
Best 5th Measurements Total number of measurements that produced the best_5th
10th The 10th percentile value for the provider.
Best 10th The best 10th percentile value out of the top 15 providers in the peer group.
Best 10th Measurements Total number of measurements that produced the best_10th
90th The 90th percentile value for the provider.
Best 90th The best 90th percentile value out of the top 15 providers in the peer group.
Best 90th Measurements Total number of measurements that produced the best_90th
95th The 95th percentile value for the provider.
Best 95th The best 95th percentile value out of the top 15 providers in the peer group.
Best 95th Measurements Total number of measurements that produced the best_95th
Stdev The standard deviation for the provider.
Best Stdev The best standard deviation out of the top 15 providers in the peer group.
Best Stdev Measurements Total number of measurements that produced the best std.dev.
Availability The availability in percentage for the provider. Availability is the probe Success rate that is, Successes / (Successes + Fails + Timeouts)
Best Availability The best availability value out of the top 15 providers in the peer group.
Best Availability Measurements The number of measurements that produced the best availability.
Importance Synthetic values generated to help find actionable data.

Navigation Timing data provides insights into the various parts of the page load process for a webpage.

This data varies because of the end user’s location, network issues, changes made by the provider, and so on. Customers can use Navigation Timing data to optimize the end user’s experience in loading the monitored webpage.

Measurements can be taken for every Radar session (if enabled). Each session is attached to an ID number that helps track all measurements from a session. These measurements are shared with customers as Navigation Timing Logs via NEM.

The following is a sample of the Navigation Timing Data in TSV file format.

The following are the columns headers and descriptions for Navigation Timing logs. The fields appear in the following order in the output files:

Log Description
Timestamp It’s the UTC time of the request in YYYY-MM-DDTHH:MI:SSZ format. The actual value (down to the second) in the log tables is rounded to the nearest hour (2018-03-30T23:00:00Z) or day (2018-03-30T00:00:00Z) in the hour/day tables, respectively. It’s always in UTC in all datasets.
Response Code Result of the measurement.e.g.0: success, 1: timeout, 4: error. For availability calculations the percent of measurements is taken with a 0 (success) response versus the overall number of measurements (total). For other probe types (RTT and throughput), the filter is to only consider RTT data points with a 0 success code when calculating statistics on the RTT. Same for throughput.
Resolver Market The market of the DNS resolver that handled the request. Generally the continent where the DNS resolver is located, where, 0: Unknown (XX), 1:North America (NA) 5: Africa (AF), 3: Europe (EU), 4: Asia (AS), 2: Oceania (OC), 6: South America (SA).
Resolver Country The country of the DNS resolver that handled the request.IDs can be mapped to names at https://community-radar.citrix.com/ref/countries.json.gz
Resolver Region The region of the DNS resolver that handled the request.IDs can be mapped to names at https://community-radar.citrix.com/ref/regions.json.gz. Not all the countries of the world have defined regions.
Resolver State The state of the DNS resolver that handled the request.IDs can be mapped to names at https://community-radar.citrix.com/ref/states.json.gz. Not all the countries of the world have defined states.
Resolver ASN The Autonomous System Number (ASN) of the DNS resolver that handled the request. Generally the ASN that has the DNS resolver. IDs can be mapped to names at https://community-radar.citrix.com/ref/asns.json.gz
Resolver IP The IP address of the DNS resolver from which our infrastructure received the DNS request.
Client Market The market of the end user that generated this measurement. Generally the continent where the client IP is located; where, 0: Unknown (XX), 1:North America (NA) 5: Africa (AF), 3: Europe (EU), 4: Asia (AS), 2: Oceania (OC), 6: South America (SA).
Client Country The country of the end user that generated this measurement.IDs can be mapped to names at https://community-radar.citrix.com/ref/countries.json.gz
Client Region The region of the end user that generated this measurement. Generally the geographic region where the client IP is located. IDs can be mapped to names at https://community-radar.citrix.com/ref/regions.json.gz. Not all the countries of the world have defined regions.
Client State The state of the end user that generated this measurement. Generally the state where the client IP is located. IDs can be mapped to names at https://community-radar.citrix.com/ref/states.json.gz. Not all the countries of the world have defined states.
Client ASN The Autonomous System Number (ASN) of the end user that generated this measurement. Generally the ASN that has the client IP. IDs can be mapped to names at https://community-radar.citrix.com/ref/asns.json.gz
Client IP The IP of the end user that generated the measurement.
Referer Host The Referer information (Protocol, Host, and Path) comes from the Referer Header of the HTTP request to Radar.
Referer Protocol The Referer information (Protocol, Host, and Path) comes from the Referer Header of the HTTP request to Radar.
Referer Path The Referer information (Protocol, Host, and Path) comes from the Referer Header of the HTTP request to Radar.
Device Category All devices are categorized into one of the following: Smartphone, Tablet, PC, Smart TV, and Other. ‘Other’ is used as the default value if the parser is unable to determine the value for any of the fields.
Device The type of device the user is on, for example an Apple iPhone. The user agent string detects it from the browser running on the page that is hosting the Radar tag.
Browser The type of browser that the user is using, for example Mobile Safari UI/WKWebView 0.0.0. The user agent string detects it from the browser running on the page that is hosting the Radar tag.
OS The operating system that is being used, for example iOS 11.0.3. The user agent string detects it from the browser running on the page that is hosting the Radar tag.
DNS Lookup Time With the Resource Timing API, the difference between the Domain Lookup End and the Domain Lookup Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as domainLookupEnd - domainLookupStart.
TCP Connect Time With the Resource Timing API, the difference between the Connect End and Connect Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as connectEnd - connectStart.
Secure Connect Time With the Resource Timing API, the difference between the Connect End and Secure Connection Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as connectEnd - secureConnectionStart.
Load Event It’s the duration or time taken to go from the start to end of the load event. It’s calculated as LoadEventEnd - LoadEventStart, when both values aren’t null and the end time is greater than the start time.
Redirect It’s the duration or time taken to go from Navigation Start to Fetch Start. It’s calculated as FetchStart - NavigationStart, when both values are not null and the end time is greater than the start time.
Total Page Load It’s the duration or time taken to go from the start of navigation to the end of the page-load event. It’s calculated as - Load Event End - Navigation Start when both values aren’t null and the end time is greater than the start time.
DOM The duration or time taken to go from DOM loading to DOM complete. It’s calculated as DomComplete - DomLoading when both values aren’t null and the end time is greater than the start time.
Latency With the Resource Timing API, the difference between the Response Start and Request Start is calculated. It calculates when both values aren’t null and the response start time is greater than the request start time. It’s calculated as responseStart - requestStart
Download Time With the Resource Timing API, the difference between the Response End and Response Start is calculated. It calculates when both values aren’t null and the end time is greater than the start time. It’s calculated as responseEnd - responseStart.
DOM interactive The duration or time taken to go from Navigation Start to DOM Interactive. It’s calculated as DomInteractive - NavigationStart when both values aren’t null and the end time is greater than the start time.
Start Render The duration or time taken to go from Navigation Start to Start Render. It’s calculated as startRender - NavigationStart when both values aren’t null and the end time is greater than the start time.

Openmix and HTTP Openmix Logs

Openmix and HTTP Openmix logs allow customers to use real-time measurements to monitor the behavior of their Openmix apps. They can use this data to find areas of improvements or to verify the expected performance of their apps.

  • These logs provide real-time measurements taken for Openmix customers.
  • The recommended file format for these logs is JSON, but they’re available in TSV format as well.
  • Here are samples of Openmix and HTTP Openmix log sharing data in TSV file format.

Openmix Log Descriptions

Log Description
Timestamp It’s the UTC time of the request in YYYY-MM-DDTHH:MI:SSZ format. The actual value (down to the second) in the log tables is rounded to the nearest hour (2018-03-30T23:00:00Z) or day (2018-03-30T00:00:00Z) in the hour/day tables, respectively. The timestamp is always in UTC in all datasets.
App Owner Zone ID The zone ID for the application owner servicing the request. This value is always equal to 1.
App Owner Customer ID The customer ID for the application owner who services the request. For HTTP requests, code this ID in the request path and use it to look up which application to run.
App ID The application ID within the customer’s account that services the request. This ID is also coded in the HTTP request path. Application IDs start at 1 and are only unique to the customer. You must fully qualify queries for a specific app ID by querying on the appOwnerCustomerId.
App Version The version of the application that serviced the account. Each time an application is updated via the portal or the API, the version is incremented. The version that was running at the time of the request is recorded. This information can be used to separate versioned logic over time as applications are updated. Hosts throughout the network generally receive updates in a similar timeframe, but almost never at precisely the same moment. It’s likely that overlapping decisions in time uses different versions of an app during the process of update.
App Name The name of the application that serviced the account.
Market The market of the end user that generated this measurement.
Country The country of the end user that generated this measurement.
Region The region of the end user that generated this measurement.
State The state of the end user that generated this measurement.
ASN ID The Autonomous System Number (ASN) of the end user that generated this measurement. Generally the Autonomous System Number that has the client IP.
ASN Name The name of the ASN of the end user that generated the measurement.
Effective IP The effective IP is the IP used to process the request. It’s the query string-specified IP overriding the requesting IP (versus The resolver/ECS/EDNS ID for the DNS flow). It’s the address that the system considers the target when processing the information. This IP is either the IP of the requesting resolver, or the ECS IP address of the client if EDNS ECS is supported. So all probe performance data, geographic information, etc.passed to the application logic is based on this IP.
Resolver Market The market of the DNS resolver that handled the request.
Resolver Country The country of the DNS resolver that handled the request.
Resolver Region The region of the DNS resolver that handled the request.
Resolver State The state of the DNS resolver that handled the request.
Resolver ASN ID The Autonomous System Number (ASN) of the DNS resolver that handled the request. Generally the Autonomous System Number that has the DNS resolver.
Resolver ASN Name The name of the ASN of the resolver that handled the request.
Resolver IP The IP address of the DNS resolver from which our infrastructure received the DNS request.
Decision Provider Name Alias of the platform that an application selects.
Reason Code Reason Code set within the application describing the reason behind the decision.
Reason Log This log is a customer-defined output from the Openmix app. It’s an optional string field that enables customers to log information about their Openmix app decisions.
Fallback Mode This mode indicates whether the app was in fallback mode when it handled the request. Fallback happens when something failed during the preparation of the request for execution.
Used EDNS True if the application uses an EDNS Client Subnet extension.
TTL The TTL (Time To Live) that was handed back.
Response The CNAME returned from the request.
Result The value in this field is always 1.
Context It’s the summary of the Radar data that was available to Openmix when the request was handled. Openmix resolves Radar data relative to the effective values for every request, so two clients making requests at the same time can have different context strings.

Openmix HTTP API Log Descriptions

Log Description
Timestamp It’s the UTC time of the request in YYYY-MM-DDTHH:MI:SSZ format. The actual value (down to the second) in the log tables is rounded to the nearest hour (2018-03-30T23:00:00Z) or day (2018-03-30T00:00:00Z) in the hour/day tables, respectively. The timestamp is always in UTC in all datasets.
App Owner Zone ID The zone ID for the application owner servicing the request. This value is always equal to 1.
App Owner Customer ID The customer ID for the application owner who services the request. For HTTP requests, code this ID in the request path and is used to look up which application to run.
App ID The application ID within the customer’s account who services the request. This ID is also coded in the HTTP request path. Application IDs start at 1 and are only unique to the customer. You must fully qualify queries for a specific app ID by querying on the appOwnerCustomerId.
App Version The version of the application that serviced the account. Each time an application is updated via the portal or the API, the version is incremented. The version that was running at the time of the request is recorded. This information can be used to separate versioned logic over time as applications are updated. Hosts throughout the network generally receive updates in a similar timeframe, but almost never at precisely the same moment. It’s likely that overlapping decisions in time uses different versions of an app during the process of update.
App Name The name of the application that serviced the account.
Market The market of the end user that generated this measurement.
Country The country of the end user that generated this measurement.
Region The region of the end user that generated this measurement.
State The state of the end user that generated this measurement.
ASN ID The ID of the Autonomous System Number (ASN) of the end user that generated this measurement that is, the network ID number associated with the ASN Name
ASN Name The name of the ASN of the end user that generated the measurement.
Effective IP The effective IP is the IP used to process the request. It’s the query string-specified IP overriding the requesting IP (versus The resolver/ECS/EDNS ID for the DNS flow). It’s the address that the system considers the target when processing the information. This IP is either the IP of the requesting resolver, or the ECS IP address of the client if EDNS ECS is supported. All probe-performance data, geographic information, and so on, passed to the application logic is based on this IP.
Decision Provider Name Alias of the platform that an application selects.
Reason Code Reason Code set within the application describing the reason behind the decision.
Reason Log This log is a customer-defined output from the Openmix app. It’s an optional string field that enables customers to log information about their Openmix app decisions.
Fallback Mode This mode indicates whether the app was in fallback mode when it handled the request. Fallback happens when something failed during the preparation of the request for execution.
Response Code Result of the measurement.e.g.0: success, 1: timeout, 4: error. For availability calculations the percent of measurements is taken with a 0 (success) response versus The overall number of measurements (total, regardless of response). For other probe types (RTT and throughput), the filter must only consider RTT data points with a 0 success code when calculating statistics on the RTT. Same for throughput.
HTTP Method The HTTP method (GET/POST/OPTIONS/etc) relates to the request that was made to the HTTP Openmix server from a customer service. Together these methods make up portions of the URL inbound and the HTTP responses outbound.
URI It’s the request path. If customers aren’t getting the behavior they want, it can be because of an improperly structured request. The logs show what our servers are receiving (Protocol, Host, and Path). The Referer information (Protocol, Host, and Path) comes from the Referer Header of the HTTP request to Radar. For HTTP OPX the whole Referer (protocol, host, and path) is included in one string labeled Referer.
User Agent It’s the user agent string from the browser page that is hosting the tag. For example, if you use Chrome and browse a page with the Radar tag, the radar measurements in the background records the user agent from your Chrome browser. The measurements include Chrome browser, version of Chrome, information about the OS that Chrome is running on, and so on.
Context It’s the summary of the Radar data that was available to Openmix when the request was handled. Openmix resolves Radar data relative to the effective values for every request, so two clients making requests at the same time can have different context strings.

Custom Reports for Third Party Organizations

Customers can work with NetScaler to get custom reports based on Radar data that NetScaler collects. NetScaler can generate reports to run on a schedule. The reports are available as data files, usually in TSV format.

FAQ

Radar

How frequently are files pushed to S3 and GCS?

The frequency of file deposits is once a minute for Radar and daily for reports.

Where are the reports stored?

S3 Legacy (Location 1):

s3://public-radar/[customer name]/

S3 (Location 2):

s3://cedexis-netscope/[customer id]/

GCS (Location 3):

gs://cedexis-netscope-[customer id]/

How to get S3 access credentials if you don’t have them already?

The portal provides an ‘Access’ and ‘Secret’ key. Use the keys with ‘s3cmd’, ‘awscli’ or other tools to access S3. For Google Storage, the Portal downloads a file with access credentials to use with the ‘gsutil’ tool.

How to use the access and secret keys with s3cmd to download logs and reports from the S3 bucket?

First you would need to download and install the s3cmd from https://s3tools.org/download, and refer to https://s3tools.org/usage for usage, options, and commands. Then run the following command:

s3cmd --access_key=[access key] --secret_key=[secret key] ls s3://cedexis-netscope/<customer id>/radar/
<!--NeedCopy-->

To download the files, run the following command:

s3cmd --access_key=[access_key] --secret_key=[secret_key] get s3://cedexis-netscope/<customer id>/radar/[the_filename_to_download] [the_name_of_the_local_file]
<!--NeedCopy-->

How to use the s3cmd config to list files in the S3 bucket

The first step is to Install s3cmd. You can install it from http://s3tools.org/download

To configure s3cmd, run the following command

s3cmd ls s3://cedexis-netscope/[customer id]/
<!--NeedCopy-->

If you’re already using s3cmd with another set of access and secret keys, then follow these steps:

If you already use s3cmd, then make a copy of the default config, at ~/.s3cfg. For example, make a copy and name it as ~/.s3cfg_netscope. Replace the access and secret key entries in ~/.s3cfg_netscope with the ones that we provide. Use the new configuration instead of the default one (your company’s) to access the S3 bucket with the following command:

s3cmd -c ~/.s3cfg_netscope ls s3://cedexis-netscope/[customer id]/
<!--NeedCopy-->

The main difference is you have to put in a -c and where the config file is with the Citrix-provided access and secret keys.

If you want to switch between sets of keys, embed them in a file. Refer to the file with the -c option to specify which key pair you’re using.

NOTE: -c parameter indicates where the config file, that contains the access and secret keys, is located.

How to use the Key File with gsutil or gcloud to download log files

Once you download the google service account JSON Key File, you can use it to authenticate your google account credentials, view, or download your log files. For example, here’s one way to do that using the google gcloud and gsutil command line utilities:

Step 1: Activate the Key File

The authenticating commands gcloud auth activate- or gsutil config -e are required to authenticate the key file for running gcloud or gsutil commands.

For gcloud:

Run the following command using the downloaded Key File:

gcloud auth activate-service-account --key-file [downloaded config file]
<!--NeedCopy-->

Or

gcloud auth activate-service-account --key-file=[path and file name of key file]
<!--NeedCopy-->

For gsutil:

Run the following command using the downloaded config file:

gsutil config -e
<!--NeedCopy-->

Step 2: List the files in the GCS (Google Cloud Storage) Bucket

Once you’ve activated the service account key file as described in the earlier step, use the following command to list the files in the GCS bucket:

gsutil ls gs://cedexis-netscope-<customer id>
<!--NeedCopy-->

Step 3 (if necessary): Restore original credentials (or switch back and forth between accounts)

You can switch between the NetScaler ITM account and other Google Cloud credentials you’ve authenticated by doing the following.

First, run the following command to list all your accounts:

gcloud auth list
<!--NeedCopy-->

Then use the following command to switch to another account:

gcloud config set account [email of the account to switch to as shown in gcloud auth list]
<!--NeedCopy-->

You can switch back and forth between accounts using the same command, by replacing the email with the account email that you want to switch to.

What does the file name look like?

Legacy Daily:

The Radar daily log ShareFile names have this structure:

<prefix><date: YYYY-MM-DD>.<customer_id>.part<uniq_id>.kr.txt.gz

For example Cedexis_Daily-2017-11-07.21222.part-cc901e1dd55eal4e.kr.txt.gz (non-standard example)

Legacy Real-time:

The Radar real-time log ShareFile names have this structure:

<prefix><customer_id>-YYYY-MM-DDTHH:MM<uniq_id>.txt.gz

For example Cedexis_3-32291-2017-11-08T20:56-cc907e8fd71eaf4e.txt.gz

Netscope NEM Format:

The Netscope NEM format for daily and real-time log share files have this structure:

<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz

Where,

  • freq: "daily" | "rt" | "hr"
  • log_type: "radar" | "opx" | "hopx"
  • prefix: log_share.prefix
  • id_type: "customer" | "provider" | "asn"
  • id: log_share.match_id
  • iso_dt: iso 8601 Date_time "YYYYMMDDTHHMMSSZ"
  • uniq_id: hash(UUID)
  • line_format: "tsv" | "json"

For example rt-radar-TestRadar1-provider-20363-20171209183034Z-cc907e8fd71eaf4e.tsv.gz

What is the format of the output file?

For Radar, the output file format is TSV (tab-separated value), gzipped.

Openmix and Openmix HTTP API

How frequently are files pushed to S3?

The frequency of file deposits is once a minute for Openmix and HTTP Openmix.

What if you’re unable to see the option to configure Openmix and Openmix HTTP API real time log sharing?

Your Account Manager can enable the required role for you to configure and enable Openmix and Openmix HTTP API real time log sharing.

How do you turn on Openmix and an Openmix HTTP API real time log sharing and access files?

Once the role is enabled on your account, you see the Manage Logs icon. Click to open the Logs dialog where you can access Openmix Log Configuration settings. These settings are basically all you need to turn on Openmix and HTTP Openmix real time log-sharing and access files.

Openmix log configuration

What is the back-end process?

Turning on Openmix log sharing enables Openmix HTTP API log sharing as well. The Openmix and Openmix HTTP API log-sharing services must start outputting logs for the customer within 10 minutes.

Where are the Openmix and HTTP Openmix reports stored?

S3 Legacy (Location 1):

s3://logshare/[zone ID]/[customer ID]/logs/openmix/json/[YYYY]/[MM]/[DD]/[HH]/.

S3 (Location 2):

s3://cedexis-netscope/[customer id]/

GCS (Location 3):

gs://cedexis-netscope-[customer id]/

What does the file name look like?

The file name structure for Openmix and HTTP Openmix typically looks like this:

Legacy Real-time:

[zone ID, 1][customerID]-openmix-json[YYYY][MM][DD][HH][mm][ss]Z-m1-w9-c0.gz

Netscope NEM Format:

The Netscope NEM format for daily and real-time log share files have this structure:

<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz

Where,

  • freq: "daily" | "rt" | "hr"
  • log_type: "radar" | "opx" | "hopx"
  • prefix: log_share.prefix
  • id_type: "customer" | "provider" | "asn"
  • idv: log_share.match_id
  • iso_dt: iso 8601 Date_time "YYYYMMDDTHHMMSSZ"
  • uniq_id: hash(UUID)
  • line_format: "tsv" | "json"

For example hr-opx-TestOpenmix1-provider-20363-20171209183034Z-cc907e8fd71eaf4e.tsv.gz

What is the output file format?

The file format for Openmix and an Openmix HTTP API is JSON (gzipped).