Forum Discussion

ES_CW's avatar
ES_CW
7 years ago

Get a list of alerts REST API

Hello all,

I am trying to get updates on alerts that span multiple days.  So, our normal code will grab new alert data for today, let's say.  However, we need to go back to old alerts and see if they have been resolved yet, so we can do accurate reporting.  What I want to do is provide a list of the IDs for a handful of alerts and get more than 1 row back.  Any ideas on how I can formulate an alert query so that I can get 2 rows back for, say ID=DS1234567 and ID=1234568 in the same request?

Here is my example call:

https://mysite.logicmonitor.com/santaba/rest/alert/alerts?filter=id:DS1275294,id:DS1472582

My hope is to combine a batch of calls so I don't flood the service and so I can get results faster.  Given a list of unique IDs, any thoughts on requesting a batch?

E

 

alerts
rest api

3 Replies

Sort By
Replies have been turned off for this discussion
  • Sarah_Terry's avatar
    Sarah_Terry
    Icon for Product Manager rankProduct Manager
    7 years ago

    @ES_CW it might be easier to filter requests based on time range instead (eg via something like filter=startEpoch>t1) - would that work for you? Currently the filter logic connects multiple values with an AND, which is why multiple IDs isn't working. We can look into adding the ability to connect with OR as well.

  • ES_CW's avatar
    ES_CW
    7 years ago

    Hi Sarah,

    Unfortunately, I don't think that will work.  We are looking at several thousand devices and a time-span starting at 04/01/2017.  It would be much harder on your servers and take much longer if I went that route.  I am starting at 4k alerts I am trying to update, but once I get an update for one that shows it as closed, I won't hit it again.  So I would imagine the numbers would drop a lot after the first execution.

    As for the ability to do an or operator, that would be really useful.  If it would be even easier to implement, you could have a syntax that would be like an "IN" clause in ANSI SQL.  That way you wouldn't have to parse operator precedence with "and" operators and "or" operators.  Just a thought.

    Thanks,
    Eric