[atlas]Can not target google.com with periodic measurement
Hi, there seems to be something wrong (?) with the measurement creation process, or maybe some rules have changed? I'm trying to schedule a toy measurement to google.com, however, as soon as I set the timing to periodic, I get the error message: "We do not allow more than 25 concurrent measurements to the same target: google.com" I am not running any measurements at the moment. This behavior is independent of the measurement type (ping, traceroute, SSL) and the number of probes (error appears with one probe requested). It seems to solely be a problem of the timing. So far this message only appears for google.com and 8.8.8.8, other targets work. If I schedule the measurement in the future, I can actually submit it, but get a "Scheduling denied" measurement, for example: https://atlas.ripe.net/measurements/75418006/details I don't know if this is related, but it seems like somebody is hammering Atlas with a large number of geolocation measurements (500 probes per measurement) and DNS lookups (1 probe) at the moment. In the last hour 5582 measurements were scheduled, which is 1.5 measurements per second! Best, Malte
Educated guess: this is a limit for a total over all users? Op wo 10 jul 2024 om 07:09 schreef Malte Tashiro via ripe-atlas <ripe-atlas@ripe.net>:
Hi,
there seems to be something wrong (?) with the measurement creation process, or maybe some rules have changed?
I'm trying to schedule a toy measurement to google.com, however, as soon as I set the timing to periodic, I get the error message:
"We do not allow more than 25 concurrent measurements to the same target: google.com"
I am not running any measurements at the moment. This behavior is independent of the measurement type (ping, traceroute, SSL) and the number of probes (error appears with one probe requested). It seems to solely be a problem of the timing.
So far this message only appears for google.com and 8.8.8.8, other targets work. If I schedule the measurement in the future, I can actually submit it, but get a "Scheduling denied" measurement, for example: https://atlas.ripe.net/measurements/75418006/details
I don't know if this is related, but it seems like somebody is hammering Atlas with a large number of geolocation measurements (500 probes per measurement) and DNS lookups (1 probe) at the moment. In the last hour 5582 measurements were scheduled, which is 1.5 measurements per second!
Best, Malte -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-leave@ripe.net
On 7/10/24 18:09, Mark Santcroos wrote:
Educated guess: this is a limit for a total over all users?
I am aware of the quotas described here [0], which describe the 25 measurement limit, but I understood them to be per user. If not, somebody could easily prevent others from performing measurements to a destination by scheduling 25 period measurements with one probe and an interval of a week or so. Btw. I had also two other users confirm to me that they have the same problem. [0] https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html#q...
Same is true for 9.9.9.9 and others, too many measurements already running against that target. I reckon RIPE does not want to be accused of spamming/ddos so there is a maximum. Regards, Ernst J. Oud
On 10 Jul 2024, at 11:55, Malte Tashiro via ripe-atlas <ripe-atlas@ripe.net> wrote:
On 7/10/24 18:09, Mark Santcroos wrote:
Educated guess: this is a limit for a total over all users?
I am aware of the quotas described here [0], which describe the 25 measurement limit, but I understood them to be per user. If not, somebody could easily prevent others from performing measurements to a destination by scheduling 25 period measurements with one probe and an interval of a week or so.
Btw. I had also two other users confirm to me that they have the same problem.
[0] https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html#q... <OpenPGP_0x7D82498BEF2E08F8.asc> -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-leave@ripe.net
Hi, Indeed, this is a global maximum against each target. We have two major reasons for this: * some targets can stand "any amount" of measuring, but most can't / shouldn't have to * once there are $thismany measurements against a particular target, there's a good chance the new ones are redundant and results from existing ones can be reused. Granted, this is not *always* the case. Technically this is just a configuration variable, we can change it. We can also add IPs / prefixes on a "bring it on!" list (allowlist). We also have a feature request to put entire ASNs on this list. In the meantime, I'd encourage you to look at the currently running measurements, to see if you can use their data. Regards, Robert On Wed, Jul 10, 2024 at 12:45 PM Ernst J. Oud <ernstoud@gmail.com> wrote:
Same is true for 9.9.9.9 and others, too many measurements already running against that target. I reckon RIPE does not want to be accused of spamming/ddos so there is a maximum.
Regards,
Ernst J. Oud
On 10 Jul 2024, at 11:55, Malte Tashiro via ripe-atlas <ripe-atlas@ripe.net> wrote:
On 7/10/24 18:09, Mark Santcroos wrote:
Educated guess: this is a limit for a total over all users?
I am aware of the quotas described here [0], which describe the 25 measurement limit, but I understood them to be per user. If not, somebody could easily prevent others from performing measurements to a destination by scheduling 25 period measurements with one probe and an interval of a week or so.
Btw. I had also two other users confirm to me that they have the same problem.
[0] https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html#q... <OpenPGP_0x7D82498BEF2E08F8.asc> -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-leave@ripe.net -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-leave@ripe.net
Hi Robert, thanks for the clarification, now I know it is not a bug. With that said, I think this necessitates some form of house-keeping task seeing how long Atlas has been active. I looked at the 25 running measurements (attached), assuming [0] is the right request: - 23 ping measurements, 1 traceroute, 1 SSL - 7 are dead (-> /latest endpoint returns no results) - Average participant count of 5 probes - None have a scheduled stop time - The last one was started on 2023-01-11, so it was not possible to schedule measurements targeting google.com since then? I know the Atlas developers always have a lot on their plate, so I won't ask for anything, but maybe it would make sense to have a process that notifies users of long-running / infinite measurements that did not return results since x amount of time due to probes getting disconnected if they want to add new probes or cancel the measurement. And if they don't reply for y time, force cancel the measurement (or exclude them from the limit). Anyways, at least now it is clear to me what is happening, so thank you. Best, Malte [0] https://atlas.ripe.net/api/v2/measurements/?status=2&target=google.com
Hi, I understand your point and recognise this is inconvenient at the moment. I'd say in the short term we can increase the limit - 25 is just a number like any other :-) - and perhaps administratively close the failing measurements. While I can't make promises about when, but in the longer term we can address this by looking at the the total results towards a target per time interval, instead of total measurements. Cheers, Robert On Thu, Jul 11, 2024 at 11:19 AM Malte Tashiro via ripe-atlas <ripe-atlas@ripe.net> wrote:
Hi Robert,
thanks for the clarification, now I know it is not a bug.
With that said, I think this necessitates some form of house-keeping task seeing how long Atlas has been active.
I looked at the 25 running measurements (attached), assuming [0] is the right request:
- 23 ping measurements, 1 traceroute, 1 SSL - 7 are dead (-> /latest endpoint returns no results) - Average participant count of 5 probes - None have a scheduled stop time - The last one was started on 2023-01-11, so it was not possible to schedule measurements targeting google.com since then?
I know the Atlas developers always have a lot on their plate, so I won't ask for anything, but maybe it would make sense to have a process that notifies users of long-running / infinite measurements that did not return results since x amount of time due to probes getting disconnected if they want to add new probes or cancel the measurement. And if they don't reply for y time, force cancel the measurement (or exclude them from the limit).
Anyways, at least now it is clear to me what is happening, so thank you.
Best, Malte
[0] https://atlas.ripe.net/api/v2/measurements/?status=2&target=google.com -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-leave@ripe.net
Hi, Considering this is about Google, I have just added google.com to our allow list. I also added 8.8.8.8 and will add the IPv6 version too. Cheers, Johan On Thu, 11 Jul 2024 at 13:56, Robert Kisteleki <robert@ripe.net> wrote:
Hi,
I understand your point and recognise this is inconvenient at the moment. I'd say in the short term we can increase the limit - 25 is just a number like any other :-) - and perhaps administratively close the failing measurements. While I can't make promises about when, but in the longer term we can address this by looking at the the total results towards a target per time interval, instead of total measurements.
Cheers, Robert
On Thu, Jul 11, 2024 at 11:19 AM Malte Tashiro via ripe-atlas <ripe-atlas@ripe.net> wrote:
Hi Robert,
thanks for the clarification, now I know it is not a bug.
With that said, I think this necessitates some form of house-keeping
task seeing how long Atlas has been active.
I looked at the 25 running measurements (attached), assuming [0] is the
right request:
- 23 ping measurements, 1 traceroute, 1 SSL - 7 are dead (-> /latest endpoint returns no results) - Average participant count of 5 probes - None have a scheduled stop time - The last one was started on 2023-01-11, so it was not possible to
schedule measurements targeting google.com since then?
I know the Atlas developers always have a lot on their plate, so I won't
ask for anything, but maybe it would make sense to have a process that notifies users of long-running / infinite measurements that did not return results since x amount of time due to probes getting disconnected if they want to add new probes or cancel the measurement. And if they don't reply for y time, force cancel the measurement (or exclude them from the limit).
Anyways, at least now it is clear to me what is happening, so thank you.
Best, Malte
[0]
https://atlas.ripe.net/api/v2/measurements/?status=2&target=google.com
-- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-leave@ripe.net -- ripe-atlas mailing list -- ripe-atlas@ripe.net To unsubscribe send an email to ripe-atlas-leave@ripe.net
participants (5)
-
Ernst J. Oud -
Johan ter Beest -
Malte Tashiro -
Mark Santcroos -
Robert Kisteleki