Feature Request - Atlas Latest
Hello Atlas, I would like to request an additional API call which just returns the latest results for a specific measurement. For use cases I would point you to the "RIPE Atlas - Map Visualisations²[1]. I have also seen places in the dnsmon beta where you only show the latest results. this would also be very useful for trouble shooting, if I see an issue its inconvenient to download xMB of json data just to see the whats going on now. An additional feature would be to ask for a result for X seconds in the past, the call would return a result closest to that time. This is for investigating historic events, if I have an issue that lasts one hour I would normally only need one result to perform the initial investigation. This would also be useful to have a history/timeline function to the maps[1]. The following code at the end of this mail does something similar to what I would like using the current API. By setting GO_BACK_IN_TIME=0 you should get the most recent measurement. However this is not perfect, depending on what value one sets the INTERVAL do you may get multiple results or now may get none and as far as I can tell this dose not relate to the measurement Interval. The other issue with queuing the results like this is that you get a lot of superfluous data. I.e. For the dns measurement in the script below you get result[answers][RDATA] and result-rdata which both seem to have the same data. Furthermore when in a script im not to interested in the probe and measurement details. If I am, I will request that information from the appropriate probe or measurement api call. For the DNS measurement a structure like the following would suite my needs { probe_id: { abuf: str, timestamp: int, result: { additional: str, question: str, authority: str, opcode: str, answer: str, flags: str, rcode: str, id: int }, response_time: float } } Thanks John #/bin/sh GO_BACK_IN_TIME=86400 INTERVAL=240 NOW=$(date +%s) MSG_ID=1423370 URL="https://atlas.ripe.net/api/v1/measurement/${MSG_ID}/result/?stop=$((NO W - GO_BACK_IN_TIME))&start=$((NOW - GO_BACK_IN_TIME - FREQUENCY))&format=json" echo ${URL} wget -q "${URL}" -O - [1]https://atlas.ripe.net/results/maps/
On 14/03/14 15:34, John Bond wrote:
I would like to request an additional API call which just returns the latest results for a specific measurement. For use cases I would point you to the "RIPE Atlas - Map Visualisations²[1]. I have also seen places in the dnsmon beta where you only show the latest results. this would also be very useful for trouble shooting, if I see an issue its inconvenient to download xMB of json data just to see the whats going on now.
I wrote this call yesterday actually, though it'll still be a few weeks before it sees the light of day. We recently updated our datastore table structure to allow simpler querying of the latest results, so this call is now relatively low-cost to our infrastructure. I'm currently in the process of porting it to work against all of our measurement maps, including the new measurement pages, so they will probably be released at the same time.
An additional feature would be to ask for a result for X seconds in the past, the call would return a result closest to that time. This is for investigating historic events, if I have an issue that lasts one hour I would normally only need one result to perform the initial investigation. This would also be useful to have a history/timeline function to the maps[1].
Unfortunately, because of how we store the data, we can't simply grab a perfect set of results nearest time X. At best, I can give you that which you've already accomplished with your snippet of code here: Take all results within a designated window, loop over them, throwing out duplicates by probe id, returning the remainder. It would require the server to do much of the work you've managed to do client-side, in only a few lines, so there isn't a lot of motivation on our side to do it... yet. We do have intentions to make the maps you mentioned historically relevant, at which point such a call may make more sense. I can't make any promises here though. Keep an eye on the list and we'll announce when the new latest call is ready :-)
Hi Daniel On 14/03/14 17:47, "Daniel Quinn" <dquinn@ripe.net> wrote:
On 14/03/14 15:34, John Bond wrote:
I would like to request an additional API call which just returns the latest results for a specific measurement. For use cases I would point you to the "RIPE Atlas - Map Visualisations²[1]. I have also seen places in the dnsmon beta where you only show the latest results. this would also be very useful for trouble shooting, if I see an issue its inconvenient to download xMB of json data just to see the whats going on now.
I wrote this call yesterday actually, though it'll still be a few weeks before it sees the light of day. We recently updated our datastore table structure to allow simpler querying of the latest results, so this call is now relatively low-cost to our infrastructure. I'm currently in the process of porting it to work against all of our measurement maps, including the new measurement pages, so they will probably be released at the same time. Great news Thanks
An additional feature would be to ask for a result for X seconds in the past, the call would return a result closest to that time. This is for investigating historic events, if I have an issue that lasts one hour I would normally only need one result to perform the initial investigation. This would also be useful to have a history/timeline function to the maps[1].
Unfortunately, because of how we store the data, we can't simply grab a perfect set of results nearest time X. At best, I can give you that which you've already accomplished with your snippet of code here: Take all results within a designated window, loop over them, throwing out duplicates by probe id, returning the remainder. It would require the server to do much of the work you've managed to do client-side, in only a few lines, so there isn't a lot of motivation on our side to do it... yet. We do have intentions to make the maps you mentioned historically relevant, at which point such a call may make more sense. I can't make any promises here though.
Understood I can live with doing this client side. Thanks John
participants (2)
-
Daniel Quinn -
John Bond