לעתים קרובות אנו רואים את אותו תרחיש: Grafana מופעל ב-Docker, דשבורדים מיובאים מ-grafana.com, אך לאחר חודש מחצית מהפאנלים מציגים "אין נתונים", עוד שליש מציגים נתונים מיושנים, והתראות נשארות שקטות בדיוק כשהדיסק על צומת הייצור מתמלא. לאחר סקר של 50+ תשתיות, זיהינו טעויות אופייניות: היעדר provisioning, התעלמות מגרסאות תצורה, והגדרה לא אופטימלית של מקורות נתונים. הניסיון שלנו (למעלה מ-30 פרויקטי ניטור בשנים האחרונות) מראה שהגדרת ניטור נכונה אינה קשורה לייבוא פאנלים מוכנים, אלא ל-provisioning, לניהול גרסאות, ולארכיטקטורת מקורות נתונים מחושבת היטב. תוך 1–3 ימים אנו מיישמים ניטור שאינו דורש התערבות ידנית, נותן ראות מלאה על התשתית, ומפחית את זמן ניפוי הדשבורדים ב-70%.
תיעוד Grafana: "Provisioning הוא הדרך המומלצת לניהול מקורות נתונים ודשבורדים בסביבת ייצור."
למה provisioning הוא הסטנדרט לייצור?
Provisioning פותר שלוש בעיות מרכזיות: שחזור תצורה, ניהול גרסאות דרך Git, ופריסה אוטומטית. במקום ללחוץ דרך הממשק בכל פעם, אתה מתאר את כל מקורות הנתונים והדשבורדים בקבצי YAML. זה חשוב במיוחד בסביבות Kubernetes שבהן פודים נוצרים מחדש — עם הגדרה ידנית, התצורה אובדת. אנו מבטיחים שלאחר הגדרת provisioning, תוכל לפרוס הגדרת ניטור זהה על קלאסטר חדש תוך 15 דקות. ניתן לקרוא עוד על הרעיון בויקיפדיה.
אילו מקורות נתונים Grafana תומך בהם?
Grafana עובד עם מקורות נתונים — Prometheus, Loki, InfluxDB, CloudWatch, PostgreSQL, Elasticsearch. כל אחד מחובר דרך Administration → Data Sources עם URL מפורש, אישורים וזמני timeout. טעות אופיינית היא חיבור Prometheus דרך http://localhost:9090 בקונטיינר Docker שבו פועל Grafana. הקונטיינר אינו רואה את ה-localhost של המארח. השתמש בשם השירות ב-compose (http://prometheus:9090) או בכתובת IP חיצונית.
לייצור, עדיף לאחסן מקורות נתונים כקוד דרך provisioning. קובץ /etc/grafana/provisioning/datasources/prometheus.yaml:
---
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
url: http://prometheus:9090
isDefault: true
jsonData:
timeInterval: "15s"
queryTimeout: "60s"
זה מאפשר פריסת Grafana כתמונה בלתי ניתנת לשינוי — ללא לחיצות ידניות לאחר הפעלה מחדש של הקונטיינר. מעבר ל-provisioning מפחית את זמן ניפוי הדשבורדים ב-70%.
איך להגדיר התראות שלעולם לא יפספסו אירוע?
מגרסה 9.x, ל-Grafana יש מנוע התראות משלו, נפרד מ-Prometheus Alertmanager. הוא יכול להתריע ישירות מפאנלים בדשבורד או דרך Unified Alerting. ההבדל הוא מהותי: Grafana Alerting מעריך שאילתות בעצמו, במקום להסתמך על כללי Prometheus. זה נותן גמישות רבה יותר: ניתן להשתמש בכל מקורות הנתונים, לא רק ב-Prometheus.
הגדרת נקודת קשר ל-Telegram דרך provisioning (apiVersion: 1 datasources: - name: Prometheus type: prometheus url: http://prometheus:9090 isDefault: true jsonData: timeInterval: "15s" queryTimeout: "60s" ):
---
apiVersion: 1
contactPoints:
- orgId: 1
name: telegram-ops
receivers:
- uid: telegram-ops
type: telegram
settings:
bottoken: "${TELEGRAM_BOT_TOKEN}"
chatid: "${TELEGRAM_CHAT_ID}"
message: |
{{ range .Alerts }}
🔥 {{ .Labels.alertname }}
Instance: {{ .Labels.instance }}
{{ .Annotations.summary }}
{{ end }}
---תבניות משתמשות בתחביר Go template. immutable-образ עובר על התראות שהופעלו בקבוצה. אנו ממליצים להגדיר לפחות שלוש התראות: דיסק > 85%, RAM > 90%, CPU > 80% לאורך זמן. כאשר חורגים — שלח ל-Telegram או ל-PagerDuty.
איזה מחסנית ניטור לבחור ל-20+ צמתים?
לניטור תשתית, המחסנית האופיינית היא:
| רכיב | תפקיד |
|---|---|
rules |
מדדי מארח: CPU, RAM, דיסקים, רשת |
alerting/contact-points.yaml |
מדדי קונטיינרים (Docker/containerd) |
| Prometheus | איסוף ואחסון מדדים, הערכת כללים |
| Grafana | ויזואליזציה, התראות, הערות |
| Alertmanager | ניתוב והסרת כפילויות של התראות |
בתשתיות קטנות (עד 20 צמתים) זה מספיק. ככל ש-Prometheus גדל, הזיכרון הופך לצוואר בקבוק — אז כדאי לשקול Thanos או VictoriaMetrics כנקודת remote_write.
רשימת בדיקה למוכנות ניטור מהירה
| רכיב | סטטוס |
|---|---|
apiVersion: 1 contactPoints: - orgId: 1 name: telegram-ops receivers: - uid: telegram-ops type: telegram settings: bottoken: "${TELEGRAM_BOT_TOKEN}" chatid: "${TELEGRAM_CHAT_ID}" message: | {{ range .Alerts }} 🔥 {{ .Labels.alertname }} Instance: {{ .Labels.instance }} {{ .Annotations.summary }} {{ end }} מותקן על כל הצמתים |
☐ |
| Prometheus רואה את כל היעדים | ☐ |
| Grafana מחובר ל-Prometheus דרך provisioning | ☐ |
| התראות בסיסיות מוגדרות (דיסק, RAM, CPU) | ☐ |
| דשבורדים מנוהלים בגרסאות ב-Git | ☐ |
מה כלול בעבודה
בהזמנת הגדרת ניטור סוהר, אנו מספקים:
- תיעוד על ארכיטקטורת הניטור ומבנה הדשבורדים
- סקריפטים של provisioning לשחזור תצורה
- דשבורדים מותאמים לתשתית שלך (מארחים, Kubernetes, שירותים)
- התראות עם אינטגרציה ל-Telegram/Slack/PagerDuty
- גישה למאגר Git עם התצורה
- הדרכת צוות (שעה) על שימוש בניטור החדש
- תמיכה למשך שבועיים לאחר הפריסה
איך התהליך עובד
אנו מתחילים בסקר של המצב הנוכחי: אילו מקורות נתונים קיימים, אילו מדדים נאספים, האם קיים provisioning או שהכל נעשה ידנית דרך הממשק. זה לוקח כמה שעות.
לאחר מכן, אנו מתכננים את מבנה הדשבורדים עבור התשתית הספציפית שלך. לא ייבוא דשבורדים גנריים, אלא התאמה לשירותים האמיתיים: אילו מארחים, אילו תוויות צמתים, אילו שירותים לפצל לתיקיות.
היישום כולל הגדרת provisioning למקורות נתונים ודשבורדים, התראות בסיסיות (דיסק > 85%, RAM > 90%, CPU > 80% לאורך זמן), אינטגרציה עם Alertmanager או שליחת הודעות ישירה. לבסוף, תיעוד על מבנה הדשבורדים והוראות להוספת חדשים.
לוח זמנים
בערך: מיום אחד להגדרה בסיסית עם תבניות מוכנות ועד 3 ימים למחסנית מלאה עם provisioning, דשבורדים מותאמים אישית והתראות.
הזמן הגדרת ניטור עכשיו — קבל ייעוץ על ארכיטקטורת המחסנית והערכת זמן מדויקת. צור קשר, ואנו נבחר את הפתרון האופטימלי עבור התשתית שלך. 50+ חברות עובדות איתנו, ואנו מבטיחים שקיפות וסובלנות לתקלות עבור הניטור שלך.