Uvádíte hodnotu Crawl-delay v robots.txt? Přetěžují roboti Vaše servery?

Hezké odpoledne, mám dotaz na zdejší správce serverů a provozovatele webových aplikací. Dnes se nám po webech potlouká běžně několik desítek různých crawlerů a již dlouho není takový robot výsadou velkých vyhledávačů. Máme zde ty "zlé", ale i ty hodné které na webu třeba i chceme, ale hlavně se chovají slušně, tedy snaží se server nepřetežovat stovkami konkurenčních spojení. Předpokládám, že první skupinu bude velká část z Vás blokovat a to jak dle IP adres, tak třeba i user-agenta. Zajímá mě však ta druhá skupina, tedy ta, co se snaží chovat se ohleduplně. K té bych měl pár dotazů.

Snažíte se omezit jejich nenasytnost uvedením nestandardní hodnoty Crawl-delay v robots.txt? Podporuje to vůbec někdo z Vás, nebo čeká tento parametr stejný osud jako třeba hlavičku DNT, kteoru podporuje promile serverů a nemá cenu jej brát v potaz?

Řešíte nějak přetěžování ať jich technicky, či třeba požadavkem na vyloučení z indexování? Nebo to prostě berete jako součást dnešní doby a máte servery dostatečně dimenzované i na tato krátkodobá vytížení?

V případě že byste zjistili nadměrný provoz, uvítali byste (po ověření domény) možnost nastavit si rozestup requestů v nějaké administraci, obdobně jako třeba v GWT? Obecně mě zajímá, zda takový případ řešíte rovnou blokací, nebo se snažíte robota pouze usměrnit?

Podvrháváte robotům záměrně jiný obsah? Detekujete je dle user-agenta, nebo spíše podle nestandardního chování typu příliš requestů/s? (nemusíte odpovídat pokud nechcete :o) )

Díky za reakci... Pokud máte jiný tip jaké chování byste očekávali, budu také rád. Třeba typu více aktivity v nočních hodinách, atd (určeno pro CZ trh, tedy v 1 časovém pásmu). Dynamické přizpůsobení počtu dotazů dle rychlosti reakce serveru je v plánu.

Kolik požadavků za sekundu je problém? Pokud web shodí už roboti, tak nejspíš nepřežije ani žádnou špičku návštěvnosti, takže bych problém hledal jinde.

1) ne, nefunguje to, ti hodní to dodržují, ale ti nejsou problém2) throttlujeme podle AS pod kterým IP je, historii držíme 30 dnů3) ne, robot má sám poznat, že je škodná, aktivně něco nastavovat někde u desítek různých robotů je opruz4) ne, nerozlišujeme mezi roboty a návštěvníky jinak než podle vytížení zdrojů. Hranice je tenká a false positive je problém, ti špatní roboti podvrhávají hlavičkysouki: Ano, i crawler dokáže shodit web, zdravím yandex, který i dnes občas chytner rapl a na větší web je schopný hodit milion requestů za hodinu, většinou se ale chová podle toho, jak mu rychle web odpovídá. Občas se objeví nějaký nemotorný robot (ať script kiddies, konkurence nebo někdo z Ghany), který spamuje na api stovky až tisíce requestů/s a ano, to nám dělá na některé vzácné zdroje problémy a musíme ho zpomalit.ad 2) Máme na tohle jednoduchou logiku, grupujeme přístupy podle AS a nastavujeme automaticky throttling těm, které prostě dělají problémy a které berou drahé zdroje. Sčítáme časy jednotlivých requestů na backend a limity máme ve spotřebovaných sekundách za nějaké časové okno (15 min, hodina atd.). K tomu samozřejmě se lehce čachruje s geo ip, regionem atd. Máme celosvětový projekt a občas je problém tohle uhlídat ručně a roboti jsou občas mrchy, hm nebo neposlušní klienti, kteří nás také někdy DoSují. Pro ČR to může funguje všeljak, chce dát pozor na whitelistování poskytovatelů internetu, velcí operátoři mají prostě mnooooho IP adres a může to v lokálním rozměru dělat neplechu. Požadavek je klasicky ve frontě max. 30s a poté dostane 503, sledujeme velikost fronty na proxy a grafujeme.Nejdůležitější je ale vše logovat, sledovat a až poté omezovat a dělat represe. Dobrá zásada je, že na backend nepustíš víc requestů než na kolik ho máš otestovaný a kolik stabilně zvládne, to se liší samozřejmě cestu od cesty. Stejně tak je vždy slepá cesta se rozhodovat podle hlaviček, které ti druhá strana poskytne, to je dobré pro analýzy chování a korelace, nikoliv pro omezování, protože je může kdokoliv podvrhnout. Pokud máš problém s přětěžování i od těch "hodnotých" robotů jako google, máš projekt špatně dimenzovaný.Jen pro zajímavost, relativně často roboti spamují přihlašovací formulář pro heslo a občas to chytne cpu na aplikáči.

