- ripe-atlas - mailman.ripe.net

Atlas API stream broken?
by Teun Vink 10 Feb '20

10 Feb '20

Hi, Since ~13.30h CET this afternoon our Atlas data stream subscriptions (using the ripe.atlas.cousteau python library) stopped receiving updates. Earlier today we (at 11.27h) observed some issues with the backend where we received redis errors, which were resolved at ~12.09h CET. I heard these were related to some firewall issues, could these problem be related? Regards, -- Teun Vink BIT | teun(a)bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE

2 1

Graphs and measurements are scaled by a factor of 1000
by Enrico Ardizzoni 07 Feb '20

07 Feb '20

Starting from 06/02/2020 at 6.00 AM UTC all graphs and measurements are scaled by a factor of 1000. Something went wrong on probes backend... "An error occurred while retrieving measurement data. We apologise and do our best to fix it asap!" See: https://atlas.ripe.net/probes/249/#!tab-builtins https://atlas.ripe.net/probes/12120/#!tab-builtins E. -- | ENRICO ARDIZZONI | Responsabile Ufficio Reti e Sistemi | Università degli Studi di Ferrara

2 3

Planned Atlas downtime on 29 January
by Robert Kisteleki 06 Feb '20

06 Feb '20

Dear RIPE Atlas users, Please be aware that we plan to do maintenance work in the RIPE Atlas core infrastructure two weeks from now, on Wednesday 29 January, between 9:00-12:00 CET (Amsterdam time). The RIPE Atlas website, UI and API will be unavailable in this period. The probes should remain connected and results will be collected normally, although during this period they can only be accessed real-time via the streaming service. Apologies for the inconvenience this may cause. Regards, Robert Kisteleki

2 3

Using Atlas for Monitoring of Anycast DNS
by Klaus Darilion 20 Jan '20

20 Jan '20

Hello! I want to restart this old thread and ask for available tools. For our Anycast DNS cloud, I want to measure the "performance", ie the RTT from Atlas probes. 1. Create measurements (I can do that already ;-) 2. Analyze this measurements: - fetch measurement - analyze the probe locations (ie. country, continent) - create reports with average RTT from certain countries and continents This second step I have partly in old scripts using influxdb and grafana dashboard - but that was a proof of concept with bad code. So, before starting coding from the base - are there some available scripts which can do the second part? Is https://github.com/RIPE-NCC/ripe.atlas.sagan still the way to go for measurement processing or are there meanwhile some better/smarter libraries? ie something for php? Thanks Klaus Am 20.11.2014 um 16:32 schrieb Klaus Darilion: > Hi! > > I want to monitor an Anycasted authoritative name server: > - are all nodes responding > - are all nodes in routing > ... > > > So I thought about starting a long term DNS measurement with plenty of > probes and NSID queried. Then, checking the results I should see every > possible NSID if there are for more probes than Anycast-nodes. > > Does anybody have done that (or similar) already and want to share code? > > Can the RIPE Atlas Status Checks be used for such monitoring? > > Thanks > Klaus >

4 4

Probe is offline but shown online
by Andre Heinrichs 19 Jan '20

19 Jan '20

I’ve just discovered my probe #29384 blinking frantically while the website claims it had been online for more than a day (which can’t be true as my DSL had to get a new connection with a different IP). I tried rebooting the probe but all that got me is lower values of Power-Up time in the SOS requests the probe sends every couple of minutes. From what I can guess it looks like something in RIPE ATLAS isn’t working right. Would be great if someone could have a look. TIA, Andre, Who’s trying to get some sleep now.

3 2

Probe stability tags
by Chris Amin 08 Jan '20

08 Jan '20

Dear RIPE Atlas users, Due to an error in our backend systems, the probe stability tags ("system: IPv4 Stable 30d" etc) had been gradually becoming stale over the past three months, meaning that probes were not gaining or losing these tags when they should. This has now been fixed, so probes are once again tagged appropriately. We have improved our internal monitoring so this kind of issue will be noticed more quickly next time. Apologies for any inconvenience caused. Kind regards, Chris Amin RIPE NCC

1 0

New RIPE Atlas Terms&Conditions
by Robert Kisteleki 08 Jan '20

08 Jan '20

Dear RIPE Atlas users, We'd like to inform you that a new version of the RIPE Atlas Terms & Conditions has just been published. Most changes in this version are needed for the introduction of "software probes". The new version (3.4) is available at https://atlas.ripe.net/legal/terms-conditions/ and will be effective as of 11 February 2020. Regards, Robert Kisteleki

1 0

Maintenance or incident?
by Stephane Bortzmeyer 07 Jan '20

07 Jan '20

% curl https://atlas.ripe.net/ curl: (7) Failed to connect to atlas.ripe.net port 443: Connection refused It started around 1015 UTC.

4 4

A new year's break for the probes
by Robert Kisteleki 03 Jan '20

03 Jan '20

Happy new year to all RIPE Atlas users! It seems we've given a little break to our probes so they can celebrate the new year too ... >From midnight 1 January until approximately noon 2 January there were no built-in measurements running. This is due to an overlooked fact where the built-in measurements had a pre-defined end date of 2020-01-01. The system dutifully observed this date and did not schedule these measurements any more. We fixed this setting on Thursday, 2 January and the system returned to normal operations shortly thereafter. As a consequence, there's a gap in the delivered measurement results for built-in measurements (i.e. IDs < 1 million). Results for the User-Defined Measurements were not affected. Please accept our apologies for the inconvenience this can cause. Regards, Robert Kisteleki

2 2

One-off measurements not terminating
by Steve Gibbard 30 Dec '19

30 Dec '19

Hi Atlas folks, I hope you’re having a good holiday season. Sorry to interrupt it by complaining about issues. On Christmas Eve my time (early Christmas morning your time) there was an Atlas issue where any attempt at reading measurements failed with an HTTP 500 status error. That appears to have gotten fixed on Christmas (a really big thank you to whoever worked on that) but since then it appears that while most of the one-off measurements we’ve created have delivered results very quickly, none of the measurements created since 17:00 UTC on 2019-12-25 have stopped running. As shown in the Atlas portal: 23722197 Traceroute www.globaltraceroute.com (AS13335) Test Traceroute 1 one-off 2019-12-25 22:24 Never 23722089 Traceroute archive.ubuntu.com (AS41231) Test Traceroute 1 one-off 2019-12-25 19:16 Never 23722088 Traceroute sps.prima.com.ar (AS10318) Test Traceroute 1 one-off 2019-12-25 19:14 Never 23721915 Traceroute www.globaltraceroute.com (AS13335) Test Traceroute 1 one-off 2019-12-25 17:00 Never And on for every measurement between then and now. Previously, the typical one-off measurement was listed with start and stop times less than 10 minutes apart. When a user has 100 measurements running concurrently, creation of new measurements fails, which is happening for me now. If somebody could take a look at this, I’d really appreciate it. Thanks, Steve

2 3