Skip to main content
Sumo Logic

Beta - About Metrics Rules

Metrics rules allow organizations to make use of their own metrics structure when specifying metrics queries.  A rule is an instruction for parsing an existing metric name so it becomes straightforward to apply Sumo Logic syntax when creating visualizations. 

For example, assume that an organization collects the metrics cpu-load, cpu-idle, and bytes-infrom instances in their production environment and that the organization’s metrics are named as follows:

prod.search.server-1.cpu-load

prod.search.server-2.cpu-load

prod.frontend.server-1.cpu-load

prod.frontend.server-2.cpu-load

prod.frontend.server-3.cpu-load

prod.search.server-1.cpu-idle

prod.search.server-2.cpu-idle

prod.frontend.server-1.cpu-idle

prod.frontend.server-2.cpu-idle

prod.frontend.server-3.cpu-idle

prod.search.server-1.bytes_in/second.m15_rate

prod.search.server-2.bytes_in/second.m15_rate

prod.search.server-1.bytes_in/second.m10_rate

prod.search.server-2.bytes_in/second.m10_rate

The metric names follow these conventions (conventions for your organization might be different):

  • The first three dot-separated entries represent the environment, cluster, and instance.
  • For CPU-related metrics, the last dot-separated entry represents the quantity being measured.
  • For bytes-in, the last two entries together represent what’s being measured.

Metric rules provide a mechanism to make this organization structure manifest with a set of key-value pairs. The key-value tags are indexed along with the metric name, making it possible to search the metrics by tags.

Constructing metric rules

Suppose that the organization in the previous example wants to add the following tags for each of the metrics cluster, instance, and what.

cluster and instance are the second and third part of the metric name, and what follows the third part. The following rule captures the tagging in a way that is consistent with the metrics naming conventions.

From: prod.*.*.** extract: cluster=$_raw._1 instance=$_raw._2 what=$_raw._3

In this example:

From indicates the source metric.

Extract indicates the matching criteria. 

The *  wildcard matches one or more characters.

Dot (.) is a literal separator. 

$_ indicates a value match.

The sequences 1, 2, and 3 reflect the order of the tags as they appear in the metrics.
The following table shows the result of applying the rule to a few of the metrics in the example.

Metric Name cluster instance what
prod.search.server-1.cpu-load  search server-1 cpu-load 
prod.frontend.server-3.cpu-idle frontend server-3 cpu-idle
prod.search.server-2.bytes_in/second.m15_rate search server-2 bytes_in/second.m15_rate
prod.search.server-2.bytes_in/second.m10_rate search server-2 bytes_in/second.m15_rate

The tag values bytes_in/second.m15_rate and bytes_in/second.m10_rate can be broken down further by adding a  granularity tag:

From: what=bytes_in/second.m*_rate extract: what=bytes_in/second granularity=$what._1

The following table shows the tag values after applying this rule.

Metric Name cluster instance what Granularity
prod.search.server-1.cpu-load  search server-1 cpu-load   
prod.frontend.server-3.cpu-idle frontend server-3 cpu-idle  
prod.search.server-2.bytes_in/second.m15_rate search server-2 bytes_in/second 15
prod.search.server-2.bytes_in/second.m10_rate search server-2 bytes_in/second 10


With this structure in mind, you can define metric rules, which then become available for selection on the Metrics page.