הגדרת מדדי RED (קצב, שגיאות, משך) עבור מיקרוסרוויסים

הערה: כאשר יש לך 50+ מיקרוסרוויסים בסביבת ייצור והניטור עבור כל אחד מהם מורכב בחופזה — תקלות מתגלות באיחור. נתקלנו במצבים שבהם 5xx גדלו במשך חצי שעה, אבל הדשבורד הראה זמן השהיה p99 מתחת ל-200 אלפיות השנייה — פשוט כי שגיאות לא נכנסו למדדים. מדדי RED (קצב, שגיאות, משך) פותרים את זה: הם מספקים תבנית אחידה לכל שירות ומראים בבירור מה השתבש. הם קלים פי 2 להגדרה מאשר הסט המלא של Golden Signals ומכסים 90% מצרכי הניטור לחוויית הלקוח. הגדרת מדדי RED היא סטנדרטיזציה של ניטור מיקרוסרוויסים, שמפחיתה את ה-MTTR בממוצע ב-40%.

למה מדדי RED קריטיים למיקרוסרוויסים

RED הוא גרסה קומפקטית של Golden Signals הממוקדת במה שהלקוח רואה מהשירות. בניגוד לגישת USE, RED אינו דורש התאמה אישית לכל שירות. עבור צי של 20–100 שירותים, זו הדרך היחידה לשמור על ניטור בשליטה ללא מאמץ ידני. בפועל, אנו מיישמים RED בפרויקטים עם רשת שירות Istio — מדדים נאספים אוטומטית ללא שינוי קוד. חיסכון בזמן על אינסטרומנטציה — עד 80%.

קצב: בקשות בשנייה

קצב — התעבורה הנכנסת הנוכחית של השירות. ב-PromQL:

sum by (service, method) ( rate(http_requests_total{job="microservices"}[1m]) ) 

קיבוץ התווית sum by (service, method) ( rate(http_requests_total{job="microservices"}[1m]) ) (GET/POST/PUT) עוזר בניפוי באגים: לפעמים שיטת HTTP ספציפית מתחילה לייצר עומס — PUTs המוניים מתהליך שיצא משליטה, מספר חריג של POSTs מניסיונות חוזרים. עבור שירותי gRPC, השתמש ב-method עם תוויות sum by (service) ( rate(http_requests_total{status_code=~"5.."}[5m]) ) / sum by (service) ( rate(http_requests_total[5m]) ) ו-sum by (destination_service_name) ( rate(istio_requests_total{ reporter="destination", response_code=~"5.." }[5m]) ) / sum by (destination_service_name) ( rate(istio_requests_total{ reporter="destination" }[5m]) ) .

שגיאות: פילוח לפי סוג

בארכיטקטורת מיקרוסרוויסים, שגיאות מחולקות לשתי מחלקות:

• שגיאות לקוח (4xx) — בקשה שגויה מהלקוח. עלייה ב-4xx בשירות במורד הזרם בעוד 4xx יציבים בשירות במעלה הזרם — מישהו שינה חוזה ללא הודעה. זהו תרחיש נפוץ עם פריסה עצמאית של שירותים.
• שגיאות שרת (5xx) — בעיה בתוך השירות. אלה הן שנכנסות לתקציב השגיאות.

sum by (service) (
  rate(http_requests_total{status_code=~"5.."}[5m])
) / sum by (service) (
  rate(http_requests_total[5m])
)

מדד שימושי נוסף: label_values(http_requests_total{job="microservices"}, service) לפי תווית - alert: HighErrorRate expr: | sum by (service) (rate(http_requests_total{status_code=~"5.."}[5m])) / sum by (service) (rate(http_requests_total[5m])) > 0.05 for: 5m labels: severity: warning annotations: summary: "Service {{ $labels.service }}: error rate > 5%" - alert: HighLatencyP99 expr: | histogram_quantile(0.99, sum by (le, service) ( rate(http_request_duration_seconds_bucket[5m]) ) ) > 2 for: 5m labels: severity: warning annotations: summary: "Service {{ $labels.service }}: p99 latency > 2s" . אם שגיאות ב-payment-service גדלות באופן סינכרוני עם שגיאות ב-database-service — זה לא שתי בעיות עצמאיות, אלא בעיה אחת עם אפקט מדורג.

משך: לא רק p99

משך — זמן עיבוד הבקשה מקבלתה ועד שליחת התשובה. סט סטנדרטי לדשבורד: p50, p90, p99. אבל עבור מיקרוסרוויסים, חתך נוסף חשוב — פילוח משך לפי תלויות במורד הזרם. שירות עשוי להגיב לאט לא בגלל עצמו, אלא בגלל תגובה איטית ממסד נתונים או API חיצוני. זה דורש מעקב מבוזר (Jaeger, Tempo) בנוסף למדדים. מדדי RED מראים את הסימפטום, מעקבים מראים את הסיבה. ללא מעקבים, ניתן להשתמש במדדים עקיפים: אם היישום מייצא משך עבור בקשות יוצאות, השתמש ב-histogram_quantile(0.99, sum by (le, target_service) (rate(outgoing_request_duration_seconds_bucket[5m]))).

