Metric Metadata 🔗

SignalFx’s multidimensional data model makes extensive use of metadata to let you find, filter, and aggregate the metrics that you want to chart or alert on. For example, you can:

Search for metrics by using associated metadata, irrespective of whether you know the name of the metric. For example, if you have a number of metrics coming from your login service and have associated them with the key:value pair of service:login, you can find the metrics by searching for either “login” or “service”.
Filter metric time series, charts, detectors, and other objects using the metadata associated with them. For instance, if you are looking at the Infrastructure Navigator or a built-in dashboard for your Amazon EC2 instances, you can filter it down to look only at a particular availability zone (e.g. US-East-1a) by applying the filter aws_availability_zone:us-east-1a. (SignalFx also generally supports Boolean and, or, and not operations for filters.)
Group the output of an analytics computation by metadata values when building a chart or detector. For example, if you have a metric jvm.cpu.load that is being sent to SignalFx from each host, but want to see the 90th percentile of jvm.cpu.load by cluster rather than by individual host, in the percentile computation, you would specify “cluster” as the group‑by variable.

This data model also means that all of your charts, dashboards, and detectors are data-driven. In other words, you can think of the charts, dashboards, and detectors as prebuilt visualizations or computations that you apply to your data. This model enables the following use cases:

Easy monitoring of autoscaling infrastructure. In an autoscaled, elastic, or ephemeral environment, the virtual machines or containers underlying your applications may come and go. When you monitor them, you want to include them in a chart or detector based on the application or service that they provide, rather than by something associated with the individual VM or container. This is easily accomplished through the use of metrics metadata.
Efficient creation of default dashboards or alerts for large environments. Instead of creating a similar dashboard for each (development, staging, and production), you can simply create one dashboard, then filter it using metadata to hone in on the environment you want to visualize. The same concept applies to detectors.

SignalFx supports three types of metadata: dimensions, properties, and tags. They can all be used for the above use cases, but have some meaningful differences. Some of these differences are shown in the table below, and the following sections discuss the differences in more depth.

Dimensions	Properties	Tags
Key:value pair	Key:value pair	Keyword
Have to know when sending datapoint	Don’t have to know when sending datapoint	Don’t have to know when sending datapoint
Defined at time of sending datapoint	Defined via Metadata Catalog or REST API after ingest	Defined via Metadata Catalog or REST API after ingest
Metric + dimensions uniquely define MTS	Used for additional classification of dimensions	Used for additional classification of dimensions
Applied to metrics	Applied to dimensions	Applied to dimensions
Can be used to filter or group by	Can be used to filter or group by	Can be used to filter

Each type of metadata is described below. For recommendations on naming metadata, character limitations for metadata names, and so on, see Naming Conventions.

Dimensions 🔗

Dimensions are key:value pairs included as part of a datapoint, and are applied to the datapoint when it is sent to SignalFx. Each combination of dimensions and metric names is used by SignalFx to uniquely identify a metric time series and the datapoints that comprise it. Dimensions are especially useful when historical metadata is important, e.g. to denote code version in canary deployments.

You can use global search to see what values are in use for a specified dimension.

Properties 🔗

Properties are key:value pairs added to dimensions. As such, they are most often used to associate metrics with metadata that is not necessary for uniquely identifying a time series; that you don’t know at the time of data submission; or when tracking history is not important.

You can use global search to see what values are in use for a specified property.

Note

In many cases, the term “property” is used to mean “property or dimension.”

Tags 🔗

Tags can be thought of as labels or keywords assigned to dimensions. They are not key:value pairs.

The primary use case for tags is when there is a one-to-many relationship between the tag and the object you are assigning it to. For example, suppose you have hosts that are running multiple apps. You can create a tag for each app, then apply multiple tags to each host to specify the apps that are running on that host.

Tags are also appropriate for binary (or on/off) states. For example, you may want to tag certain hosts as “down” when you take them offline for a specific reason. When you bring the host back up, simply remove the tag. Note, however, that if the state is not binary, a property is more appropriate. If a host could have one of multiple states, then using a “state” property with the appropriate values (such as “down”, “being upgraded”, and “needs attention”) provides more flexibility. Using properties also makes the values more discoverable than would be the case with multiple tags, because the values will appear in dropdown lists when you are using the property to filter or group your data.

Property propagation 🔗

For the search, filtering and aggregation use cases mentioned above to work, the time series you are seeking must have the right metadata. SignalFx makes it easy to have the right metadata: properties that have been added to a dimension are propagated to all of the metric time series that contain that dimension.

For example, all of the metrics that are sent from host:server1 — e.g. cpu.utilization, memory.free, and disk_ops.total — will automatically inherit all the properties added to the dimension host:server1. By adding the property aws_availability_zone:us-east-1a to host:server1, your query for cpu.utilization of all hosts that are in aws_availability_zone:us-east-1a yields the CPU utilization metric time series for server1.