Performance monitoring using OCUM API Services.

[abhijit_bhagat]

Hello ,

Since OCUM 6.x for monitoring of performance metrics we have to use OCUM API services.

I have created this setup but I am not able to get the data for the performance metrics for any of the object.

For example 

https://localhost:8443/api/1.0/ontap/aggregates/metrics

This URI is returning response as follows :

{
   "status": {
   "code": "SUCCESS"
    },
    "result": {
    "total_records": 0,
    "records": []
    }
}

This means execution of query is successful with empty data array.

Whereas the query for the aggregates is returning data properly.
https://localhost:8443/api/1.0/ontap/aggregates

Performance manager has a real-time as well as historical data.

Connection status between OCUM API Services, OCUM and performance manager shows as connected.

Any highlight why would the URI is returning data array for the performance metrics empty ?

Thanks,

Abhijit.

[abhijit_bhagat]

Some more details about versions :

OnCommand Unified Manager 6.2P1

OnCommand Performance Manager 2.0.0

OnCommand API Services Version: 1.0-1506072347

[bobshouseofcards · Accepted solution]

The issue is version incompatibility between OnCommand API servers 1.0 and OnCommand Performance Manager 2.0GA.  Officially, API 1.0 only supports OPM up to 1.1 per the Interoperability Matrix, which is why you don't get metrics.

If you get the API 1.1 Release Candidate you will get metrics.  API 1.0 did work with the OPM 2.0 Release Candidate just fine, which was really a problem when they switched to GA and stuff didn't work quite right.

This particular issue killed me during evaluation of the tools - the API 1.1 RC didn't come out until almost two months after OPM 2.0 and OCUM 6.3 GA versions, as I recall.  The release candidates of both OCUM and OPM worked fine with API 1.0, then update to the GA versions, stopped getting metrics to a whole bunch of custom collection scripts in my environment.  

Also be aware that OC-API 1.1 RC1 is not "perfect".  Example - the REST APIs still all use API version 1.0 in the URI.  The front page which documents the APIs hasn't changed.  BUT the APIs have actually changed, especially regarding the metrics.  There are tons MORE metrics available that are NOT documented in the front end web page.  The new metrics are listed in the documentation.  There are also a couple of subtle naming changes to the old metrics.  You will have to examine your code to see if changes are needed due to the additions and changes.  You cannot depend on versioning of the REST API because they didn't change the version in the REST call.

I've opened cases about all of these items - I'm hoping that the GA version addresses these topics.  For the moment, just to get data I'm having to rework significant chunks of code that were written depending on a stable and/or versioned API set typical of good REST implementations.

I hope this helps you.

Bob Greenwald

Lead Storage Engineer

Huron Legal | Huron Consulting Group

NCDA, NCIE - SAN Clustered, Data Protection

Kudos and accepted solutions are always appreciated.

[abhijit_bhagat]

Many Thanks Bob; For such a prompt and helpful response. Appreciated a lot :).

I am able to get the data for performance counters with API services 1.1.

As a side note any idea when this API version 1.1RC1 will get GAed.

Abhijit.

[marcinlub]

I'm getting the results with /aggregate/metrics however it's totally useless in my opinion. 

The results are reported for current moment and at least in my case if fluctuates very wiledly. 

I see headroom for the same aggregate changing within few seconds from 75% to 5%. I was hoping to use it for decision making in where to provision new LUNs but as it is it's not usable 😕 

Or is there a way to ask for metrics that would cover more than "NOW" (f.e. average for last 24hrs, last 7 days) ?