Souki + TomášX: Díky oběma za reakci ;)Aby nedošlo k nedoruzumění.. Já se nesnažím robotům bránit, crawler vytvářím, pouze bych rád respektoval nějaké zásady, proto tento dotaz :)Účel robota je trošku odlišný od běžného indexovacího a proto se bude mírně lišit i jeho chování. Nemám v plánu nijak zvlášť simulovat návštěvníka, je to robot a jako robot se bude chovat, přístupy ale musí být řízené, jelikož pojede ve 2 instancích na 1Gbps linkách, což by mohlo být pro drobná VPS problém v případě souběhu procházení více webů v rámci 1 serveru. Bude k dispozici i 1 worker na "kontrolní" dotazy, kdy bude schopen v případě podezření na podrvhávání obsahu provést nový dotaz se standardním user agentem a z geolokačně jiného místa, ale nebude to běžné chování těch primárních instancí.V zásadě mám ale spíše jiná dilemata. Z povahy projektu nás zajímá pouze určitá skupina stránek a to pouze v CZ jazyce, bez ohledu na doménu. Zde balancuji před výběrem menšího zla, kdy obsah stránky včetně jazyka odhalím až po jejím stažení a tedy na nějakém větším vzorku zjistím, že mě nezajímá (wiki, zpravodajský web,..).Technicky by šlo "zkusit" nalézt pro nás podstatný obsah vyzkoušením url typu cs.domena.com, domena.com/cs, shop.domena.com, atd, ale zase bych na serverech generoval 404. Otázka tedy je, co je z pohledu poskytovatelů přípustnější, zda prubnout HP + pár desítek náhodných stránek a případně otestovat "obvyklé" URL které nás většinou zajímají, nebo prostě striktně jít po odkazech s tím, že provedu třeba 200k zbytečných requestů na server. Zajímá nás text + obrázky, ostatní obsah je irelevantní. Cílem je získat určité indicie pro další posouzení, nikoliv provést 100% analýzu obsahu :)

krátce řečeno, měl bys ses chovat jako se chová Nutch od Apache, striktně udržovat určitý počet souběžný dotazů na jeden server, při delší odezvě zvednout internval mezi dotazy, v případě errorů odložit frontu i o několik hodin.Dále si asi budeš muset pohrát s nastavením tcp stacku v kernelu, to ale asi víš.Pokud jde o české weby, nejjednoduší je si vytáhnout z ripe.net seznam ip adres a jejich registrovaných poloh (inetnum, inet6num) a vytáhnout si jen ty pro cz, tím máš velkou skupinu potenciálně českých webů a lze čekat, že jejich výchozí jazyk bude cz a zjistíš ho z meta tagů.U těch nadnárodních domén s českou mutací to je horší, první je získat seznam, já vždy slušně vykradl ty různé podvodné katalogy, řada se jich tam registruje. Další dobrý seznam mezinárodních domén je http://aws.amazon.com/datasets/common-crawl-corpus/, kde se dá z metadat získat adresy domén.Pokud jde o kontrolu jazyku, hodně se mi vyplatilo porovnat jak moc se liši obsah pro požadavek s http hlavičkou Accept-Language: en a Accept-Language: cs. Řada webů to zohledňuje. Jinak bych asi stáhl homepage a hledal bych odkaz na přepnutí jazyku pokud by už samotná stránka nebyla v cz.Další dobrý zvyk je nepoužívat sekvenční procházení, ale mít inteligentní planner, který požadavky na jeden server rozhodí do časového okna souměrně. Je také dobré použít jazyk, který je dostatečně nízkoúrovňový, aby se dalo dobře pracovat s tcp - php, node.js, ruby to nejsou a s javou je sraní než to člověk vyladí. Většinou jsem v podobných věcech šáhl po pythonu nebo c, erlang je v tom ale naprosto famózní a přesně tohle je jeho doména a dokáže konkurovat i optimalizovaným c knihovnám. Na prvotní zjištění jestli IP adresa vůbec žije a jestli tam běží nějaký server je neskutečný https://github.com/robertdavidgraham/masscan, tím ulehčíš svým workerům, aby už stahovali pouze ze serverů, které existují. Stejně tak resolvování dns je lepší udělat offline dopředu, mám vykradenou knihovnu https://github.com/miekg/dns, lze ale použít i dig -f, rozhodně to ale nedělej až na úrovni crawleru a získej to dopředu, výrazně s tím zvýšíš výkon. Lokální resolver s cache je samozřejmost.2 instance na 1gbit linkách je mrhání, nevěřím, že je dokážeš vytěžit a stejně většinu času budeš čekat na IO. Já klasicky jedu v 2000 threadech a každý z nich dostává adresy z planneru, který chystá frontu tak, aby udržel určitou konkurenci a aby nepřetěžoval vzdálený server. Dopředu si nachystám pro každý požadavek domain, path, ip, port, headers (session, language, agent), timeout, protocol, accepted headers. Worker odevzdá výsledek do databáze a planner hned podle výsledku upraví frontu. Dělal jsem experimenty pro jeden vyhledávač, teď mi takhle běží pár robotů, kteří sbírají open data na další zpracování.

