Docs » Reference » Best Practices » Separate Dimensions from Metric Names

Separate Dimensions from Metric Names 🔗

Some metrics products, such as Graphite, StatsD, or New Relic, expect you to describe metrics as long period-delimited or slash-delimited strings that include both a metric name and all the data that describes the metric (its metadata). Splunk Infrastructure Monitoring lets you to associate arbitrary key-value pairs called dimensions with metrics. Dimensions let you represent multi-dimensional data without having to overload your metric name with metadata.

Splunk Infrastructure Monitoring also lets you use dimensions and metric names to find, filter, and aggregate.

Although some UI features let you use long delimited metric names, others such as dashboard variables or the Infrastructure Navigator require you to use dimensions.

Follow the guidance in this topic to modify your naming scheme to use metrics and dimensions.


If you already have metrics with period-separated names, use OpenTelemetry to parse dimensions from metric names.

Metric name standards 🔗

Information you can use in a metric name:

  • Measurement description: For example, cpu.temperature If you apply a calculation to the metric before you send it, you can also use the calculation as part of the description. For example, if calculate the ninety-fifth percentile of measurements and send the result in a metric, use p95 as part of the metric name.
  • Measurement units: For example, degreesC
  • Metric category: For example, temperature

Information that should be a dimension:

  • Description of hardware or software being measured: For example, don’t use production1 to indicate that the measurement is for a particular host.

Dimension name and value standards 🔗

Types of information that are suitable for dimension values:

  • Categories rather than measurements: If doing an arithmetic operation on dimension values results in something meaningful, you don’t have a dimension.
  • Metadata for filtering, grouping, or aggregating
  • Name of entity being measured: For example "hostname": "production1"
  • Metadata with large number of possible values: Use one dimension key for many different dimension values.
  • Non-numeric values: Numeric dimension values are usually labels rather than measurements.

Example: Custom metric name and dimensions 🔗

For example, consider the measurement of HTTP errors.

You want to track the following data:

  • Number of errors
  • HTTP response code for each error
  • Host that reported the error
  • Service (app) that returned the error

Suppose dimensions didn’t exist, and instead you had to make a long metric name from all of the data. A metric name that represented the number of HTTP response code 500 errors reported by the host named myhost for the service checkout would have to be the following:


As a result of using this metric name, you’d experience the following:

  • To visualize this data in a Splunk Infrastructure Monitoring chart, you would have to perform a wildcard query with the syntax web.http.*.*.error.*.count.
  • To sum up the errors by host, service, or error type, you would have to change the query.
  • You couldn’t use filters or dashboard variables in your chart.
  • You would have to define a separate metric name to track HTTP 400 errors, or errors reported by other hosts, or errors reported by other services.

Because dimensions are available, to track the same data you can do the following:

  1. Define a metric name that describes the measurement you want, which is the number of HTTP errors: web.http.error.count. The metric name includes the following:
    • web: Your name for a family of metrics for web measurements
    • http.error: Your name for the protocol you’re measuring (http) and an aspect of the protocol (error)
    • count: The unit of measure
  2. Define dimensions that categorize the errors. The dimensions include the following:
    • host: The host that reported the error
    • service: The service that returned the error
    • error_type: The HTTP response code for the error

When you want to visualize the error data using a chart, you can search for “error count” to locate the metric by name. When you create the chart, you can filter and aggregate incoming metric time series by host, service, error_type, or all three. You can add a dashboard filter so that when you view the chart in a specific dashboard, you don’t have the chart itself.