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.

MELT Payload Examples

The fsoc melt send command sends telemetry payloads to be ingested into the MELT store. Often, this command is used to simulate received telemetry for testing solutions.

Payload data files can be created in two ways:

From a solution's MELT model, generated by the fsoc melt model command. This works well for your own solutions, as it uses your solution's manifest and objects to correctly represent the supported MELT data. The drawback is that you need the solution files to create a model.
Created by filling in attributes manually, e.g., by obtaining attribute, metric and event names from the Schema Browser.

Both methods are described below.

Also, please note that fsoc logs the trace response for each payload sent. You can obtain these logs by looking in the fsoc.log file or by running fsoc with the --verbose flag. The trace responses can be used to troubleshoot data ingestion problems.

Here are some examples of trace responses for metrics and logs payloads that were successfully sent:

• Sent MELT data            path=metrics trace_response=00-25dc40e087d984d047088b6a769292bc-b2e577e6b7bd9500-01
• Sent MELT data            path=logs trace_response=00-8fef2365fb161d3e22624fbf7f2d4fcb-9bfb4a60bbc704e2-01

Generating a MELT Model

For your own solutions, you can use the fsoc melt model command to create a template for all possible telemetry payloads for types defined by your solution.

The melt model command should be executed in the solution directory (similar to most fsoc solution commands). It creates a model file named <solutioin>-<version>-melt.yaml, where <solution> is the name of your solution and <version> is the version of the solution for which the model file is created.

You can then copy and customize MELT objects from that template and send them with the melt send command.

Manually Populated Payloads

A single data file can contain a number of different telemetry payloads. Each is formed as a separate YAML object in the file. The examples below describe telemetry types separately, but it is possible to combine multiple in the same file.

Here is an example of a data file that combines multiple MELT telemetry types for the same entity:

melt:
- typename: ugottaridedev:rider
  attributes:
    ugottaridedev.rider.display_name: "Superman"
    ugottaridedev.rider.first_name: "Clark"
    ugottaridedev.rider.last_name: "Kent"
    ugottaridedev.rider.riderid: "7770007"
    telemetry.sdk.name: "ugottaridedev"

  metrics:
  - typename: ugottaridedev:miles_traveled
    contenttype: gauge
    description: number of miles traveled
    unit: miles
    type: long
    min: "5"
    max: "50"
  logs:
  - body: hello world-0 for an entity of type ugottaridedev:rider
    severity: INFO
    attributes:
      level: info
  - body: hello world-1 for an entity of type ugottaridedev:rider
    severity: INFO
    attributes:
      level: info
  relationships:
    - attributes:
        ugottaridedev.ride.rideid: "7770007"
        ugottaridedev.type: "ride"

Metrics

The following form is the simplest one to send metrics:

melt:
- typename: ugottaridedev:rider
  attributes:
    ugottaridedev.rider.display_name: "Superman"
    ugottaridedev.rider.first_name: "Clark"
    ugottaridedev.rider.last_name: "Kent"
    ugottaridedev.rider.riderid: "7770007"
    telemetry.sdk.name: "ugottaridedev"

  metrics:
  - typename: ugottaridedev:miles_traveled
    contenttype: gauge
    unit: ""
    type: long

Since neither values nor ranges are defined for the metric, fsoc generates 5 random values between 0 and 50. Each value covers a one-minute observation.

Minimum and/or maximum values can be defined to control the random value generated by fsoc:

melt:
- typename: ugottaridedev:rider
  attributes:
    ugottaridedev.rider.display_name: "Superman"
    ugottaridedev.rider.first_name: "Clark"
    ugottaridedev.rider.last_name: "Kent"
    ugottaridedev.rider.riderid: "7770007"
    telemetry.sdk.name: "ugottaridedev"

  metrics:
  - typename: ugottaridedev:miles_traveled
    contenttype: gauge
    unit: ""
    type: long
    min: "5"
    max: "140"

Using random values and automatically generated timestamps is a convenient way to test metric ingestion.

Instead of a range, you can define just a value that will be repeated 5 times:

melt:
- typename: ugottaridedev:rider
  attributes:
    ugottaridedev.rider.display_name: "Superman"
    ugottaridedev.rider.first_name: "Clark"
    ugottaridedev.rider.last_name: "Kent"
    ugottaridedev.rider.riderid: "7770007"
    telemetry.sdk.name: "ugottaridedev"

  metrics:
  - typename: ugottaridedev:miles_traveled
    contenttype: gauge
    unit: ""
    type: long
    value: "42"

(the above form was introduced in v0.57.0)

