A Guide to NetScaler Metrics

A metric is a quantifiable measure used to assess and monitor the performance and quality of a system. Metrics such as latency, throughput, packet loss, and response times etc are crucial for assessing health and performance of a network. Metrics are vital because they help identify potential bottlenecks, security vulnerabilities, and performance issues, enabling IT teams to quickly address problems before they impact users. In today’s technology landscape, where the reliability and performance of applications are paramount, metrics serve as the backbone for proactive management, optimization, and protection, ensuring seamless and secure user experiences.

NetScaler offers an extensive range of metrics, making it a powerful tool for monitoring and optimizing application performance. These metrics provide deep insights into various aspects of system behavior, from network traffic patterns to application response times, and security posture. By leveraging this vast array of data, organizations can fine-tune their infrastructure to enhance speed, reliability, and security. 

Metrics Schema

NetScaler uses schema files to manage metrics that are reported to observability platforms such as Splunk and Prometheus. When an analytics profile is created it requires a schema file as input. Only the metrics included in the schema are reported. A metric in the schema file is defined as a JSON object and has 2 attributes: “name” and “rate”.

Name: Name of the counter.

Rate: Report the rate for the counter. This will be explained further in the article.

Below is a sample JSON object for a metric.

Metrics for different NetScaler entity types such as Vservers, services, backend servers, service groups, application firewall etc. are consolidated under an JSON array.

Here is an example that lists 5 metrics for the “server_vip” entity type.

Different such entities and their corresponding metrics can be added together to create a schema file. There are two schema files “schema.json” and “reference_schema.json” that are present by default on a NetScaler ADC.

• schema.json: This is the default schema file that is used when an analytics profile is created. It contains a number of commonly used metrics that have been identified after consultation with multiple users.

• reference_schema.json: This file serves as a reference template and contains all the metrics that NetScaler supports. The metric can be copied from this file to the desired schema file used in the analytics profile

 Note:

1. The reference schema file can contain distinct sub-objects for entities of the same type. Metrics taken from these sub objects should be coalesced into a single sub object of that type in the schema file. For example:

The entity “netscaler” is defined multiple times in the reference schema. Each definition contains metrics of different sub-objects of “netscaler” entities. When adding these metrics in the schema file, ensure that there is a single “netscaler” entity in the schema file. The metrics of different sub-objects of “netscaler” entities should be merged under this single “netscaler” entity.

2. Validate the schema file by passing through a JSON parser before use. Ensure that the metric name is correct. If the name of the metric is incorrect, the metrics of that whole entity is not reported.
3. When a new metric is added to a schema file that is being referred to in an analytics profile, then disable and enable the metrics profile for the change to take effect.

Rate of a Metric

Numeric metrics such as si_tot_RequestBytes (total number of request bytes) or si_tot_1xx_resp (total number of http 1xx responses) etc can be reported as an absolute value and also as a rate. Any metrics for which NetScaler can calculate rate has the “rate” attribute set to “True” in the reference schema. When a metric object that supports rate calculation is added to the schema file, one can set the rate attribute to either True or False. If the “rate” attribute is set to True, then NetScaler will report both absolute value and the rate of that metric. If the “rate” attribute is set to “False” then NetScaler will only report the absolute value of the metric.

The rate of a metric is reported with the string “RATE__” string prepended to the name of the metric.  For example, consider the metric si_tot_1xx_resp. Its absolute value is reported as si_tot_1xx_resp and its rate as RATE__si_tot_1xx_resp.

It is at the discretion of the Admin whether they want the rate to be calculated and reported by NetScaler or want to use the monitoring tools to calculate the rate of the metric from the absolute value.

Note

1. Since only the numeric metrics support rate calculation, if the rate attribute is set to “true” for metrics that don't support rate calculation, the rate for that metrics is reported as 0.

Additional Notes

• If certain features are disabled but the metrics for those features are added to the schema file, then those metrics are reported as 0.
• If certain features are enabled and then disabled, then the metrics for those features remain at the last reported values. But the rate (if enabled) for those metrics are reported as 0.
• Metrics are available at a granularity interval of 30 seconds.

Refer to the below resources more information on NetScaler metics and observability integrations:

• https://www.youtube.com/watch?v=ZoYEzlZbHaQ&t=4s
• https://docs.netscaler.com/en-us/citrix-adc/current-release/observability.html