Infrastructure metrics

Metric types

IBM Instana Observability supports the collection and storage of curated and custom metrics:

• Curated metrics are metrics that Instana sensors are preconfigured to collect and store. These metrics represent Key Performance Indicators (KPIs) for a particular technology and are typically the default metrics that are seen in curated Instana dashboards.

• Custom metrics are metrics that originate from user applications or unsupported technologies. Certain Instana sensors, such as the Instana Prometheus sensor, can collect custom metrics.

Metric granularity

Metric granularity is the time interval that is used to collect and store metrics. The default metric granularity for most Instana sensors is one second. To reduce storage costs and improve dashboard visualization, one-second metrics are rolled up (summarized) into the following time intervals:

• 5 seconds
• 10 seconds
• 1 minute
• 5 minutes
• 1 hour

A metric rollup generally consists of the sum, minimum, maximum, the mean aggregation value over the time interval, plus percentiles.

IBM Instana Observability automatically selects the appropriate metric granularity to use for metric retrieval based on the time range that is selected on a dashboard. The metric granularity decreases as the time range increases. The smallest metric granularity that can be displayed on the Analyze Infrastructure and custom dashboards is 10 seconds. Curated dashboards generally display mean metric values, but you can select the metric aggregation value that is used on the Analyze Infrastructure and custom dashboards.

Metric identity

A metric by itself is meaningless without context. For a metric to be useful, additional information (metadata) that describes the origin of the metrics is required. IBM Instana Observability automatically associates metrics to the entity or resource that creates the metric to define its context. Metric identifiers can be tagged or untagged:

• Tagged metrics use one or more key-value pairs (tags) to further identify the metric context.
• Untagged metrics do not specify any identity information other than the metric name itself.

For example, consider a metric that is named shoes_sold_total. The metric represents the number of shoes that were sold, but the store which sold the shoes is not clear. Because no other identification information is included (making it an untagged metric), this metric represents a single time series of values. To provide further detail, shoes_sold_total can be changed to a tagged metric that specifies both the country and store that sold the shoes:

shoes_sold_total{country="Canada",storeId="0001"}
shoes_sold_total{country="Canada",storeId="0002"}
shoes_sold_total{country="France",storeId="0003"}
shoes_sold_total{country="Germany",storeId="0004"}

Adding key-value pairs as tags results in the creation of multiple time series (four in this example), which allows more detailed metric insights and flexible metric queries.

Metric tag usage

In addition to providing detailed metric identification, tags can be used to filter and group metric results. Tag filters and groups can provide powerful data insights that are otherwise not available for untagged metrics. Using the shoes_sold_total example from the Metric identity discussion, the following types of queries are possible:

• Calculate the total number of shoes that are sold across all stores by using a cross-series sum where country="Canada".
• Display the total number of shoes that are sold from highest to lowest, and group the results by country.

Use tags to filter and group metrics on the Analyze Infrastructure and custom dashboards.