כשהשירות נופל אבל הניטור מראה הכל ירוק — זו בעיה. ניטור CPU וזיכרון סטנדרטי לא משקף את חוויית המשתמש. בלי golden signals, לא תדעו שהשהייה (latency) עלתה ל-10 שניות עד שתבדקו לוגים. ארבעת האותות — Latency, Traffic, Errors, Saturation — עונים על השאלה "איפה לחפור?". גוגל תיארה אותם ב-SRE Book SRE Book, והמסגרת הזו נשארת אחת הגישות הפרקטיות ביותר לניטור. היא מתמקדת במדדים מול המשתמש, לא בתשתית.
אנחנו מגדירים golden signals במפתח פתוח: ממלאי של מדדים קיימים ועד דשבורדים והתראות עם תיעוד. צרו קשר להערכה ראשונית של הפרויקט שלכם.
Latency: למה p99 חשוב יותר מהממוצע
Latency — זמן ביצוע בקשה. הטעות העיקרית היא לנטר את הממוצע. הממוצע מסתיר את הבעיה: אם 1% מהבקשות לוקחות 30 שניות ו-99% האחרים לוקחים 10ms, הממוצע ייראה בסדר, אבל מאות משתמשים רואים הקפאה כל דקה. p99 latency אינפורמטיבי פי 10 מהממוצע לאבחון בעיות ביצועים.
גישה נכונה: p50, p95, p99 דרך היסטוגרמה. הפרדת latency לבקשות מוצלחות ושגויות. שגיאה איטית גרועה משגיאה מהירה — המשתמש חיכה ועדיין קיבל כישלון.
# P99 latency для успешных запросов
histogram_quantile(0.99, sum by (le, service) (
rate(http_request_duration_seconds_bucket{service="$service", status_code!~"5.."}[5m])
))בדשבורד — שלושה קווים: p50 (חציון), p95 (רוב המשתמשים), p99 (חסרי המזל). סטייה של p99 מ-p50 מאותתת על זנב לא יציב של ההתפלגות.
Traffic: קו בסיס ואנומליות
Traffic — עומס על השירות. עבור שירותי HTTP — בקשות בשנייה. עבור תורים — הודעות בשנייה. עבור מסדי נתונים — טרנזקציות בשנייה.
sum by (service) ( rate(http_requests_total{service="$service"}[1m]) ) Traffic מספק הקשר לאותות אחרים. Latency גבוה עם traffic נמוך — בעיה פנימית (דליפת זיכרון, deadlock). Latency גבוה עם traffic גבוה בצורה חריגה — עומס יתר או DDoS.
פאנל שימושי: traffic עם הערות deployment. ירידה חדה ב-traffic — ייתכן שהשירות הפסיק לקבל בקשות. עלייה חדה — עומס חריג.
Errors: סיווג והתראות
Errors — חלק הבקשות שהסתיימו בשגיאה. חשוב להבחין: HTTP 5xx (שגיאות שרת), HTTP 4xx לפי קוד (400 = בקשה לא תקינה, 404 = לא נמצא — דברים שונים), timeouts (עשויים להחזיר 200 אבל להיות שבורים).
# Error rate 5xx
sum(rate(http_requests_total{service="$service", status_code=~"5.."}[5m])) / sum(rate(http_requests_total{service="$service"}[5m])) * 100ההתראה על שגיאות צריכה להתחשב בקו הבסיס. 0.1% שגיאות עבור תשלום הוא קריטי. 2% עבור חיפוש עשוי להיות תקין אם החיפוש מחזיר "לא נמצא".
Saturation: מדידה לרכיבים שונים
Saturation — כמה קרוב השירות לתקרת המשאבים. זה אות חיזוי: השירות עדיין עובד כרגיל, אבל המשאבים נמוכים, ובגל הבא השפלה היא בלתי נמנעת.
עבור רכיבים שונים, saturation נמדד אחרת:
# CPU saturation для пода
rate(container_cpu_usage_seconds_total{pod=~"$service.*"}[5m]) / on(pod) kube_pod_container_resource_limits{resource="cpu"}
# Saturation connection pool (для приложений с пулом соединений к БД)
db_pool_active_connections{service="$service"} / db_pool_max_connections{service="$service"}
# Queue saturation
rabbitmq_queue_messages{queue="$queue"} / rabbitmq_queue_consumer_capacity{queue="$queue"}Saturation > 80% — התראה צהובה. > 95% — אדום, הגדל לפני השפלה.
דוגמה לחישוב saturation של CPU
אם מגבלת ה-CPU של קונטיינר היא ליבה אחת, והצריכה היא 0.8 ליבה — saturation הוא 80%. במהלך כתיבות לדיסק זה עלול לגרום ל-latency.דשבורד של ארבעה אותות
דשבורד אחד, ארבע שורות, כל אחת לאות אחד. בכל שורה — כמה פאנלים עם היבטים שונים.
| אות | פאנלים |
|---|---|
| Latency | סדרות זמן P50/P95/P99, Heatmap של התפלגות עיכובים |
| Traffic | RPS לפי קודי סטטוס, פילוח RPS לפי endpoint |
| Errors | אחוז שגיאות %, מספר שגיאות לפי סוג, הודעות השגיאה המובילות |
| Saturation | שימוש ב-CPU/זיכרון, מילוי מאגר חיבורים, עומק תור |
משתנה # P99 latency для успешных запросов histogram_quantile(0.99, sum by (le, service) ( rate(http_request_duration_seconds_bucket{ service="$service", status_code!~"5.." }[5m]) ) ) בחלק העליון — הדשבורד עובד עבור כל שירות מהגילוי.
איך ליישם golden signals ב-3 שלבים
- מלאי של מדדים נוכחיים ואינסטרומנטציה. בדקו אם יש היסטוגרמות latency ומדדי שגיאות.
- הגדרת כללי recording עבור היסטוגרמה, אחוז שגיאות, saturation.
- פיתוח דשבורד עם ארבע שורות וסט התראות עם ספי צהוב/אדום.
קבלו ייעוץ על הגדרת ניטור — אנחנו עוזרים בכל שלב.
השוואה: ממוצע מול אחוזונים
| מדד | יתרון | בעיה לדוגמה |
|---|---|---|
| ממוצע | פשוט לחישוב | מסתיר 1% של בקשות איטיות |
| p99 | רגיש לחריגים | חושף הקפאה אפילו על 0.1% מהבקשות |
אחוזונים נותנים תמונה מדויקת פי 100 לאבחון latency.
מה כלול בעבודה
- מלאי של מדדים נוכחיים ואינסטרומנטציה
- הגדרת כללי recording עבור היסטוגרמה, אחוז שגיאות, saturation
- פיתוח דשבורד עם ארבע שורות ומשתנה
sum by (service) ( rate(http_requests_total{service="$service"}[1m]) ) - הגדרת התראות עם ספי צהוב/אדום
- תיעוד לצוות: מה כל אות אומר, איך להגיב
- העברה והדרכה (אופציונלי)
איך העבודה בנויה
אנחנו מתחילים במלאי: איזה מארבעת האותות כבר נמדדים. Latency דרך היסטוגרמה — האם הוא קיים? או רק gauge עם ממוצע? אם gauge — אנחנו מתקנים אינסטרומנטציה של האפליקציה, בלי היסטוגרמה אי אפשר לחשב אחוזונים.
Errors — האם 5xx מתועדים כמדדים? Traffic — האם יש מדדי בקשות של Prometheus, או רק מלוגים של nginx/loadbalancer.
אחרי המלאי: פיתוח כללי recording, דשבורד, סט התראות לכל אות עם ספים סבירים. התוצאה — תיעוד עם תיאורי אותות ו-runbook להתראות.
למהנדסים שלנו יש ניסיון SRE נרחב, הסמכות Prometheus ו-Kubernetes. אנחנו מבטיחים עמידה ב-MTTR SLA.
לוחות זמנים ואיך להזמין
דשבורד של ארבעה אותות לשירות אחד — 1-2 ימים. תבנית סטנדרטית לצי מיקרוסרוויסים — 2-3 ימים. העלות מחושבת באופן אישי.
אנחנו נעריך את הפרויקט שלכם. צרו קשר — נספר לכם איך לשפר את הניטור.