nieuws: Grote Cloudflare-storing werd niet door cyberaanval veroorzaakt maar ...
@YannickSpinner
@YannickSpinner
Dit is mijn inziens een verkeerde weergave van wat er hier geschreven is op het blog van Cloudflare:Het Bot Management-systeem is een tool die op basis van machinelearning bepaalt hoe betrouwbaar een bot zoals een scraper is. Op basis van die score kunnen klanten bepalen of zij een bot toelaten of blokkeren. Het configuratiebestand bevat het aantal functies die Bot Management mag gebruiken. Dit is handmatig begrensd op 200 om overmatige invloed op de prestaties van het systeem te voorkomen. Normaal heeft dat bestand grofweg 60 'features', maar het foutieve bestand bevatte meer dan het maximum aantal functies, waardoor het systeem op momenten minder dan de helft van alle verzoeken kon verwerken.
De oorzaak was wellicht meer configuratie items dan verwacht, maar de storing zelf kwam door een bug in een stukje code wat uit performance oogpunt een gemaximeerde hoeveelheid geheugen had gealloceerd voor de configuratie items (de 200) en dat er geen foutafhandeling was als er meer items waren.Each module running on our proxy service has a number of limits in place to avoid unbounded memory consumption and to preallocate memory as a performance optimization. In this specific instance, the Bot Management system has a limit on the number of machine learning features that can be used at runtime. Currently that limit is set to 200, well above our current use of ~60 features. Again, the limit exists because for performance reasons we preallocate memory for the features.
When the bad file with more than 200 features was propagated to our servers, this limit was hit — resulting in the system panicking. The FL2 Rust code that makes the check and was the source of the unhandled error is shown below: