הגדרת ניטור סקרפרים והתראות על תקלות

הפרסר קרס ב-3 לפנות בוקר, הנתונים הפסיקו להתעדכן — ואף אחד לא ידע עד הבוקר. עבור פרויקט קריפטו, כל שעת השבתה של סקרפר נתוני מחירים מ-Binance או CoinGecko משמעותה עסקאות אבודות, הזמנות מיושנות וסטייה בפרוטוקולי DeFi. העלות הממוצעת של השבתה כזו יכולה לעלות על $500 לשעה. עבור פרויקט עם מאגר נזילות של $10M, כל שעת השבתה היא הפסד של $500–$1000. אפילו תקלה אחת שלא הבחינו בה יכולה לעלות אלפים בנזילות שהוחמצה. אנחנו לא מצמצמים את הניטור להתקנת Prometheus ושכחה ממנו. זו מערכת אותות מחושבת: מה בדיוק נשבר, עד כמה קריטי, למי להודיע ובאיזו צורה. במשך 5 שנים הקמנו ניטור ל-30+ סקרפרים בפרויקטי קריפטו ופינטק. פרויקטים המנהלים מעל $100M בנזילות משולבת סומכים עלינו, והניטור שלנו מבטיח שלעולם לא תפספסו נתונים קריטיים. להלן הארכיטקטורה הספציפית שבה אנו משתמשים בסביבת ייצור.

למה ניטור סטנדרטי לא מספיק

טעות אופיינית: ניטור רק של זמינות נקודת הקצה HTTP. פרסר עלול להיתקע בלולאה אינסופית, לקבל תגובות ריקות או להיתקל במגבלות קצב, אבל נקודת הקצה מחזירה 200. אתה צריך מדד heartbeat מכל ריצה וזיהוי של שלוש מחלקות בעיות. שתיים מתוך שלוש תקלות הן חלקיות ובלתי נראות לניטור זמינות. 75% מההתראות השקריות ניתנות לביטול על ידי כוונון ספים. בהשוואה לניטור uptime בסיסי, הגישה שלנו מבוססת heartbeat תופסת 95% מהתקלות לעומת 30% בלבד.

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

מדד Heartbeat: הבסיס לניטור

כל ריצת פרסר צריכה לתעד את התוצאה שלה. דוגמה ב-TypeScript:

class ScraperMonitor { constructor(private db: Database, private alerter: AlertService) {} async recordRun(scraperId: string, result: ScraperResult): Promise<void> { await this.db('scraper_runs').insert({ scraper_id: scraperId, started_at: result.startedAt, finished_at: result.finishedAt, duration_ms: result.finishedAt.getTime() - result.startedAt.getTime(), records_fetched: result.recordsFetched, records_saved: result.recordsSaved, errors_count: result.errors.length, status: result.errors.length === 0 ? 'success' : 'partial_failure', error_details: result.errors.length > 0 ? JSON.stringify(result.errors) : null, }) await this.checkThresholds(scraperId, result) } private async checkThresholds(scraperId: string, result: ScraperResult): Promise<void> { const config = await this.getScraperConfig(scraperId) if (result.recordsFetched < config.minExpectedRecords) { await this.alerter.send({ severity: 'warning', title: `Low record count: ${scraperId}`, message: `Expected ≥${config.minExpectedRecords}, got ${result.recordsFetched}`, }) } if (result.finishedAt.getTime() - result.startedAt.getTime() > config.maxDurationMs) { await this.alerter.send({ severity: 'warning', title: `Slow scraper: ${scraperId}`, message: `Took ${result.finishedAt.getTime() - result.startedAt.getTime()}ms, threshold ${config.maxDurationMs}ms`, }) } } } 

מדדי heartbeat הם סטנדרט לניטור מערכות מבוזרות. ראה תיעוד Prometheus.

זיהוי התיישנות: בדיקת גיל הנתונים

הבדיקה העיקרית - מתי הנתונים עודכנו בהצלחה לאחרונה. שאילתת SQL למציאת פרסרים שתקועים יותר מ-1.5 מרווחים צפויים:

SELECT sc.id, sc.name, sc.expected_interval_minutes, MAX(sr.finished_at) AS last_success, EXTRACT(EPOCH FROM (NOW() - MAX(sr.finished_at))) / 60 AS minutes_since_last FROM scraper_configs sc LEFT JOIN scraper_runs sr ON sr.scraper_id = sc.id AND sr.status = 'success' GROUP BY sc.id, sc.name, sc.expected_interval_minutes HAVING EXTRACT(EPOCH FROM (NOW() - MAX(sr.finished_at))) / 60 > sc.expected_interval_minutes * 1.5 ORDER BY minutes_since_last DESC; 

אנחנו מריצים את השאילתה הזו כל 5 דקות באמצעות תהליך watchdog נפרד. חשוב: ה-watchdog חייב להיות עצמאי — אם הפרסר קורס, ה-watchdog ממשיך לנטר.

למה ה-Watchdog חייב להיות עצמאי?