Díky za obsáhlou odpověď.V zásadě jsem nad tím přemýšlel podobně, pár věcí však plánuji odlišně, kvůli požadovanému účelu. Pokud jde o nějaké výchozí adresy, těch seznamů mám k dispozici několik. Jednak to jsou nějaké katalogy eshopů, výstupy z nejmenovaného srovnávače, řádově jednotky stovek domén. Tento seznam je nejdůležitější, protože pro nás budou výsledky tím relevantnější, čím užší bude propojení nalezené URL s výchozím bodem. Mám ale také nějaký whitelist (wikipedia, novinky, idnes,...) a rovněž blacklist již nyní zájmových.Žádný planner užit nebude. V tomto nejde primárně o projití co možná největšího počtu URL, ale naopak analýza a nalezení možné zájmové adresy. Z tohoto důvodu nepůjdu cestou klasických crawlerů kteří si do stacku ukládají všechny nalezené URl a v jiném vlákně je dále prochází, ale na základě analýzy se on-demand rozhodne, zda bude pokračovat nebo bude bude všechny výsledky z této stránky, nebo dokonce celé domény ignorovat. Cílem totiž je, najít stránky obsahující požadované prvky a ty teprve oštítkovat, ostatní nás nezajímají. Nemá pro mě tedy smysl provádět analýzu post-process a v případě nezájmu zahodit již 30k stránek z fronty.Pojede to na linuxových strojích, takže jako DNS resolver je k dispozici BIND. Nicméně bude s prázdnou cache, takže je otázka, jestli to má přínos, protože necachovaný dotaz stejně forwarduje. 2 instance jsou z jiného důvodu než zvýšení rychlosti. Primární půjde po obsahu a sekundární bude provádět analýzu obrázků (pouze podobnost s předem danými vzory) pomocí OpenCV, což je časově podstatně náročnější. Mezi nimi bude fronta s RabbitMQ.V zásadě se to pak má chovat tak (náš cíl), že začne procházet odkazy z předem daného seznamu a když narazí na nový externí link, provede na pár desítek requestů analýzu, jestli má cenu se domény/subdomény držet a dle toho zařadí případně na WL. V případě že půjde dále, bude zkoumat obsah jednotlivých URL a nalezené obrázky rovněž předávat druhému workeru. Jestli na URL zjistí něco, co nás zajímá, doménu a konkrétní URL odešle na BL k ručnímu ověření. V tom vyhodnocovacím procesu pak bude hrát roli i to, jak je url daleko od výchozího seznamu, tedy opět blog se 4 příspěvky na které jsme se dostali přes 80 jiných webů má pro nás menší hodnotu, než shop propagovaný třeba na heuréce. Whitelistované domény se budou rescannovat až po několika měsících, tedy pokud nedojde k ručnímu zásahu.Každopádně díky, šlo mi primárně o to, aby se robot když už to procházet musí choval ohleduplně a nenasíral zbytečně provozovatele ;)