Now GA: Device Availability Change History

John-K
Meraki Employee
Meraki Employee

Now GA: Device Availability Change History

This endpoint returns the time-stamped availability change events that occurred for the organization's devices in the requested timespan, and is intended to be a hyper-efficient means of monitoring device availabilities. You can get started by calling:

 

 

GET /organizations/:organizationId/devices/availabilities/changeHistory

 

 

An empty result means there were no availability changes for any device in that organization for that timespan.

 

Default timespan is 1 day; maximum timespan is 14 days. Aside from the standard t0/t1/timespan controls, other filters include:

 

 

productTypes[]
networkIds[]
serials[]
statuses[]

 

 

Here's an example response, indicating that a single MV device changed from online > offline status, and subsequently changed back online status about 2 days later. It also indicates that no other device in the organization had any change in availability for that timespan.

 

JohnK_1-1689031684990.png

 

 

This can be used for many purposes, such as:

 

  1. Finding historical availability information for one or more devices. Has a device changed status around the time the user originally reported an issue? Now you can look back (up to 14 days) and find out!
  2. If you monitor device availability via API, then for stable networks, using this history endpoint will be far more efficient than polling availability (or statuses) for every device in the organization. Instead of gathering a ton of "online" data points, you can instead focus on the changes that might evidence an issue (or a resolution). The endpoint reveals only the changes during the timespan, so if you get an empty response, that means there were no changes.

    In other words, if you have gathered a complete picture as of a given timespan via polling an org's devices' availabilities (either via the /availabilities or /statuses endpoints), then you can subsequently switch to polling for changes from that snapshot, and get the differential data with which to update your locally cached information.
  3. Building the "Connectivity" bars the dashboard offers under Organization > Overview > Devices tab
  4. Sleeping easier at night, I hope!

Thanks to our Early API Access community for your valuable feedback during beta! This endpoint is now GA and we look forward to hearing how this new endpoint helps to streamline your workflows. 

7 Replies 7
Prodrick
Building a reputation

Hi, @John-K.  Can you clarify if this shows every availability (status) change during the given time frame?  For example, if a device were connected from 12:01AM to 9AM, then disconnected between 9AM and 3PM, then connected again from 3PM to 7PM, and finally disconnected for the remainder of the day... what would this endpoint tell us about the device?

Thanks so much!

Hi @Prodrick ! You'll see all the changes:

 

1. The first change at ~9am to offline

2. The second change ~3pm to online

3. The final change ~7pm to offline

 

You'll also see change events for that device if at any point in the process it was in "alerting" status.

Prodrick
Building a reputation

I love it!!! Thanks @John-K.  Since this is an org-level call, might this be a precursor to being able to get all events at the org-level without having to make network-level calls?  I ask because we have customers with thousands of networks where it's rate-limit prohibitive to use the network-level events endpoints.

Is this live in 135? 

The change history endpoint is live on all shards.

 

Which events endpoint(s) would you like to see aggregated at the organization level?

Prodrick
Building a reputation

Hi, @John-K.  This is the one I have my eye on, but it's expensive to make on a per-network call if you have thousands of networks.  However, If I could make per-org calls every 5-10 minutes to get these in bulk they'd be super valuable.

https://api.meraki.com/api/v1/networks/:networkId/events

Perhaps having it similar to this:

https://api.meraki.com/api/v1/organizations/:organizationId/appliance/security/events

However, I suspect that it these uber-large orgs we might have to do lots of paging if it's limited to 1000 per call.  I'll DM you with the customer-specific info, as there are two extremely large global Meraki Orgs that I have in mind for this.



Crocker
Building a reputation

Throwing my hat in for this one as well. An org-level event log would be excellent.

 

Another that could benefit from org-level aggregation would be:

 

https://api.meraki.com/api/v1/networks/$networkId/health/alerts

sungod
Head in the Cloud

Catching up on testing after covid, this post has been edited as I went along...

 

The old/new details arrays can differ in size, either can be zero, I've not seen either >2

 

The only time I see size >1 is where the first element just says it's an alert, and the second says what the alert is/was.

 

As the call is GA now, probably too late, but if it were me I'd have simplified and put the alert description in the value rather than have detail arrays.

 

Or are there other instances where array will be >1 ?

 

total elementstimestampmodellold nameold valuenew namenew value
42023-07-19T21:17:25.795000ZMS350-48LPstatusalertingstatusalerting
42023-07-19T21:17:25.795000ZMS350-48LPalertDHCP failure on management VLANalertDisabled gateway (bad DNS)
42023-07-19T21:17:25.779999ZMS350-48LPstatusalertingstatusalerting
42023-07-19T21:17:25.779999ZMS350-48LPalertDHCP failure on management VLANalertDisabled gateway (bad DNS)
32023-07-19T23:59:07.091000ZMS350-48LPstatusonlinestatusalerting
32023-07-19T23:59:07.091000ZMS350-48LP  alertDHCP failure on management VLAN
32023-07-19T23:59:07.036999ZMS350-48LPstatusonlinestatusalerting
32023-07-19T23:59:07.036999ZMS350-48LP  alertDHCP failure on management VLAN
32023-07-19T21:19:29.835000ZMS350-48LPstatusalertingstatusonline
32023-07-19T21:19:29.835000ZMS350-48LPalertDisabled gateway (bad DNS)  
32023-07-19T21:19:29.818000ZMS350-48LPstatusalertingstatusonline
32023-07-19T21:19:29.818000ZMS350-48LPalertDisabled gateway (bad DNS)  
32023-07-19T21:18:30.970999ZMX67statusalertingstatusonline
32023-07-19T21:18:30.970999ZMX67alertDisabled gateway (bad DNS)  
32023-07-19T21:18:15.997999ZMX67statusofflinestatusalerting
32023-07-19T21:18:15.997999ZMX67  alertDisabled gateway (bad DNS)
32023-07-19T21:17:25.653000ZMS350-48LPstatusalertingstatusonline
32023-07-19T21:17:25.653000ZMS350-48LPalertDHCP failure on management VLAN  
Get notified when there are additional replies to this discussion.