Monitoring ו-Alerting למערכות Scraping: המדריך המלא

למה רוב ה-scrapers רצים על עיוור (וזה עומד לעלות לכם ביוקר)

בנינו scraper. הוא עובד. אנחנו מריצים אותו על cron job כל שעה, והכל נראה תקין. עד שיום אחד, אחרי שבועיים של שקט, לקוח מתקשר ושואל למה הדאטה לא התעדכן מאז יום שלישי. בדיקה מהירה מגלה שה-scraper אכן רץ, אבל הוא מחזיר 0 רשומות. האתר שינה קלאס ב-CSS, והכל נשבר בשקט.

הסיפור הזה הוא לא תיאורטי. זאת המציאות של 90% ממערכות ה-scraping שראיתי. הן נבנות, עובדות פעם אחת, ואז נזנחות לרוץ על אדי דלק ותקווה. אבל תקווה היא לא אסטרטגיה. מערכת scraping היא לא פרויקט "שגר ושכח". היא מערכת חיה שדורשת השגחה מתמדת, כי היעד שלה – האינטרנט – משתנה כל הזמן, בלי להודיע.

בלי monitoring ו-alerting, אתם לא מנהלים מערכת, אתם מהמרים. אתם מהמרים שהאתר לא ישנה את ה-HTML שלו, שהם לא יטמיעו הגנה חדשה, שה-proxy שלכם לא ייחסם. וההימור הזה תמיד נכשל. השאלה היא רק מתי וכמה זה יעלה לכם.

מה שאתה לא מודד, אתה לא מנהל: חמשת מדדי הזהב

כדי לעבור מהימורים לניהול, אנחנו צריכים נתונים. לא סתם נתונים, אלא המדדים הנכונים שיספרו לנו את הסיפור האמיתי על בריאות המערכת שלנו. הנה חמשת המדדים שכל מערכת scraping חייבת לעקוב אחריהם, בלי יוצא מן הכלל.

1. Success Rate (פר יעד)

זה המדד החשוב ביותר. הוא עונה על השאלה הפשוטה: "כמה אחוז מהבקשות שלנו הצליחו לחלץ את המידע שרצינו?". חשוב למדוד את זה פר יעד (per target). אחוז הצלחה כללי של 98% יכול להסתיר את העובדה שהיעד הכי חשוב שלכם נכשל ב-100% מהזמן. הצלחה היא לא רק קבלת סטטוס קוד 200. הצלחה היא קבלת סטטוס 200, פיענוח הדף, ומציאת כל שדות החובה.

2. Latency (p95)

כמה זמן לוקח לבקשה, מקצה לקצה, להסתיים? מעקב אחרי ממוצע הוא טעות של מתחילים. בקשה אחת איטית במיוחד יכולה להטות את הממוצע ולא תראו את הבעיה. אנחנו מודדים אחוזונים, בדרך כלל p95 או p99. כלומר, 95% מהבקשות שלנו מסתיימות תוך X שניות. אם ה-p95 שלכם קופץ מ-3 שניות ל-15 שניות, זה סימן ברור שהאתר מאט אתכם, או שרשת ה-proxies שלכם גוססת.

3. Error Rate (לפי סוג שגיאה)

לא כל השגיאות נולדו שוות. קוד 404 (לא נמצא) הוא לא אותו דבר כמו 403 (גישה נדחתה) או 429 (יותר מדי בקשות). אתם חייבים לפרק את סך השגיאות שלכם לפי קוד סטטוס או סוג שגיאה פנימי. קפיצה פתאומית בשגיאות 403 יכולה להצביע על חסימת IP. עלייה בשגיאות 503 יכולה להצביע על בעיה בשרתי היעד. בלי הפירוט הזה, אתם יורים באפלה.

4. Data Freshness

המדד הזה עונה על השאלה: "מתי בפעם האחרונה קיבלנו בהצלחה נתונים עדכניים מהיעד הזה?". זה מדד קריטי למערכות שמספקות נתונים תלויי-זמן. אתם יכולים לחשב את הדלתא (בשניות או שעות) בין הזמן הנוכחי ל-timestamp של הרשומה המוצלחת האחרונה מכל יעד. אם הדלתא הזו עוברת סף מסוים (למשל, 3 שעות), זה הזמן להפעיל התראה.

5. Queue Depth / Throughput

אם אתם מריצים ארכיטקטורת scraping בסקייל, סביר להניח שיש לכם תור (queue) של משימות. עומק התור הוא מדד קריטי. אם התור הולך וגדל, זה אומר שהעובדים (workers) שלכם לא מצליחים לעבד את המשימות מספיק מהר. זה יכול להצביע על בעיית latency, עלייה בכמות החסימות, או פשוט צורך ביותר משאבים. לצד זה, מדד ה-throughput (משימות לדקה) נותן תמונה משלימה על קצב העבודה של המערכת.

