[role="xpack"] [[ml-metric-functions]] === Metric functions The metric functions include functions such as mean, min and max. These values are calculated for each bucket. Field values that cannot be converted to double precision floating point numbers are ignored. The {xpackml} features include the following metric functions: * <> * <> * xref:ml-metric-median[`median`, `high_median`, `low_median`] * xref:ml-metric-mean[`mean`, `high_mean`, `low_mean`] * <> * xref:ml-metric-varp[`varp`, `high_varp`, `low_varp`] [float] [[ml-metric-min]] ==== Min The `min` function detects anomalies in the arithmetic minimum of a value. The minimum value is calculated for each bucket. High- and low-sided functions are not applicable. This function supports the following properties: * `field_name` (required) * `by_field_name` (optional) * `over_field_name` (optional) * `partition_field_name` (optional) For more information about those properties, see {ref}/ml-job-resource.html#ml-detectorconfig[Detector Configuration Objects]. .Example 1: Analyzing minimum transactions with the min function [source,js] -------------------------------------------------- { "function" : "min", "field_name" : "amt", "by_field_name" : "product" } -------------------------------------------------- // NOTCONSOLE If you use this `min` function in a detector in your job, it detects where the smallest transaction is lower than previously observed. You can use this function to detect items for sale at unintentionally low prices due to data entry mistakes. It models the minimum amount for each product over time. [float] [[ml-metric-max]] ==== Max The `max` function detects anomalies in the arithmetic maximum of a value. The maximum value is calculated for each bucket. High- and low-sided functions are not applicable. This function supports the following properties: * `field_name` (required) * `by_field_name` (optional) * `over_field_name` (optional) * `partition_field_name` (optional) For more information about those properties, see {ref}/ml-job-resource.html#ml-detectorconfig[Detector Configuration Objects]. .Example 2: Analyzing maximum response times with the max function [source,js] -------------------------------------------------- { "function" : "max", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `max` function in a detector in your job, it detects where the longest `responsetime` is longer than previously observed. You can use this function to detect applications that have `responsetime` values that are unusually lengthy. It models the maximum `responsetime` for each application over time and detects when the longest `responsetime` is unusually long compared to previous applications. .Example 3: Two detectors with max and high_mean functions [source,js] -------------------------------------------------- { "function" : "max", "field_name" : "responsetime", "by_field_name" : "application" }, { "function" : "high_mean", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE The analysis in the previous example can be performed alongside `high_mean` functions by application. By combining detectors and using the same influencer this job can detect both unusually long individual response times and average response times for each bucket. [float] [[ml-metric-median]] ==== Median, high_median, low_median The `median` function detects anomalies in the statistical median of a value. The median value is calculated for each bucket. If you want to monitor unusually high median values, use the `high_median` function. If you are just interested in unusually low median values, use the `low_median` function. These functions support the following properties: * `field_name` (required) * `by_field_name` (optional) * `over_field_name` (optional) * `partition_field_name` (optional) For more information about those properties, see {ref}/ml-job-resource.html#ml-detectorconfig[Detector Configuration Objects]. .Example 4: Analyzing response times with the median function [source,js] -------------------------------------------------- { "function" : "median", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `median` function in a detector in your job, it models the median `responsetime` for each application over time. It detects when the median `responsetime` is unusual compared to previous `responsetime` values. [float] [[ml-metric-mean]] ==== Mean, high_mean, low_mean The `mean` function detects anomalies in the arithmetic mean of a value. The mean value is calculated for each bucket. If you want to monitor unusually high average values, use the `high_mean` function. If you are just interested in unusually low average values, use the `low_mean` function. These functions support the following properties: * `field_name` (required) * `by_field_name` (optional) * `over_field_name` (optional) * `partition_field_name` (optional) For more information about those properties, see {ref}/ml-job-resource.html#ml-detectorconfig[Detector Configuration Objects]. .Example 5: Analyzing response times with the mean function [source,js] -------------------------------------------------- { "function" : "mean", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `mean` function in a detector in your job, it models the mean `responsetime` for each application over time. It detects when the mean `responsetime` is unusual compared to previous `responsetime` values. .Example 6: Analyzing response times with the high_mean function [source,js] -------------------------------------------------- { "function" : "high_mean", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `high_mean` function in a detector in your job, it models the mean `responsetime` for each application over time. It detects when the mean `responsetime` is unusually high compared to previous `responsetime` values. .Example 7: Analyzing response times with the low_mean function [source,js] -------------------------------------------------- { "function" : "low_mean", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `low_mean` function in a detector in your job, it models the mean `responsetime` for each application over time. It detects when the mean `responsetime` is unusually low compared to previous `responsetime` values. [float] [[ml-metric-metric]] ==== Metric The `metric` function combines `min`, `max`, and `mean` functions. You can use it as a shorthand for a combined analysis. If you do not specify a function in a detector, this is the default function. //TBD: Is that default behavior still true? High- and low-sided functions are not applicable. You cannot use this function when a `summary_count_field_name` is specified. This function supports the following properties: * `field_name` (required) * `by_field_name` (optional) * `over_field_name` (optional) * `partition_field_name` (optional) For more information about those properties, see {ref}/ml-job-resource.html#ml-detectorconfig[Detector Configuration Objects]. .Example 8: Analyzing response times with the metric function [source,js] -------------------------------------------------- { "function" : "metric", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `metric` function in a detector in your job, it models the mean, min, and max `responsetime` for each application over time. It detects when the mean, min, or max `responsetime` is unusual compared to previous `responsetime` values. [float] [[ml-metric-varp]] ==== Varp, high_varp, low_varp The `varp` function detects anomalies in the variance of a value which is a measure of the variability and spread in the data. If you want to monitor unusually high variance, use the `high_varp` function. If you are just interested in unusually low variance, use the `low_varp` function. These functions support the following properties: * `field_name` (required) * `by_field_name` (optional) * `over_field_name` (optional) * `partition_field_name` (optional) For more information about those properties, see {ref}/ml-job-resource.html#ml-detectorconfig[Detector Configuration Objects]. .Example 9: Analyzing response times with the varp function [source,js] -------------------------------------------------- { "function" : "varp", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `varp` function in a detector in your job, it models the variance in values of `responsetime` for each application over time. It detects when the variance in `responsetime` is unusual compared to past application behavior. .Example 10: Analyzing response times with the high_varp function [source,js] -------------------------------------------------- { "function" : "high_varp", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `high_varp` function in a detector in your job, it models the variance in values of `responsetime` for each application over time. It detects when the variance in `responsetime` is unusual compared to past application behavior. .Example 11: Analyzing response times with the low_varp function [source,js] -------------------------------------------------- { "function" : "low_varp", "field_name" : "responsetime", "by_field_name" : "application" } -------------------------------------------------- // NOTCONSOLE If you use this `low_varp` function in a detector in your job, it models the variance in values of `responsetime` for each application over time. It detects when the variance in `responsetime` is unusual compared to past application behavior.