Cisco Observability Platform Query Service API

Pagination

Sometimes a query returns a list of entities that needs to be ordered to ensure the responses can be handled easily. Query Service API supports continuous loading, meaning the query will return the only limited count of records and link to get the next page. provides three options to paginate the reponses:

  • Order (sort) data to get a consistent result.
  • Limit the number of rows - define the page size.
  • Use the continuation link in the result to retrieve the next page with the data.

Query Service API supports continuous loading, meaning the query returns only limited count of records and a link to get the next page.

Query Service API response is an array of data chunks. Each individual data chunk of the response can be individually paginated. Data chunks represent MELT data in some scope. For example, entities or events related to a single entity.

  • topology - Also known as the main data chunk. The number of roads there is defined by the FROM statement of the query.
  • events

Limits

You need to define a limit of records or accept a default limit to paginate. For example, default limit for topology is 1000.

Code Snippet
CopyFETCH
  id,
  attributes,
  events(some_type)
FROM
  entities(k8s:pod)
LIMITS
  topology.count(100),
  events.count(500)

This query returns the main data chunk (topology) with maximal 100 rows. The FETCH clause returns id, reference to chunk with attributes, reference to chunk with events for each row. So, the response contains up to 100 data chunks with attributes and 100 data chunks with events. The LIMITS clause then defines that each of these 100 events data chunks contain a maximum of 500 rows with actual events.

Continuation

Each response data chunk with limited rows contains a link to the next page. - See "_links" .

Code Snippet
Copy{
    "type": "data",
    "model": {
      "$jsonPath": "$..[?(@.type == 'model')]..[?(@.name == 'm:main')]",
      "$model": "m:main"
    },
    "dataset": "d:main",
    "_links": {
      "next": {
        "href": "/monitoring/v1dev/query/continue?cursor=ewogICJtYXhHcmFudWxhcml0eSIgOiAtMSwKICAic2tpcCIgOiAxMDAsCiAgInR5cGUiIDogInRvcG9sb2d5IiwKICAicXVlcnkiIDogIkZFVENIXG4gICBpZFxuRlJPTSBcbiAgZW50aXRpZXMoazhzOnBvZClcbkxJTUlUU1xuICB0b3BvbG9neS5jb3VudCgxMDApLFxuICBldmVudHMuY291bnQoMTAwMCkiCn0%3D"
      }
    },
    "data": [
      ...
     ]
}

Order/Sort

To get expected data with limitations, you need to order (sort) its rows.

You can order/sort:

  • Topology (entities) - id, type, createdAt, updatedAt, any attribute or tag
  • Events - only timestamp

Note You must use an alias in the FETCH statement to define what to order by.

Code Snippet
CopyFETCH
  attr_name: attributes(name),
  attr_foo: attributes(foo),
  tp: type,
  tag_location: tags(location)
FROM
  ...
ORDER
  topology.asc(tp).asc(attr_name).desc(tag_location).asc(attr_foo),
  events.desc()
Next