OpenMetrics Monitoring

Overview

LogicMonitor has created a monitoring package template that allows you to gather metrics from systems, like Telegraf, that expose metrics in OpenMetrics, an open source metrics exposition format. Previously known as Prometheus, OpenMetrics has been adopted by the Cloud Native Computing foundation, and is in use by a large number of projects.

Because OpenMetrics data can represent any number of metrics from any number of resources, you’ll need to customize both the template DataSource(s) LogicMonitor provides as well as add custom properties to the resource(s) that are exposing the OpenMetrics metrics.

Compatibility

LogicMonitor’s OpenMetrics monitoring package is compatible with any system that exposes metrics in the OpenMetrics format.

Setup Requirements

Import LogicModules

From the LogicMonitor repository, import the appropriate OpenMetrics LogicModule(s). LogicMonitor offers two versions of its OpenMetrics DataSource template:

  • OpenMetrics Template. This is the single-instance version. Use this DataSource template if the datapoints do not apply to more than one entity on the same host (e.g. memory usage on the host).
  • OpenMetrics Template MultiInstance. This is the multi-instance version. Use this DataSource template if the datapoints do apply to more than one entity on the same host (e.g. core utilization monitoring on a multi-core system).

Clone and Customize LogicModules

Once the OpenMetrics LogicModule(s) have been imported, clone and rename to something more descriptive. For more information on cloning LogicModules, see Cloning a LogicModule.

Edit and/or create datapoints that reflect the data you are looking to capture. Working off the sample datapoints provided in the DataSource template, this process primarily consists of cloning, renaming, and updating the datapoints(s) to reflect the key of the metric to be collected. For more information on configuring datapoints, see Datapoint Overview.

Note: The suggested logic for the AppliesTo field is commented out. In most cases, you’ll want to make this logic active so that the DataSource applies to any hosts with the openmetrics.host property configured (as discussed in a following section) and remove the false() designation. However, if you create multiple clones of the DataSource and you require each clone to apply to unique hosts, then you’ll need to customize the logic in the AppliesTo field in a manner that suits your use case.

Add Hosts Into Monitoring

Add your OpenMetrics host(s) into monitoring if they are not currently present. For more information on adding resources into monitoring, see Adding Devices.

Set Properties on Host

Set the following custom properties on the OpenMetrics host(s) within LogicMonitor. For more information on setting properties, see Resource and Instance Properties.

Property

Required or Optional

Value

openmetrics.host Required The name or IP of the host exposing metrics in OpenMetrics format. This may be the same host to which you are applying the property.
openmetrics.user Required If the OpenMetrics’ endpoint URL requires HTTP basic authentication, enter an authentication username.
openmetrics.pass Required If the OpenMetrics’ endpoint URL requires HTTP basic authentication, enter an authentication password.
openmetrics.path Optional The URL path to which the host is serving metrics in OpenMetrics format. This property is only necessary if the path differs from the default “/metrics” path.
openmetrics.ssl Optional If your OpenMetrics endpoint is serving metrics over HTTPS, set this property to TRUE.
openmetrics.port Optional The port to connect to in order to access the OpenMetrics endpoint. This property is only necessary if the port differs from the default 9273 port.
openmetrics.hostlabel Optional By default, the DataSource looks for a “host” label in the output and only parses metrics assigned this label that also match the value of the system.hostname property. If you are using a label other than “host” to identify the host in the output, assign that label here.
openmetrics.maphostname Optional By default, the DataSource looks for a “host” label in the output and only parses metrics assigned this label that also match the value of the system.hostname property. If you would like to collect metrics from entities other than “host”, set this property to FALSE. For example, a metric collection system such as Telegraf often receives metrics from multiple hosts. This property allows you to restrict to just those metrics pertaining to current host or, by disabling, you can aggregate metrics across multiple instances. If the instance name, as assigned according to the openmetrics.instance_keys property, identifies the host in some way, you’d be able to differentiate among metric host sources.
openmetrics.instance_keys Required for multi-instance The key that identifies the instance name. This is required if using the multi-instance version of the Datasource. Multiple keys can be referenced. For example, a property value of “cpu,host”, when applied to the following sample output, would return instance names of “cpu1telegraf”, “cpu2telegraf”, “cpu1sqlserver”, and so on.
cpu_usage_guest {"cpu-total",host="telegraf" } 25.3719
cpu_usage_guest {"cpu1",host="telegraf" } 23.1476
cpu_usage_guest {"cpu2",host="telegraf" } 27.4582
cpu_usage_guest {"cpu-total",host="sqlserver" } 40.5491
cpu_usage_guest {"cpu1",host="sqlserver" } 32.1539
cpu_usage_guest {"cpu2",host="sqlserver" } 45.9334
SAMPLE OUTPUT

LogicModules in Package

LogicMonitor’s package for OpenMetrics consists of the following LogicModules.

Display Name

Type

Description

OpenMetrics Template DataSource This is the single-instance version. Use this DataSource template if the datapoints do not apply to more than one entity on the same host (e.g. memory usage on the host).
OpenMetrics Template MultiInstance DataSource This is the multi-instance version. Use this DataSource template if the datapoints do apply to more than one entity on the same host (e.g. core utilization monitoring on a multi-core system).

This package does not include predefined datapoint thresholds (i.e. no alerts will trigger based on collected data). This is because the DataSources are provided as templates and designed to be highly customized. In order to receive alerts for collected data, you’ll need to manually create thresholds, as discussed in Tuning Static Thresholds for Datapoints.

In this Article: