# Value types and metric kinds

In the discussion of the metric model, the section called Metric types provides a general discussion of the attributes that describe a metric type. This section provides a more detailed discussion of two of those attributes:

• Value type
• Metric kind

### Value type

The value type is the data type for the measurements. Each time series records the value type (type `ValueType`) for its data points.

• For measurements consisting of a single value at a time, like boolean values and numeric data, the value type tells you how the data is stored:

• `BOOL`, a boolean
• `INT64`, a 64-bit integer
• `DOUBLE`, a double-precision float
• `STRING`, a string
• For distribution measurements, the value isn't a single value but a group of values. The value type for distribution measurements is `DISTRIBUTION`.

A distribution contains statistics that summarize a group of values. The values in a distribution include the mean, count, max, and other statistics, computed for a group of values. A distribution can also include a histogram that represents how the values are distributed across a set of ranges.

Latency metrics typically capture data as distributions. For more information about distributions, see the `Distribution` reference page. For information about charting these metrics, see Distribution metrics.

### Metric kind

Each time series includes the metric kind (type `MetricKind`) for its data points. The kind of metric data tells you how to interpret the values relative to each other. Cloud Monitoring metrics are one of three kinds:

• A gauge metric, in which the value measures a specific instant in time. For example, metrics measuring CPU utilization are gauge metrics; each point records the CPU utilization at the time of measurement. Another example of a gauge metric is the current temperature.

• A delta metric, in which the value measures the change since it was last recorded. For example, metrics measuring request counts are delta metrics; each value records how many requests were received since the last data point was recorded.

• A cumulative metric, in which the value constantly increases over time. For example, a metric for “sent bytes” might be cumulative; each value records the total number of bytes sent by a service at that time.

### Supported combinations

Not all combinations of metric kind and value type make sense. For example, you never see a delta metric with boolean data. There are certain combinations that make sense together.

The following table lists the supported metric kinds and value types:

Value type GAUGE DELTA CUMULATIVE4
BOOL yes no no
INT64 yes yes1 yes
DOUBLE yes yes1 yes
STRING yes1 no no
DISTRIBUTION yes2 yes1, 3 yes

1 This combination isn't permitted in custom metrics, `custom.googleapis.com`.
2 This combination isn't permitted for logs-based metrics. For more information, see Configure distribution-type logs-based metrics.
3 This is the only combination permitted for logs-based metrics, `logging.googleapis.com/user`, with value type `DISTRIBUTION`; for more information, see the `metricDescriptor` field in the Logging API `LogMetric` reference.
4 Cumulative metrics can't be used directly for charting or alerting in Monitoring, but they can be aggregated into non-cumulative metrics that can be used in these ways. See Kinds, types, and conversions for more information.

Additionally, if you are creating your own metrics, you must use only valid combinations of value types and metric kinds.

#### Emulating string-valued custom metrics

String values in custom metrics are not supported, but you can replicate string-valued metric functionality in the following ways:

• Create a GAUGE metric using an INT64 value as an enum that maps to a string value. Externally translate the enum to a string value when you query the metric.
• Create a GAUGE metric with a BOOL value and a label whose value is one of the strings you want to monitor. Use the boolean to indicate if the value is the active value.

For example, suppose you want to create a string-valued metric called "status" with possible options OK, OFFLINE, or PENDING. You could make a GAUGE metric with a label called `status_value`. Each update would write three time series, one for each `status_value` (OK, OFFLINE, or PENDING), with a value of 1 for "true" or 0 for "false".

[{ "type": "thumb-down", "id": "hardToUnderstand", "label":"Hard to understand" },{ "type": "thumb-down", "id": "incorrectInformationOrSampleCode", "label":"Incorrect information or sample code" },{ "type": "thumb-down", "id": "missingTheInformationSamplesINeed", "label":"Missing the information/samples I need" },{ "type": "thumb-down", "id": "otherDown", "label":"Other" }]
[{ "type": "thumb-up", "id": "easyToUnderstand", "label":"Easy to understand" },{ "type": "thumb-up", "id": "solvedMyProblem", "label":"Solved my problem" },{ "type": "thumb-up", "id": "otherUp", "label":"Other" }]