REST Alerts list

[josepho]

The REST API currently only returns 20 alerts from GET /alert so it is possible to miss some alerts with a client. Is there a way to configure the REST sevice to return all the alerts curently in RHQ? 

[jayshaughnessy]

For some reason this is currently hardcoded.  It looks like a work in progress by Heiko.  It looks like there is a TODO in AlertHandlerBean.  If you're building from scratch that's the file you would want to tweek (line 100).

[pilhuhn]

While Jay is right about the WIP (patches welcome :-), there is a parameter 'page' that can be used to page through the list of fired alerts.

There is currently no linking implemented, so that there is no 'next' header for the next page.

Would it make sense so you to have an additional parameter 'pageSize' that overrides the standard size?

[josepho]

Yes, another parameter for 'pageSize' would be great. Also it would be very helpful if the 'pageSize' parameter would accept a value of 'all' or if there was another boolean parameter like: 'displayAll'=true|false to return all the alerts in one request. Although, just using the 'pageSize' parameter hopefully the alert count would never exceed Integer.MAX_VALUE .

[pilhuhn]

Hey,

while I can see the usefulness of such a "unlimited" page size (perhaps setting to -1 ?), I fear that this may with a large list of alerts (or other objects in the case of other endpoints), put too much (memory) burden on the server.

If you promise not to complain if your server runs out of memory, I could implement that :-)

Seriously: where do you see the usecase of such an "export all"? Could that be fulfilled via the .csv report?

[josepho]

Hi,

I think -1 would be a good value for the 'unlimited' setting at least better than passing in very large values as I had mentioned. Another idea would be to also add a page like /alertStats or even just a parameter to /alert that would return the total number of alerts and pages similar to the response message returned when an invalid page is requested. Although it would be nice if each value was its own field and not just part of a string like the current message is. This would allow a client to decide if it should request all the alerts at once, and if not it would know how many pages to request without doing it through trial and error.

I promise I will not complain about any additional server load. The server I am deploying RHQ on is a large blade cluster where the hardware resources can be considered relatively unlimited, but the api may need a disclaimer for others .

My use case for the export of all the alerts is:

• I have 200+ systems/VMs each with an agent that are part of a specific hierarchical tree structure
• The structure and status of the agents are being displayed in real time on a single custom web page for a high level master view
• Any alerts also need to have a notification displayed on this page in real time. Most of the metrics being collected are on 30 or 60 second intervals so all the alerts need to be collected every 30 seconds in case a new one was generated. I am currently just getting all the alert pages and combining them but if /alert could just return all the alerts in one request it would be much more convenient.

I think the CSV report could probably accomplish the same thing but using the REST service is preferred due to its ease of use. And can RHQ be set to export reports automatically to a specific directory on such a frequent schedule as mentioned above?