Step3: Query trend data - last 24 hours
In this step we query (IPM) for the metric data for a given entity and metric. We will be requesting data for the last 24 hours and will let (IPM) decide on the appropriate granularity to return for that timeframe.
Tip
Refer to the Schema section in the swagger documentation for other helpful end points and more information
Each time you need to query trend data for a given entity/metric you perform a GET to the following endpoint:
https://IPADDRESS/api/sdk/p/2/metrics/trend?metric=VM_cpu_used&entityId=<entity_uid>&startTime=-86400&granularity=AUTO&groupBy=ENTITY_TIMESTAMP_VERBOSE
Notice
Replace the <entity_uid> place holder with the UID of the ESX VM identified in step 2
The response will contain VM CPU Utilization trend data for the given entity, over the 24 hours (starting from the current time). The response will come back in a verbose form (where metric ids area repeat with every value)
Here is a breakdown of the various query parameters in that request:
metric=VM_cpu_used: Identifies (using the internal metric id) the metric to query for the given entity. You can repeat this section multiple times in the query parameters to request additional metrics in the same payload.
entityId=<entity_uid>: Identifies the entity (by entity uid) that you want to fetch the specified metrics for. You can repeat this section multiple times in the query parameters to request the same metrics from multiple entities.
startTime=-86400: This defines the start time of the query. Here we use a negative number of seconds to represent a start time RELATIVE to the end time. In this case, the last day (86400 seconds to a day). Since end time is NOT provided it defaults to the current time, thus this request is asking for data from the last 86400 seconds, or for the last day.
Tip
Start and end times can be provided in many different formats. Refer to the swagger documentation for more details.
granularity=AUTO: This indicates to (IPM) to pick an appropriate granularity that provides data for the given time at a granularity that will not overload user interfaces etc (5 minutes is typical for 24 hours). You can force the granularity to different levels, such as HOURLY or DAILY, however remember that data retention rates vary based on granularity. Refer to the swagger documentation for more details.
groupBy=ENTITY_TIMESTAMP_VERBOSE: This requests that the data be returned in a verbose json format, where metric names are repeated with each response. This can result in large payloads and extra processing time, but is easier to understand the data when just browsing. Refer to the swagger documentation for alternative formats (such as CSV)
We have successfully queried metric for one or more entities and for one or more metrics for the specified time frame. The options listed here are just a subset of what is available. Refer to the swagger documentation for additional options.