הגישה שלא עובדת: להסתכל רק על CPU ו-Memory

הרבה צוותים באים מרקע של תשתיות קלאסיות, ושם המדדים החשובים הם ניצול CPU, צריכת זיכרון, ו-I/O של הדיסק. המדדים האלה חשובים, אבל בעולם ה-scraping הם מספרים רק חלק קטן מהסיפור. הם יכולים להגיד לכם שהשרת שלכם חי, אבל הם לא יגידו לכם אם ה-scraper שלכם עובד.

ראיתי אינספור פעמים dashboard ירוק לחלוטין ב-AWS CloudWatch, בזמן שה-scraper עצמו היה שבור לחלוטין. הוא רץ, צרך מעט CPU, ולא הדליף זיכרון. מושלם, לא? הבעיה היא שהוא נתקל ב-CAPTCHA בכל בקשה, נכשל בלפתור אותה, וסיים את הריצה "בהצלחה" בלי לחלץ אפילו רשומה אחת. המדדים התשתיתיים היו תקינים, אבל התוצאה העסקית הייתה אפס.

הפסיקו להתייחס ל-scraper שלכם כמו לעוד שרת. התייחסו אליו כמו לאפליקציה עם לוגיקה עסקית מורכבת, שההצלחה שלה תלויה בגורמים חיצוניים ובלתי צפויים. זה דורש סט מדדים אחר לגמרי.

הסטאק המנצח: Prometheus + Grafana ללוחמי הגרילה

אז איך אוספים את המדדים האלה בפועל? הדרך הפשוטה, הזולה והעוצמתית ביותר להתחיל היא עם השילוב של Prometheus ו-Grafana. Prometheus הוא בסיס נתונים של סדרות-זמן (Time-Series DB) שנועד לאסוף מדדים, ו-Grafana היא כלי ויזואליזציה מדהים שמאפשר לבנות dashboards על גבי הנתונים האלה.

הרעיון פשוט: ה-scraper שלכם חושף נקודת קצה (endpoint) ב-HTTP, למשל /metrics, שמציגה את המדדים הנוכחיים בפורמט טקסטואלי ש-Prometheus מבין. Prometheus סורק את הנקודה הזו כל 15 או 30 שניות ושומר את הנתונים. קל להוסיף את זה לכל scraper בפייתון עם הספרייה הרשמית.

from prometheus_client import start_http_server, Counter, Gauge, Histogram
import time

# --- הגדרת המדדים ---

# Counter: מדד שתמיד עולה (מספר בקשות, שגיאות)
REQUESTS_TOTAL = Counter('requests_total', 'Total number of requests', ['target', 'status_code'])

# Gauge: מדד שיכול לעלות ולרדת (עומק תור, משימות פעילות)
IN_PROGRESS_REQUESTS = Gauge('inprogress_requests', 'Number of in-progress requests', ['target'])

# Histogram: מודד התפלגות, מושלם ל-latency
REQUEST_LATENCY = Histogram('request_latency_seconds', 'Request latency', ['target'])


def process_request(target):
    # מדד Gauge עולה בכניסה לפונקציה ויורד ביציאה
    with IN_PROGRESS_REQUESTS.labels(target=target).track_inprogress():
        start_time = time.time()
        try:
            # ... לוגיקת ה-scraping כאן ...
            time.sleep(0.5) # מדמה עבודה
            status_code = 200
            print(f"Processed {target} successfully.")
        except Exception as e:
            status_code = 500
            print(f"Failed to process {target}: {e}")
        finally:
            # מדד Histogram מקבל את משך הזמן שלקח
            latency = time.time() - start_time
            REQUEST_LATENCY.labels(target=target).observe(latency)
            # מדד Counter עולה בסיום, עם תוויות (labels) לסטטוס ויעד
            REQUESTS_TOTAL.labels(target=target, status_code=status_code).inc()

if __name__ == '__main__':
    # חשיפת שרת HTTP על פורט 8000 שיציג את המדדים
    start_http_server(8000)
    print("Metrics server running on port 8000")
    
    # לולאה ראשית שמדמה ריצה של ה-scraper
    targets = ['amazon', 'ebay', 'bestbuy']
    while True:
        for target in targets:
            process_request(target)
        time.sleep(2)

עם הקוד הזה, כל מה שצריך זה להגדיר את Prometheus לגרד את הכתובת your-scraper-ip:8000, ובתוך דקות תוכלו לבנות dashboard ב-Grafana שמראה לכם בדיוק מה קורה.

מתי להעיר אותי ב-3 בלילה? הגדרת התראות (Alerts) שבאמת חשובות

