This documentation and the Cisco Observability Platform functionalities it describes are subject to change. Data saved on the platform may disappear and APIs may change without notice.

Introduction

The Cisco Observability Platform allows you to subscribe to a solution and define custom integrations to suit your solutions and processes. To extend a solution capability, you need to describe a domain model.

After you define a domain model, define the domain objects required for your solution.

if you obtain domain data by observing customer environments and instrumenting other applications, then create processing rules to identify and extract domain objects from the telemetry
if you obtain domain data by extracting additional value based on the data ingested by other solutions, then define extension points that in turn produce the domain objects - functions or workflows

Cisco Observability Platform includes a core capability (packaged as a system solution) called Flexible Meta Model (FMM) that allows you to model the domain of your solution. A domain model allows your solution to describe your topology and corresponding telemetry data using a predefined type system. A type defines required attributes, their data types, references to other types, including correlations with other domains (solutions), and so on. Cisco Observability Platform can then interpret, correlate and present telemetry data for your solution based on your data model.

Each solution domain can define and maintain its own model. This helps the domain teams to update the solution model or extend it. After you define an Cisco Observability Platform data model, you can monitor the performance of various entities (components/objects) defined in your solution. For example, you can define a data model to monitor a Git repo as an entity; determine the number of commits, number of test failures as metrics to monitor this entity.

Info: Some solutions need not define any domain model and may use the predefined domain models, such as, K8, and infra.

Structure of the Cisco Observability Platform Domain Model

The following image depicts various components, attributes and properties of the Cisco Observability Platform Data model.

The following table lists the base components of a Flexible Meta Model (schema). You use these components to define a domain model for your solution. You can define various attributes and properties associated with each of the components.

Component	Description
Namespace	Represents the unique name of the namespace across all domain namespaces within the Cisco Observability Platform. The Cisco Observability Platform uses this object to identify all the data related to your solution domain.
Associations	The associations that describe the relationships between entities in a domain model.
Association Type	Association types associate a given interaction type to its source, target type, context and upstream types .
Entity	An entity represents a logical component of an application. An entity has properties, attributes, tags and labels.
Entity Types	The entity types and the relationships represent how they interact with each other within a given domain (for example, A K8s Cluster contains Nodes).
Event	An event is a discrete data record with significant points of analysis that occurred at a given time (timestamp) for a specific entity . E vents are automatically generated when the entities change state, or when errors occur.
Event Type	Various types of events recorded in an application. Event types are associated with an existing Entity or Interaction.
Extension Type	Extensions help add/derive value to/from entities that belong to other solutions. An extension type adds attributes or MELT data to one or more existing entity types.
Metric	Metrics are numerical measurements of an entity or Interactions measured or sampled over a period of time typically with fixed frequency. Metrics can include: A numeric status at a moment in time (like CPU % used) Aggregated measurements (like a count of events over a one-minute time, or a rate of events-per-minute)
Metric Type	Various types of metrics (collected or processed) obtained from the telemetry data. Metric types are associated with an existing Entity or Interaction.
Span	A span represents each unit of work within a trace. Whereas a trace represents the complete process of a request, from the beginning to the end of a request lifecycle.

After you subscribe to a solution, you can view the data model for the solution, update it based on your requirements and even extend the model.

Info: You can make a local update to a subscribed solution. However, you cannot make a global update to a solution that you do not own.

Example of an Entity Domain Model

Expand source

{
  "types": [
    {
      "namespace": {
        "name": "apm",
        "version": 1
      },
      "kind": "entity",
      "name": "service_instance",
      "displayName": "Service Instance",
      "lifecycleConfiguration": {
        "purgeTtlInMinutes": 4200,
        "retentionTtlInMinutes": 1440
      },
      "attributeDefinitions": {
        "optimized": [
          "service.instance.id", "service.name", "service.namespace"
        ],
        "required": [
          "service.instance.id", "service.name", "service.namespace"
        ],
        "attributes": {
          "service.instance.id": {
            "type": "string",
            "description": "ID of the service instance"
          },
          "service.name": {
            "type": "string",
            "description": "Name of the service"
          },
          "service.namespace": {
            "type": "string",
            "description": "Namespace for the service"
          },
          "service.version": {
            "type": "string",
            "description": "The application version this instance is running"
          },
          "container.id": {
            "type": "string",
            "description": "The ID of the container this instance is running on"
          }
        }
      },
      "metricTypes": [
        "apm:calls_per_minute",
        "apm:average_response_time",
        "apm:errors_per_minute"
      ],
      "associationTypes": {
        "common:consists_of": [ "apm:instance_endpoint" ]
      }
    }
  ],
  "configs": []
}