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

לוחות מחוונים מותאמים אישית של Grafana ליישומים

לעתים קרובות אנו נתקלים במצב: מדדי התשתית תקינים, אך המשתמשים מתלוננים על ביצועי API איטיים. ללא לוח מחוונים ליישום, צריך לחפש בלוגים ולקוות לטוב. עם לוח מחוונים מוגדר כראוי — 2 דקות לאבחון. הניסיון שלנו מראה שעבור שירות עם 50,000 RPS, לוח מחוונים מעוצב היטב מפחית את ה-MTTR מ-30 דקות ל-3-5.

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

למה לוח המחוונים של התשתית אינו מספיק

דוגמה טיפוסית: CPU ב-30%, זיכרון פנוי, אך זמן השהיה p95 מזנק ל-2 שניות. לוח המחוונים של התשתית לא יראה שהבעיה היא שאילתת SQL איטית או נעילת מאגר חיבורים. רק לוח מחוונים ליישום עם מדדי לוגיקה עסקית מאפשר לאתר את הבעיה תוך דקות.

אילו מדדים צריך לייצא?

היישום חייב לייצא מדדים בעצמו. עבור Go השתמשו ב-prometheus/client_golang, עבור Python — prometheus_client, עבור Node.js — prom-client, עבור Java — Micrometer עם רישום Prometheus. ללא אינסטרומנטציה, אין נתונים; ללא נתונים, אין לוח מחוונים.

קבוצה מינימלית של מדדים שכל יישום HTTP צריך לייצא:

var (
	httpRequestsTotal = prometheus.NewCounterVec(
		prometheus.CounterOpts{
			Name: "http_requests_total",
			Help: "Total number of HTTP requests",
		},
		[]string{"method", "path", "status_code"},
	)
	httpRequestDuration = prometheus.NewHistogramVec(
		prometheus.HistogramOpts{
			Name:    "http_request_duration_seconds",
			Help:    "HTTP request duration in seconds",
			Buckets: []float64{0.01, 0.05, 0.1, 0.5, 1, 2, 5},
		},
		[]string{"method", "path", "status_code"},
	)
)

מדדים אלה מהווים את הליבה של לוח מחוונים ליישום.

פאנלים מרכזיים בלוח המחוונים ליישום

קצב בקשות — מספר בקשות לשנייה, מפוצל לפי קוד סטטוס. זיהוי מהיר של קפיצות שגיאות:

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

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

sum(rate(http_requests_total{service="$service", status_code=~"5.."}[5m])) / sum(rate(http_requests_total{service="$service"}[5m])) * 100 

אחוזוני זמן השהיה — p50, p95, p99. זמן השהיה ממוצע הוא כמעט תמיד מטעה. p99 הוא מה שחווים 1% המשתמשים חסרי המזל ביותר:

histogram_quantile(0.99, sum by (le, method) ( rate(http_request_duration_seconds_bucket{service="$service"}[5m]) ) ) 

רוויה — מצבי משאבים של היישום: גודל מאגר חיבורים, goroutines, תור בקשות. ללא זה, ייתכן שתראו זמן השהיה תקין עד שהשירות קורס תחת עומס.

ספי SLO טיפוסיים:

מבנה ירידה לפרטים

קבוצה טובה של לוחות מחוונים לשירות בנויה בשלוש רמות.

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

פרטי מופע — מופע אחד עם כל המדדים: קצב בקשות, פירוט זמן השהיה לפי נקודת קצה, אחוז שגיאות, ערימת JVM (אם Java), goroutines (אם Go), שימוש במאגר חיבורי DB.

פרטי נקודת קצה — נקודת קצה HTTP ספציפית. התפלגות זמן השהיה (מפת חום היסטוגרמה), גודל מטען של בקשות/תגובות, תלויות במורד הזרם. רמה זו נדרשת בעת ניפוי שגיאות של פעולה איטית ספציפית.

מעבר בין רמות דרך קישור נתונים — לחיצה על מופע בסקירה הכללית פותחת את פרטי המופע עם המשתנים הנכונים. זה לא מוגדר אוטומטית; יש להגדיר זאת ידנית דרך var ( httpRequestsTotal = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "http_requests_total", Help: "Total number of HTTP requests", }, []string{"method", "path", "status_code"}, ) httpRequestDuration = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: "http_request_duration_seconds", Help: "HTTP request duration in seconds", Buckets: []float64{0.01, 0.05, 0.1, 0.5, 1, 2, 5}, }, []string{"method", "path", "status_code"}, ) ) בהגדרות הפאנל.

הערות פריסה

פריסת היישום צריכה להיות גלויה בלוח המחוונים. הערה דרך Grafana Annotations API או אירוע Prometheus:

curl -X POST http://grafana:3000/api/annotations \
  -H "Content-Type: application/json" \
  -d '{ "time": '"$(date +%s000)"', "tags": ["deployment", '"$SERVICE_NAME"'], "text": "Deploy '"$VERSION"' to production" }'

ב-Grafana, זה מוצג כקו אנכי בכל פאנלי סדרות הזמן. אם לאחר פריסה זמן השהיה p99 עלה, זה נראה מיד, ללא צורך בתאם ידני בין זמן הפריסה לגרף.

תהליך פיתוח לוח המחוונים

אנו מתחילים במלאי מדדים: מה היישום מייצא, אילו תוויות זמינות, האם יש צורך לשקף SLOs. ללא הבנה של המדדים הזמינים, לוח המחוונים לא יעבוד.

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

יישום: פאנלים, משתנים, קישורי נתונים בין רמות, צבעי סף, יחידות מדידה (לא "ערך 0.045", אלא "45 ms"). לבסוף, provisioning JSON ב-git ותיעוד להוספת מדדים חדשים.

מה כלול בעבודה (תוצרים)

• ביקורת מדדים ויצואנים קיימים
• עיצוב מבנה לוח המחוונים (אב טיפוס)
• יישום פאנלים, משתנים, קישורי נתונים
• הגדרת הערות פריסה
• תיעוד תפעולי (README, provisioning JSON)
• הדרכת צוות (שעה)
• אחריות לתוצאה: לא נמסור את לוח המחוונים עד שכל המדדים מאומתים כנכונים

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

איך לזרז פיתוח לוחות מחוונים עם תבניות?

הכנו תבניות למיקרוסרוויסים טיפוסיים (Go, Python, Java). הן מכסות 80% מהמדדים הנפוצים. התאמה לדרישות ספציפיות לוקחת יום אחד בלבד. ניסיון של למעלה מ-5 שנים ב-DevOps מאפשר לנו להבטיח שלוח המחוונים יעקוב אחרי שיטות העבודה המומלצות של Prometheus ו-Grafana.

רוצים לוח מחוונים דומה לשירות שלכם? צרו קשר — נעריך את הפרויקט שלכם ביום אחד ונציע פתרון מתאים.