Dashboards זה נחמד, אבל אף אחד לא יושב ובוהה בהם כל היום. הכוח האמיתי של monitoring הוא ביכולת לייצר התראות אוטומטיות (alerts) כשמשהו רע קורה. אבל זהירות: יותר מדי התראות, או התראות לא חשובות, יובילו ל-alert fatigue, והצוות פשוט יתחיל להתעלם מהן. הנה כמה חוקים להתראות שבאמת עובדות:

התראה על ירידה חדה ב-Success Rate

זו ההתראה החשובה ביותר. אם אחוז ההצלחה ליעד מסוים יורד ב-20% או יותר ונשאר נמוך במשך 15 דקות, משהו כנראה נשבר. החישוב בדרך כלל משווה את הממוצע ב-15 הדקות האחרונות לממוצע בשעה שלפני. זה מונע התראות שווא מקפיצות רגעיות.

התראה על עלייה חריגה בשגיאות ספציפיות

אל תתריעו על כל שגיאה. תתריעו על שינוי. אם בדרך כלל יש לכם 1% שגיאות 403, ופתאום זה קופץ ל-15% ונשאר שם, זה דורש בדיקה מיידית. סביר להניח שריינג' שלם של כתובות IP נחסם.

התראה על Data Freshness

התראה פשוטה ויעילה: אם עברו יותר מ-X שעות מאז שקיבלנו רשומה תקינה מיעד Y, שלח התראה. זה תופס את המקרים השקטים, שבהם ה-scraper לא נכשל במפורש, אלא פשוט לא מצליח להביא מידע חדש.

התראה על Latency p99

אם ה-latency של 99% מהבקשות ליעד מסוים עובר סף קריטי (למשל, 30 שניות) למשך יותר מ-5 דקות, זה יכול להצביע על בעיה חמורה. או שהאתר תחת עומס כבד, או שהם מפעילים עליכם מנגנוני האטה אקטיביים.

מעבר ל-Dashboard: תחקור תקלות עם Observability

מדדים והתראות אומרים לנו שמשהו לא בסדר. Observability עוזר לנו להבין מה לא בסדר. זה השילוב של שלושה עמודי תווך: Metrics (מה שדיברנו עליו), Logs (מה קרה בכל אירוע), ו-Traces (המסלול של בקשה אחת דרך כל המערכת).

כלי כמו Datadog משלב את כל השלושה בצורה הדוקה, אבל אפשר להרכיב סטאק דומה עם כלים כמו Prometheus (למדדים), Loki (ללוגים), ו-Tempo (ל-traces). כשמתקבלת התראה על ירידה ב-success rate, אתם יכולים לקפוץ מה-dashboard ב-Grafana ישירות ללוגים הרלוונטיים מאותה תקופת זמן ולאותו יעד, ולראות את הודעות השגיאה המדויקות.

לדוגמה, תרחיש כשל קלאסי: ה-Success Rate שלכם 100%, אבל אתם לא מקבלים נתונים. מדוע? כי האתר שינה את ה-selector של אלמנט המחיר. הבקשה הצליחה (200 OK), הדף פוענח, אבל חילוץ הנתונים החזיר null. מדד ה-Success Rate הבסיסי לא יתפוס את זה. כאן נכנסות לתמונה בדיקות תקינות נתונים (data validation) כמדד. אתם יכולים למדוד את אחוז הבקשות שהחזירו מחיר תקין (גדול מאפס), ולהתריע כשהוא יורד מתחת ל-95%. זה ההבדל בין monitoring ל-observability אמיתית.

ה-SLA שאתם חייבים לעצמכם (וללקוחות שלכם)

בסופו של דבר, כל המדדים וההתראות האלה צריכים לשרת מטרה עסקית. המטרה הזו מגולמת ב-Service Level Agreement (SLA). גם אם אתם צוות פנימי, הגדירו SLA לעצמכם. זה מכריח אתכם לחשוב על מה שחשוב.

SLA טוב ל-scraping לא מדבר על uptime של שרתים. הוא מדבר על דברים כמו:

• כיסוי נתונים (Data Coverage): אנחנו מתחייבים לאסוף בהצלחה נתונים מ-99% מהיעדים המוגדרים בכל יום.
• טריות נתונים (Data Freshness): הנתונים מכל יעד לא יהיו ישנים יותר מ-4 שעות.
• איכות נתונים (Data Quality): פחות מ-1% מהרשומות יכילו שדות חובה ריקים או לא תקינים.

כשיש לכם יעדים כאלה, ה-monitoring הופך להיות הכלי שמודד אתכם מול היעדים האלה. ה-dashboard הראשי שלכם לא צריך להראות CPU, אלא את עמידתכם ב-SLA בזמן אמת. זה מה שהופך מערכת scraping חובבנית למערכת מקצועית ואמינה, כזו שאפשר לבנות עליה עסק.