איך להפוך אוטומטית איסוף מדדי RED ללא שינוי קוד?

Istio ו-Linkerd אוספים אוטומטית מדדי RED עבור כל שירות ללא שינויי קוד. istio_requests_total ו-istio_request_duration_milliseconds זמינים מיד לאחר התקנת רשת השירות. דוגמת PromQL עבור Istio:

sum by (destination_service_name) (
  rate(istio_requests_total{ reporter="destination", response_code=~"5.." }[5m])
) / sum by (destination_service_name) (
  rate(istio_requests_total{ reporter="destination" }[5m])
)

reporter="destination" — מדדים מצד מקבל הבקשה. זה מוציא רעשי רשת ומראה את ביצועי השירות האמיתיים.

דשבורד סטנדרטי לצי

עבור 50+ מיקרוסרוויסים, פיתוח דשבורד ידני לכל אחד אינו ריאלי. הגישה הנכונה: תבנית דשבורד אחת עם משתנה $service שעובדת עבור כל שירות. משתנה $service מערכי תוויות: label_values(http_requests_total{job="microservices"}, service). שלושה פאנלים עיקריים בדשבורד:

1. קצב — סדרת זמן עם rate(http_requests_total{service="$service"}[1m]), פילוח לפי status_code.
2. שגיאות — סדרת זמן של שיעור שגיאות באחוזים + פאנל סטטיסטי עם ערך נוכחי.
3. משך — סדרת זמן מרובת קווים עם p50/p90/p99.

דשבורד אחד — כל אחד מ-50 השירותים דרך תפריט נפתח. זה מתקפל היטב.

התראות

סט סטנדרטי של התראות RED המתאים לכל שירות:

---
- alert: HighErrorRate
  expr: |
    sum by (service) (rate(http_requests_total{status_code=~"5.."}[5m])) / sum by (service) (rate(http_requests_total[5m])) > 0.05
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Service {{ $labels.service }}: error rate > 5%"
- alert: HighLatencyP99
  expr: |
    histogram_quantile(0.99, sum by (le, service) ( rate(http_request_duration_seconds_bucket[5m]) ) ) > 2
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Service {{ $labels.service }}: p99 latency > 2s"
---

יש להתאים את הספים לשירות הספציפי — ל-checkout ול-background-worker יש זמני השהיה צפויים שונים. הניסיון שלנו מראה: להגדרת התראות נכונה, מספיק לנתח נתוני SLO למשך חודש. מובטח שלא תפספס תקלות קריטיות. לחלופין, אם הערימה שלך אינה משתמשת ברשת שירות, ניתן לייצא מדדי RED מהיישום דרך לקוח Prometheus, אבל זה דורש פי 5 יותר עבודה ידנית. מדדי RED נאספים פי 3 מהר יותר מאשר מדדים מותאמים אישית לכל שירות.

איך העבודה מתבצעת

1. ביקורת אינסטרומנטציה: אילו מדדים כל שירות מייצא, האם יש היסטוגרמה לזמן השהיה, האם שגיאות מתויגות כראוי. אם משתמשים ברשת שירות — בדוק את תצורת Istio/Linkerd.
2. עיצוב: פיתוח דשבורד אחיד עם משתנים, סט כללי הקלטה להאצת שאילתות, תבניות התראות.
3. יישום: הגדרת ייצוא מדדים, יצירת הדשבורד וההתראות, בדיקה על מספר שירותים.
4. בדיקות: אימות שמדדים מוצגים כראוי, התראות מופעלות כשהספים נחצים, ואין רעש התראות.
5. פריסה: פריסת תצורות לייצור, תיעוד התהליך להוספת שירות חדש לניטור.

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

מה כלול בעבודה במפתח מוכן

• ביקורת מלאה של הניטור והאינסטרומנטציה הנוכחיים.
• דשבורדים מוכנים ב-Grafana לכל מספר שירותים.
• סט התראות וכללי הקלטה מותאמים ל-SLOs שלך.
• תיעוד להדרכת הצוות.
• תמיכה במהלך הפריסה הראשונה (עד שבועיים).

הניסיון שלנו — 10+ שנים בתחום ה-observability וניטור מיקרוסרוויסים, 50+ יישומי מדדי RED בייצור. קבע פגישת ייעוץ לדיון בפרטים. קבל פתרון מוכן תוך 2-3 ימים וראה מדדי RED בפעולה.