DellEMC

PowerStore performance metrics with REST API

In this blog post we are going to cover how to use DellEMC PowerStore’s REST API to get performance metrics. This skill is very important if you are planning to integrate PowerStore with a monitoring solution. In particular we will use this knowledge to create a Prometheus exporter in another blog post

We have written about PowerStore’s REST API before in this other article. Also you can get acquainted with the REST API very quickly and hands-on by using the Postman collection in this GitHub repo:

https://github.com/cermegno/Project-Vision

If you are new to Postman, don’t worry we have you covered; this other blog post provides details on how to use the collection in the Project Vision GitHub repo.

The REST API endpoint for extracting metrics from the PowerStore REST API is:

POST /metrics/generate

It being a POST call has 2 implications

  • The PowerStore REST API requires a CSRF token for POST calls. We’ll see shortly how to get it
  • POST calls require a “Body” parameter. In this particular case the “Body” parameter needs to specify things like the granularity of the metrics collection and more importantly the type of metrics, ex: capacity, performance, etc

First thing first. You have to run any GET call to get the token. In the following screenshot you can see how I have run the “GET /cluster”. The headers of the response provide us with the the token under “DELL-EMC-TOKEN”

Your code needs to extract the token programmatically and add it as a header on subsequent POST calls. By the way this also applies to other API calls that can “change the state” of the system, ex: PATCH and DELETE

As we mentioned, the POST call needs to include a JSON formatted “Body” parameter that looks as follows

{
  "entity": "performance_metrics_by_cluster",
  "entity_id": "0",
  "interval": "Five_Mins"
}

This is a “Body” example to obtain cluster-level metrics. The first parameter tells the storage array what type of metrics we are looking for. PowerStore is a REST API first architecture and as such the amount of functionality it provides through the REST API is staggering. This is also true for the types of metrics that are exposed through the REST API. At the time of this writing the following entities are supported. Their purpose is self-explanatory

  • performance_metrics_by_appliance
  • performance_metrics_by_node
  • performance_metrics_by_volume
  • performance_metrics_by_cluster
  • performance_metrics_by_vm
  • performance_metrics_by_vg
  • performance_metrics_by_fe_fc_port
  • performance_metrics_by_fe_eth_port
  • performance_metrics_by_fe_eth_node
  • performance_metrics_by_fe_fc_node
  • wear_metrics_by_drive
  • wear_metrics_by_drive_daily
  • space_metrics_by_cluster
  • space_metrics_by_appliance
  • space_metrics_by_volume
  • space_metrics_by_volume_family
  • space_metrics_by_vm
  • space_metrics_by_storage_container
  • space_metrics_by_vg
  • copy_metrics_by_appliance
  • copy_metrics_by_cluster
  • copy_metrics_by_vg
  • copy_metrics_by_remote_system
  • copy_metrics_by_volume
  • performance_metrics_by_file_system
  • performance_metrics_smb_by_node
  • performance_metrics_smb_builtinclient_by_node
  • performance_metrics_smb_branch_cache_by_node
  • performance_metrics_smb1_by_node
  • performance_metrics_smb1_builtinclient_by_node
  • performance_metrics_smb2_by_node
  • performance_metrics_smb2_builtinclient_by_node
  • performance_metrics_nfs_by_node
  • performance_metrics_nfsv3_by_node
  • performance_metrics_nfsv4_by_node
  • performance_metrics_file_by_node
  • performance_metrics_file_by_appliance
  • performance_metrics_file_by_cluster
  • performance_metrics_by_ip_port

Then we have the “entity_id”. This is the specific “id” for this kind of metric:

  • For clusters it will be: 0, 1, 2 …
  • For appliances: A1, A2, …
  • For volumes: 016c768a-340e-4123-98d8-3c689c9bd763, etc

The final parameter in the “Body” parameter is the “interval”. This tells the REST API the granularity of the data we are looking for. There are 4 different options at the time of this writing:

  • Twenty_Sec
  • Five_Mins
  • One_Hour
  • One_Day

Tips and Tricks

Now let’s cover some things to watch out for.

Firstly, one implication of this design is that metrics for different entities require discrete API calls. So for example if you want to extract read and write IOPS metrics for all volumes, it will be a two step process:

  • First retrieve the full list of volumes with “GET /volume”, specifically their id’s
  • Then retrieve the metrics for each individual volume by specifying their “entity_id”

In the next article we will introduce a Prometheus exporter for PowerStore that does exactly this

Another thing to watch out for is that depending on the API call and the “interval” the REST API might return the values for multiple intervals. For example:

  • a cluster performance call with a “Five_Mins” interval will always give you 24 hours worth of data
  • whereas volume performance with a “Twenty_Sec” interval will return a single point in time

At the time of this writing there is no parameter to control the time period you want retrieved, but from a developer perspective, the important thing is that the results are always packaged as a “list”. Since you just typically want to keep the most recent reading, write your code to extract the last item in the list. Why the last one? because the output is sorted in ascending order of timestamp, so that last one will be the most recent. For example, in Python if we have all the intervals in a list called “volumes”, we can simply use “volumes[-1]” to access the most recent metrics

Finally, another thing we have to bear in mind is that for some metrics the schema of the response changes for the “Twenty_Sec” interval. This is done to highlight the fact the metric is not an average for the period but a straight instantaneous reading. This is important when you are writing your code because if you only test it for the larger intervals, like “Five_Mins” and above, the code might break when you bring it down to “Twenty_Sec”. For example if we are interested in Read IOPS for a volume:

  • Five_Mins will return a parameter called “avg_read_iops”
  • Twenty_Sec will return a parameter called “read_iops”

So, my advice is to test your code thoroughly for all 4 intervals before releasing into production, even if you plan to keep it to “Five_Mins” initially

Don’t forget to visit the next article to see how to use all of this to create a Prometheus exporter in Python

1 reply »

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s