[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-28。"],[],[],null,["# About ratios of metrics\n\nThis document helps you choose the best approach to chart or monitor a ratio\nof metric data. It also includes links to examples,\nidentifies when you can compute ratios,\nand describes anomalies that you might see when charting a ratio of two\ndifferent metrics. These anomalies are due to differences in the sampling rate\nor alignment parameters.\n\nRatios let you transform your metric data into a different, and potentially\nmore useful, form. For example, consider a\nmetric type that counts the number of HTTP responses by\nresponse code. The metric data reports the number of errors,\nbut not the proportion of requests that failed. However,\nperformance requirements are often specified as a percentage, like\n\"The error rate must be less than 0.1%\". To determine the error rate\nby using the metric data, you compute the ratio of the requests that failed\nto the total number of requests.\n\nBest practices\n--------------\n\nTo monitor or chart a ratio of metric data, we recommend that you use\n[PromQL](/monitoring/promql). You can use PromQL with the\nCloud Monitoring API and with the Google Cloud console.\nThe Google Cloud console includes a code editor that\nprovides suggestions, error detection, and other support for creating valid\nPromQL queries.\n\nTo create an alerting policy that monitors a ratio of metrics when you\naren't familiar with PromQL, use the Cloud Monitoring API and include a\n[time-series filter](/monitoring/api/v3/filters). For an example, see\n[Metric ratio](/monitoring/alerts/policies-in-json#json-ratio).\n\nTo chart a ratio of metric data when you aren't familiar with PromQL,\nwe recommend that you use the Google Cloud console\nand that you use a menu-driven interface.\nFor detailed instructions see,\n[Chart a ratio of metrics](/monitoring/charts/metrics-explorer#chart-ratio) and\n[Add charts and tables to a custom dashboard](/monitoring/charts).\n\nRestrictions with ratios\n------------------------\n\nWhen you configure a ratio, the following restrictions apply:\n\n- After aggregation, the labels in the denominator time series must be the\n same as, or a subset of, the labels in the numerator time series.\n\n We recommend that you select aggregation options such that after\n aggregation, the numerator and the denominator time series have the same\n labels.\n\n Consider a configuration where the numerator time series has `method`,\n `quota_metric`, and `project_id` labels. The denominator time\n series has `limit_name`, `quota_metric` and`project_id` labels.\n The valid choices for the denominator grouping depend on the selections for\n the numerator:\n - Numerator grouped by the `method` label: Combine the denominator time series into a single time series. No other grouping results in the labels for the denominator time series being a subset of the labels for the numerator time series.\n - Numerator grouped by the `quota_metric` label: Group the denominator by that label or combine all time series in the denominator into a single time series.\n - Numerator grouped by the `quota_metric` and `project_id` labels: Group the denominator by both labels, by one label, or combine the denominator time series into a single time series.\n\n The valid denominator aggregation options always eliminate the `limit_name`\n label from the grouped time series because that\n label isn't present in the numerator time series.\n- The alignment period must be the same for the numerator and the denominator\n when configuring a chart by using the Google Cloud console;\n however, these fields can be different when using the Cloud Monitoring API.\n\n We recommend that you use the same alignment period for the numerator and\n the denominator regardless of the tool you use to create to the chart.\n- The numerator and denominator must have the same\n [value type](/monitoring/api/v3/kinds-and-types).\n For example, when the numerator is of type `DOUBLE`, the denominator\n must also be of type `DOUBLE`.\n\n Ratios requires that the numerator and denominator metric have a value\n type of `DOUBLE` or `INT64`.\n- The aligned time series for the numerator and the denominator must have the\n same [metric kind](/monitoring/api/v3/kinds-and-types). When the two metrics have\n different kinds, you must use aligners to convert them to the same kind.\n\n Consider a configuration where a `DELTA` metric is selected for the\n numerator and a `GAUGE` metric is selected for the denominator.\n In this situation, use the rate aligner, `ALIGN_RATE`,\n to convert the `DELTA` metric to a `GAUGE` metric. For an example, see\n [Ratio alerting policies on usage of rate quota for one limit](/monitoring/alerts/using-quota-metrics#mql-rate-one-limit).\n- For ratios that aren't defined with PromQL, the monitored resource type\n must be the same for the numerator and the denominator.\n\n For example, if the resource for the numerator metric\n is Compute Engine instances, then the resource for the denominator metric\n must also be Compute Engine instances.\n\nAnomalies due to sampling and alignment mismatches\n--------------------------------------------------\n\nIn general, it is best to compute ratios based on time series collected for\na single metric type, by using label values. A ratio computed over two\ndifferent metric types is subject to anomalies due to different sampling\nperiods and alignment windows.\n\nFor example, suppose that you have two different metric types, an RPC total\ncount and an RPC error count, and you want to compute the ratio of error-count\nRPCs over total RPCs. The unsuccessful RPCs are counted in the time series of\nboth metric types. Therefore, there is a chance that, when you align the time\nseries, an unsuccessful RPC doesn't appear in the same alignment interval for\nboth time series. This difference\ncan happen for several reasons, including the following:\n\n- Because there are two different time series recording the same event, there are two underlying counter values implementing the collection, and they aren't updated atomically.\n- The sampling rates might differ. When the time series are aligned to a common period, the counts for a single event might appear in adjacent alignment intervals in the time series for the different metrics.\n\nThe difference in the number of values in corresponding alignment intervals can\nlead to nonsensical `error/total` ratio values like 1/0 or 2/1.\n\nRatios of larger numbers are less likely to result in nonsensical values.\nYou can get larger numbers by aggregation, either by using an alignment window\nthat is\nlonger than the sampling period, or by grouping data for certain\nlabels. These techniques minimize the effect of small differences in the\nnumber of points in a given interval. That is, a two-point disparity is more\nsignificant when the expected number of points in an interval is 3 than when\nthe expected number is 300.\n\nIf you are using built-in metric types, then you might have no choice but to\ncompute ratios across metric types to get the value you need.\n\nIf you are designing custom metrics that might count the same thing---like\nRPCs returning error status---in two different metrics, consider instead\na single metric, which includes each count only once. For example, suppose\nthat you are counting RPCs and you want to track the ratio of unsuccessful\nRPCs to all RPCs. To solve this problem,\ncreate a single metric type to count RPCs, and use a label to record the\nstatus of the invocation, including the \"OK\" status. Then each status value,\nerror or \"OK\", is recorded by updating a single counter for that case.\n\nWhat's next\n-----------\n\n- For information about using PromQL to configure alerting\n policies, see [PromQL alerting overview](/monitoring/promql/promql-in-alerting).\n\n- For information about creating charts, see the following documents:\n\n - To create temporary charts, see [Metrics Explorer](/monitoring/charts/metrics-explorer).\n - To add charts to a dashboard by using the Google Cloud console, see [Add charts and tables to a custom dashboard](/monitoring/charts).\n - To manage charts by using the Cloud Monitoring API, see [Create and manage dashboards by API](/monitoring/dashboards/api-dashboard)."]]
