Cisco AppDynamics Metrics Model

Cisco Cloud Observability ingests metrics in OpenTelemetry™ Line Protocol (OTLP) format from your OpenTelemetry-compatible agents or collectors, converts them into the Splunk AppDynamics metrics model, enriches them with derived data, and stores them in the Cisco Cloud Observability metrics datastore in Splunk AppDynamics metrics model format.The Splunk AppDynamics metrics model is similar to the OpenTelemetry data model for metrics, with important differences. This page describes the Splunk AppDynamics metrics model and explains how it relates to the OTLP format.

For help with individual metrics you might see in Cisco Cloud Observability, see Understand the Observe UI.

This document contains references to third-party documentation. Splunk AppDynamics does not own any rights and assumes no responsibility for the accuracy or completeness of such third-party documentation.

What is a Metric?

A metric is a numerical measurement, sampled over a specific timeframe and typically with a fixed frequency, such as TargetConnectionErrorCount. Splunk AppDynamics metrics are registered by a domain or feature in a type system. A metric has properties, a content type, and a category.

Terminology

The OpenTelemetry Data Model for Metrics

The OpenTelemetry data model for metrics specifies data formats and protocols for the import, transportation, and export of metrics. It includes the OpenTelemetry Line Protocol (OTLP) and the OpenTelemetry Timeseries Model.

OpenTelemetry Line Protocol

The OpenTelemetry Line Protocol (OTLP) defines how the OpenTelemetry metric stream is encoded and transported over gRPC or HTTP 1.1 to an OpenTelemetry timeseries store. Each metric stream is identified by its name, attributes, originating resource, and OTLP type (point kind). There can be more than one metric stream per instrument in the event model.

Splunk AppDynamics supports the following OTLP types. Each OTLP type maps to a specific aggregation function or functions.

OpenTelemetry Timeseries Model

The OpenTelemetry Timeseries Model specifies how OpenTelemetry backends store metrics—in other words, the at rest format of metrics at their destination.

The Splunk AppDynamics Metrics Model

Pre-ingest, Ingest, and Post-ingest Granularity

• Pre-ingest metric granularity depends on the data source. The granularity of sampling can vary depending on the collector's configuration or the data source.
• Supported ingest granularities are one minute and five minutes. Granularities that fall within a threshold range(±3s) of defined ingest granularities are also acceptable. At ingest time, the Cisco Observability Platform aggregates metrics collected at sub-minute granularities into one-minute granularities by default. Cisco Observability Platform schemas define metrics and ingest granularities for all registered entity types.
• Post-ingest, Cisco Cloud Observability may aggregate metrics into higher granularities and compute roll-ups and summaries both at an entity's relationship level and at an entity's attribute level. 

Metric Retention

Cisco Cloud Observability retains one-minute aggregations for eight days, and one-hour aggregations for 367 days. 

Metric Content Types

The Splunk AppDynamics metrics model defines Sum,  Distribution, and Gauge metric content types. The following table explains how Splunk AppDynamics maps OTLP types to Splunk AppDynamics metric content types.

Metric Categories 

The Splunk AppDynamics metrics model introduces the concept of metric categories. Metric categories do not exist in the OpenTelemetry data model for metrics. When you look at metric graphs on Cisco Cloud Observability, you see a single value for each timestamp even though some Splunk AppDynamics metric content types can have multiple values. This single value is a calculation based on the metric category. The metric category is a consumption function --a mathematical function that defines how that single value is calculated.  Therefore, the best practice is to assign a metric category to each metric in your OpenTelemetry collector's configuration. 

The Splunk AppDynamics metric model defines the following metric categories:

• AVERAGE
• CURRENT
• CURRENT_PER_INSTRUMENTED_ENTITY
• RATE_PER_MIN
• RATE_PER_SEC
• SUM
• SUM_PER_INSTRUMENTED_ENTITY

The following table lists each Splunk AppDynamics metric category, the mathematical formula that Splunk AppDynamics uses to calculate a single value to display, and what metric content types Splunk AppDynamics can assign to that metric category. For example, Splunk AppDynamics assigns metrics of category CURRENT to content type Guage.

timestamp | sum | RATE_PER_MIN| RATE_PER_SEC   
      60s |  30 |  30/0.5=60  | 30/30=1
     120s |  30 |  30/0.5=60  | 30/30=1

Consumption Functions

A consumption function is a mathematical function, which can show a different view or aggregation of metric data. For example, a max function gives the maximum value of all metric data points in the given time range. A consumption function is similar to a metric category, except that it can be supplied dynamically at query time. In other words, in addition to a default value based on a category, a consumption function can be used when querying metrics. This is useful when you want to override the metric category and apply a different mathematical function for a query.  

Splunk AppDynamics Metric Aggregations

Space Aggregations

Cisco Cloud Observability does not support space aggregations if the timeseries have different aggregation temporalities, such as Delta and Cumulative timeseries.

Time Aggregations

Cisco Cloud Observability converts all Cumulative metrics into Delta before storing them. We handle resets and gaps in Cumulative metrics as follows:

• We detect resets and gaps based on the StartTimeUnixNano present in the metric packet and a comparison of that value with the same value in a previously received metric packet. If the current value is greater than the previous value, we treat it as a reset. Also, in case of monotonically increasing metrics, if the current metric value is less than previous metric value, then we treat it as a reset.
• We treat drops in the continuous data flow of metric data as gaps. The first metric we receive after a gap is not stored in our backend but is instead used as the new reference point to calculate future Delta metrics.

OpenTelemetry™ and Kubernetes® (as applicable) are trademarks of The Linux Foundation®.