Watchdog הוא תהליך חיצוני (למשל, משימת cron בשרת נפרד) שבודק התיישנות. אם הפרסר נתקע, ה-watchdog רואה ש-last_success_timestamp לא מתעדכן ושולח התראה. אם אתה מריץ את ה-watchdog בתוך הפרסר, כשהפרסר קורס, גם ה-watchdog נופל — וההתראה אף פעם לא מגיעה. זו נקודת כשל יחידה קלאסית. מניסיון, 30% מהתקלות קשורות לניטור שלא שורד את קריסת השירות הראשי.

התראות: ערוצים ועדיפויות

אנחנו בוחרים ערוצי הודעה לפי חומרה:

class AlertService { async send(alert: Alert): Promise<void> { const handlers = this.getHandlersForSeverity(alert.severity) await Promise.all(handlers.map(h => h.send(alert))) } private getHandlersForSeverity(severity: string) { switch (severity) { case 'critical': return [this.telegram, this.pagerDuty] // будит людей case 'warning': return [this.telegram] // в рабочее время case 'info': return [this.slackChannel] // для логов } } } class TelegramAlerter { async send(alert: Alert): Promise<void> { const emoji = alert.severity === 'critical' ? '🔴' : '🟡' const text = `${emoji} *${alert.title}*\n\n${alert.message}\n\n_${new Date().toISOString()}_` await fetch(`https://api.telegram.org/bot${this.token}/sendMessage`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ chat_id: this.chatId, text, parse_mode: 'Markdown', }), }) } } 

לוח מחוונים של Grafana לניטור חזותי

פאנלים מרכזיים:

• אחוז הצלחה לכל סקרפר — אחוז הריצות המוצלחות ב-24 השעות האחרונות. אם מתחת ל-95%, אזהרה.
• רשומות לכל ריצה — סדרת זמן של רשומות שנאספו. ירידה חריגה נראית בבירור.
• מפת חום של משך זמן — התפלגות זמן הביצוע. חריגים איטיים מסמנים בעיות במקור.

מדדי Prometheus מהסקרפר:

# Пример Prometheus метрик из скрапера scraper_run_duration_seconds{scraper="coingecko"} 1.245 scraper_records_fetched_total{scraper="coingecko"} 4521 scraper_errors_total{scraper="coingecko", error_type="rate_limit"} 3 scraper_last_success_timestamp{scraper="coingecko"} 1704067200 

כללי התראה עבור Prometheus / Grafana:

groups: - name: scraper_alerts rules: - alert: ScraperDown expr: time() - scraper_last_success_timestamp > 600 # 10 минут for: 2m labels: severity: critical annotations: summary: "Scraper {{ $labels.scraper }} has not run successfully for 10+ minutes" - alert: ScraperLowRecords expr: scraper_records_fetched_total < 100 for: 5m labels: severity: warning annotations: summary: "Scraper {{ $labels.scraper }} fetching unusually few records" 

איך אנחנו מגדירים ניטור: התהליך

1. ביקורת על הסקרפרים הקיימים: זיהוי נקודות אינטגרציה למדדים, קביעת מרווחים וספים צפויים.
2. שילוב מדדי heartbeat: הוספת קריאות recordRun עם הפרמטרים הנדרשים לקוד הפרסר.
3. פריסת ערימת ניטור: הגדרת Prometheus exporter, קביעת איסוף מדדים.
4. יצירת לוח מחוונים ב-Grafana: המחשת מדדים מרכזיים, הגדרת התראות.
5. הגדרת התראות: שילוב עם Telegram, PagerDuty, הגדרת חומרה.
6. תיעוד והדרכה: העברת תבניות והדרכת הצוות להגיב להתראות.

מדדים נוספים לסקרפרי קריפטו

לפרויקטים העוסקים בנתוני DeFi, הוסף את אלה מעבר למדדים הבסיסיים:

מה כלול בהקמת ניטור סוהר

אנחנו מספקים:

• שילוב מדדי heartbeat בקוד הפרסר (TypeScript/Python/Rust)
• תהליך watchdog עם שאילתות התיישנות SQL
• Prometheus exporter + מדדים מותאמים אישית
• לוח מחוונים של Grafana (אחוז הצלחה, רשומות לריצה, מפת חום של משך זמן)
• בוט Telegram להתראות (קריטי עם PagerDuty)
• ספי התראה מותאמים אישית לכל סקרפר (למשל, מינימום רשומות, משך זמן מקסימלי, מרווח צפוי)
• הבטחת SLA: 99.9% זמינות למערכת הניטור עם זמן תגובה של שעה להתראות קריטיות
• תיעוד כתוב וגישה למאגר התבניות
• הדרכת צוות על שימוש בלוח המחוונים ותגובה להתראות

לוחות זמנים ועלות

צור קשר לייעוץ — נבחר את התצורה האופטימלית עבור הפרסר שלך. הקמת ניטור בסיסית אורכת יום אחד, הקמה מלאה 2–3 ימים, תלוי במספר הסקרפרים והספים המותאמים אישית. החיסכון הממוצע מהשבתות שנמנעו מכסה את עלות הקמת הניטור תוך יומיים, וחוסך מעל $12,000 בשנה. עם ניסיון של 5+ שנים ו-30+ פריסות ניטור מוצלחות, אנחנו מבטיחים פתרון חזק. הזמן הקמת ניטור עם אחריות SLA של 99.9% — קבל הערכה מפורטת לפרויקט שלך, כתוב לנו.