2012-10-14 24 views
6

Facebook có thực hiện một số trình thu thập dữ liệu web không? Trang web của tôi đã bị lỗi vài lần trong vài ngày qua, bị quá tải nghiêm trọng bởi các IP mà tôi đã truy tìm lại trên Facebook.Facebook Crawler Bot Crashing Site

Tôi đã thử tìm kiếm xung quanh nhưng không thể tìm thấy bất kỳ tài nguyên dứt khoát nào liên quan đến việc kiểm soát bot trình thu thập thông tin của Facebook thông qua robots.txt. Có một tài liệu tham khảo về việc bổ sung như sau:

User-agent: facebookexternalhit/1.1 Crawl-delay: 5

User-agent: facebookexternalhit/1.0 Crawl-delay: 5

User-agent : facebookexternalhit/* Thu thập thông tin chậm trễ: 5

Nhưng tôi không thể tìm thấy bất kỳ tham chiếu cụ thể nào về việc bot Facebook tôn trọng robots.txt hay không. Theo các nguồn tin cũ hơn, Facebook "không thu thập thông tin trang web của bạn". Nhưng điều này chắc chắn là sai, vì nhật ký máy chủ của tôi cho thấy họ thu thập dữ liệu trang web của tôi từ một tá + IP từ phạm vi 69.171.237.0/24 và 69.171.229.115/24 với tốc độ nhiều trang mỗi giây.

Và tôi không thể tìm thấy bất kỳ tài liệu nào về điều này. Tôi nghi ngờ nó là một cái gì đó mới mà FB chỉ thực hiện trong vài ngày qua, do máy chủ của tôi không bao giờ bị rơi trước đó.

Ai đó có thể xin lời khuyên?

+0

Có, một cái gì đó gần đây đã thay đổi khi nó bắt đầu đâm chúng tôi lần đầu tiên trong 8 năm chúng tôi đã được xung quanh. Giả sử họ đang "cập nhật opengraph của họ". Tuy nhiên, nhìn vào các trang của chúng tôi nó đang yêu cầu (rất ít trang tối nghĩa), tôi tự hỏi nếu một bot hợp pháp đang thực hiện javascript, và kéo vào các nút tương tự, kích hoạt một bản cập nhật FB OpenGraph. Đó chỉ là một linh cảm ... – Stickley

+0

Câu hỏi liên quan: http://stackoverflow.com/questions/11521798/excessive-traffic-from-facebookexternalhit-bot?lq=1 và http://stackoverflow.com/questions/7716531/ facebook-and-crawl-delay-in-robots-txt? lq = 1 – Stickley

+0

Cảm ơn lời đề nghị và tài liệu tham khảo của bạn, Hank. Trong một biến cố của sự kiện, trang web của tôi đã bị choáng ngợp với hàng tá truy cập mỗi giây, trong một vài giờ vào ngày 8 và 9 tháng 11. Nhưng lần này - không phải Facebook, mà là Amazon. Nó đột nhiên bắt đầu xáo trộn một lượng lớn các liên kết trong trang web, nhưng dường như không có bất kỳ mô hình rõ ràng nào - một số trang được truy cập là những trang tối nghĩa/cũ, trong khi một số trang mới nhất. Tự hỏi liệu họ có đang làm mới cơ sở dữ liệu công cụ tìm kiếm của riêng mình hay không. – Andy

Trả lời

0

Bất cứ điều gì facebook phát minh ra bạn chắc chắn cần phải sửa chữa máy chủ của bạn vì nó có thể sụp đổ nó với các yêu cầu bên ngoài.

Ngoài ra, chỉ là một hit đầu tiên trên google cho facebookexternalhit: http://www.facebook.com/externalhit_uatext.php

+0

Cảm ơn. Tôi đã kiểm tra rằng trang FB uatext, mặc dù nó không cung cấp bất cứ điều gì cụ thể. Các trang đang gặp sự cố máy chủ của tôi là từ phần blog Wordpress chứa một vài nghìn bài đăng. Thật không may, động cơ không đủ hiệu quả ngay cả với tất cả các chỉnh sửa và cài đặt quickcache, và cách duy nhất tôi có thể nghĩ là khắc phục nhanh là triển khai chậm trễ thu thập dữ liệu robots.txt, nhưng tôi không biết FB có tôn trọng hay không. Tôi đã không có vấn đề với Google thu thập thông tin mặc dù vì nó được lan truyền trong suốt cả ngày. FB pounces trên tấn của tất cả các trang tại một trong những đi và giết chết máy chủ. – Andy

+0

Tôi có thêm một lý do tại sao tôi không thích FB :) – Serge

1

Chúng tôi thấy hành vi tương tự vào khoảng cùng thời gian (giữa tháng mười) - lũ yêu cầu từ Facebook gây ra các yêu cầu xếp hàng đợi và sự chậm chạp trên toàn hệ thống. Để bắt đầu với nó cứ 90 phút một lần; trong vài ngày, tần số này tăng lên và được phân phối ngẫu nhiên.

Các yêu cầu xuất hiện không tôn trọng robots.txt, vì vậy chúng tôi buộc phải nghĩ đến một giải pháp khác. Cuối cùng, chúng tôi thiết lập nginx để chuyển tiếp tất cả các yêu cầu với một useragent facebook đến một cặp máy chủ phụ trợ chuyên dụng. Nếu chúng ta đang sử dụng nginx> v0.9.6 chúng tôi đã có thể làm một regex đẹp cho điều này, nhưng chúng tôi không, vì vậy chúng tôi sử dụng một ánh xạ dọc theo dòng của

map $http_user_agent $fb_backend_http { 
      "facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)" 
        127.0.0.1:80; 
    } 

này đã làm việc độc đáo cho chúng ta; trong vài tuần mà chúng tôi đã nhận được búa này phân vùng yêu cầu giữ lưu lượng truy cập cao đi từ phần còn lại của hệ thống.

Dường như phần lớn đã chết cho chúng tôi bây giờ - chúng tôi chỉ thấy những lần tăng đột ngột. Tại sao điều này xảy ra, tôi vẫn không chắc chắn - dường như có một sự cố tương tự vào tháng Tư là do lỗi http://developers.facebook.com/bugs/409818929057013/ nhưng tôi không biết bất cứ điều gì tương tự gần đây hơn.

+0

Cảm ơn bạn đã chia sẻ. Tôi đang sử dụng Apache - hy vọng họ có một cách tiếp cận tương tự để yêu cầu ánh xạ lại bởi tác nhân người dùng. Nhưng điều đó sẽ cho rằng tôi có một máy chủ tốt khác để loại bỏ các truy cập động này vì chúng không phải là các trang tĩnh, nếu không tôi sẽ phải loại bỏ hoàn toàn các yêu cầu và hy vọng FB không coi trang web của tôi là không hợp lệ. Tương tự như những gì bạn quan sát thấy, sự việc đã dừng ngay sau đó. Nó có thể là một số quy trình FB của cỏ khô - nhưng nó chắc chắn là một thực tế tồi tệ ở cuối của họ không phải để tôn trọng robots.txt. – Andy

2

Như được thảo luận trong in this similar question on facebook and Crawl-delay, facebook không tự coi mình là bot và thậm chí không yêu cầu robots.txt của bạn, ít chú ý hơn đến nội dung của nó.

Bạn có thể triển khai mã giới hạn tốc độ của riêng bạn như được hiển thị trong liên kết câu hỏi tương tự.Ý tưởng là chỉ cần trả lại mã http 503 khi máy chủ của bạn vượt quá dung lượng hoặc bị tràn ngập bởi một tác nhân người dùng cụ thể.

Có vẻ như những người làm việc cho các công ty công nghệ lớn không hiểu "cải thiện bộ nhớ đệm của bạn" là một công ty nhỏ không có ngân sách để xử lý. Chúng tôi đang tập trung vào việc phục vụ khách hàng thực sự trả tiền và không có thời gian để chống lại các chương trình web cuồng nhiệt từ các công ty "thân thiện".