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.loadthat is being sent to SignalFx from each host, but want to see the 90th percentile ofjvm.cpu.loadby cluster rather than by individual host, in thepercentilecomputation, 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.