Alternatively, you can also define the exact data points with their timestamps that you wish to send:

melt:
- typename: ugottaridedev:rider
  attributes:
    ugottaridedev.rider.display_name: "Superman"
    ugottaridedev.rider.first_name: "Clark"
    ugottaridedev.rider.last_name: "Kent"
    ugottaridedev.rider.riderid: "7770007"
    telemetry.sdk.name: "ugottaridedev"

  metrics:
  - typename: ugottaridedev:miles_traveled
    contenttype: gauge
    unit: ""
    type: long
    datapoints:
    - starttime: 1700117308082199642
      endtime: 1700117368082199642
      value: 14
    - starttime:  1700117631014670124
      endtime:  1700117691014670124
      value: 48

Note that the start and end time used must be recent, with a few minutes from the current time; otherwise the data will be rejected.

For metrics with content type sum, the aggregation temporality can be specified as well:

melt:
- typename: ugottaridedev:rider
  attributes:
    ugottaridedev.rider.display_name: "Superman"
    ugottaridedev.rider.first_name: "Clark"
    ugottaridedev.rider.last_name: "Kent"
    ugottaridedev.rider.riderid: "7770007"
    telemetry.sdk.name: "ugottaridedev"

  metrics:
  - typename: ugottaridedev:miles_traveled
    contenttype: sum
    description: "number of miles traveled"
    unit: "miles"
    type: long
    aggregationtemporality: cumulative

The temporality can be specified in any of the following forms (the strings values are not case sensitive):

Meaning	Integer	Short name	Long name
Unspecified	0	unspecified	AGGREGATION_TEMPORALITY_UNSPECIFIED
Delta	1	delta	AGGREGATION_TEMPORALITY_DELTA
Cumulative	2	cumulative	AGGREGATION_TEMPORALITY_CUMULATIVE

The units, description and temporality support was added in fsoc v0.64.0.

Logs

Log events use the following form:

melt:
- typename: ugottaridedev:rider
  attributes:
    ugottaridedev.rider.display_name: "Superman"
    ugottaridedev.rider.first_name: "Clark"
    ugottaridedev.rider.last_name: "Kent"
    ugottaridedev.rider.riderid: "7770007"
    telemetry.sdk.name: "ugottaridedev"

  logs:
  - body: hello world-0 for an entity of type ugottaridedev:rider
    severity: INFO
    attributes:
      level: info
  - body: hello world-1 for an entity of type ugottaridedev:rider
    severity: INFO
    attributes:
      level: info

Events

Non-log events use the following form:

melt:
  - attributes:
      telemetry.sdk.name: optimize:co
      k8s.deployment.uid: f76a4ef5-6aa5-46eb-bc02-afb947784834
      k8s.cluster.id: 9fc0afdc-9474-43ad-b5b9-849acb14c74f
      optimize.optimization.num: 41
      optimize.optimization.optimizer_id: 9fc0afdc-9474-43ad-b5b9-849acb14c74f
      optimize.recommendation.num: 1
      optimize.recommendation.cost: 1.1
      #...
    logs:
      - attributes:
          optimize.event_description: "recommendation verified"
        isevent: true
        typename: optimize:recommendation_verified

Spans

melt:
  - attributes:
      container.id: container-458FB4A7-7342-4323-9811-B1030263289C
      k8s.namespace.name: ns-458FB4A7-7342-4323-9811-B1030263289C
      k8s.pod.name: pod-458FB4A7-7342-4323-9811-B1030263289C
      service.instance.id: service-inst-458FB4A7-7342-4323-9811-B1030263289C
      service.name: service-name-458FB4A7-7342-4323-9811-B1030263289C
      service.namespace: service-namespace-458FB4A7-7342-4323-9811-B1030263289C
    spans:
      - traceid: 7bba9f33312b3dbb8b2c2c62bb7abe1d
        spanid: 086e83747d0e381e
        parentspanid: ""
        name: /v1/sys/health
        starttime: 1700101923345341184
        endtime: 1700101923556341184
        status:
          code: 1
          message: ""
        attributes:
          http.flavor: "1.1"
          http.host: 10.177.2.152:26040
          http.method: GET
          http.route: /v1/sys/health
          http.scheme: http
          http.server_name: mortar-gateway
          http.status_text: OK
          http.target: /v1/sys/health
          http.user_agent: Consul Health Check
          net.host.ip: 10.177.2.152
          net.host.port: "26040"
          net.peer.ip: 172.17.0.1
          net.peer.port: "51820"
          net.transport: IP.TCP
        events:
          - name: "OK"
            timestamp: 1700101923556341184