Adding Custom Metric Datasets

Metrics contained in a generic dataset do not automatically appear in the Metrics Explorer. For that to happen, you must tell Observe that this dataset contains metrics. This is done by editing the dataset and using the “metric” option of the interface OPAL command. Observe will then recognize this dataset contains metrics, and automatically present its metrics for visualization in Metrics Explorer.

The interface verb is used to map fields to an interface. In the case of metrics, the required OPAL looks as follows:

interface "metric", metric:metric_column_name, value:value_column_name, tdigestValue:tdigest_column_name

Note

The “tdigestValue” column is optional. It is only required if any of the metrics contained in the dataset are of type tdigest. The interface binding is also optional, and only required if such column is present.

The data you see doesn’t change, but registering or implementing the metric interface establishes the following conditions:

  • Each row represents one point in a time series

  • A field named metric_column_name contains the metric names

  • A field named value_column_name contains the float64 metric values

  • A field named tdigest_column_name contains the tdigest metric values

If the metric names and values are already in fields called “metric” and “value”, interface discovers them automatically and you can simply use:

interface "metric", tdigestValue:tdigest_column_name

Note

The “tdigestValue” binding, unlike the “metric” and “value” bindings, can never implicit when any of the metrics if of type tdigest.

Now that you understand the types of Metrics collected by Observe and the Observe apps and how to tell Observe about them, try to use the Metrics Explorer feature to easily visualize Metrics Datasets!

Modeling Metadata into Metric Datasets

After telling Observe about metric datasets, you may need to customize the individual metrics.

Every metric in Observe can have a type, unit, and description associated with it. Defining a metric using set_metric, lets you set values for all three of these.

Observe uses the metadata of a metric to visualize metrics appropriately. For example, Observe chooses the rate rollup method by default to visualize metrics of type cumulativeCounter, and the Y-axis label displays the unit based on the unit of the chosen metric.

Some metric providers, such as Google Cloud Platform (GCP), AWS, and OTEL, provide metric metadata with every metric point. The metric dataset looks similar to the following table:

Metric

Value

Tag

Type

Unit

Description

Tags

Other providers, such as Prometheus, send metadata separately from the metric and do not contain any information about the tags.

A sample observation of a metric point sent by Prometheus with the OBSERVATION_KIND set to prometheus:

{

  "__name__": "collector_request_duration_seconds_bucket",  // <- metric name
  "clusterUid": "23e17bad-48da-427e-9585-ead2231bbcae",     //---+
  "container": "collector",                                 //   |
  "endpoint": "/chronicle/eu-west1/dmgprotect",             //   |
  "instance": "172.20.68.149:11000",                        //   |
  "job": "integrations/kubernetes/pods",                    //   |<- metric tags
  "le": "0.05",                                             //   |
  "namespace": "prod-eu-1",                                 //   |
  "node": "ip-172-20-83-237.eu-central-1.compute.internal", //   |
  "pod": "collector-6dbb6787f9-5bqdn",                      //   |
  "status": "202"                                           //---+
 
}

A sample observation of metric metadata sent by Prometheus with the OBSERVATION_KIND set to prom_md:

{
  "help": "HTTP request latency in seconds",                    
  "metric_family_name": "collector_request_duration_seconds",  // <- metric name
  "type": "HISTOGRAM",
  "unit": ""
}

Modeling Metadata

Observe provides two ways of modeling metric metadata:

  • GCP, AWS, and OTEL metrics where the metric includes the metadata

  • Prometheus where the metrics and metadata are sent separately.

For metrics with included metadata, use the following OPAL:

interface "metric", metric:metric, value:value, metricType:type, metricUnit:unit, metricDescription:description

metricType, metricUnit, and metricDescription are optional parameters for the metric interface. When defined, Observe can find the metric metadata in the columns for these fields.

To model metadata sent separately from metrics, store the metrics and metadata in separate datasets. Datasets containing metrics should implement metric interface and the dataset containing metadata should implement the metric_metadata interface.

Metric

Type

Unit

Description

You can define the metric_metadata interface using the following OPAL:

interface "metric_metadata", metric:metric, metricType:type, metricUnit:unit, metricDescription:description