ניטור תשתית עם Thanos: Prometheus ניתן להרחבה
לעתים קרובות אנו רואים תרחיש זה: מספר מופעי Prometheus אוספים מדדים מאשכולות, מרכזי נתונים או אזורי ענן שונים. אין נקודה אחת לשאילת את כל הנתונים בבת אחת. והשמירה של Prometheus מוגבלת לדיסק מקומי — אחסון מדדים למשך יותר מכמה חודשים הופך ליקר ולא יעיל. בינתיים, העומס יכול להגיע למיליון מדדים בשנייה, וכל מופע Prometheus מאחסן נתונים מקומית, מה שמוביל לכפילות ועלויות מוגדלות.
Thanos פותר את שתי הבעיות. הוא מספק תצוגה גלובלית אחת על פני מופעי Prometheus רבים ומעביר אחסון מדדים לטווח ארוך לאחסון אובייקטים (S3, GCS, Azure Blob). Thanos אינו מחליף את Prometheus; הוא משלים אותו, תוך שמירה על תאימות PromQL ו-Grafana המוכרות. בפועל, זה יכול להפחית עלויות תשתית בעד 40% באמצעות אופטימיזציית אחסון ו-downsampling.
הצוות שלנו פרס את Thanos בעשרות פרויקטים, מסטארטאפים ועד התקנות ארגוניות גדולות המטפלות במאות אלפי מדדים בשנייה. להלן פירוט מעשי של רכיבים, טעויות אופייניות ותהליך הפריסה.
ארכיטקטורת Thanos: רכיבים
| רכיב | תפקיד | פריסה |
|---|---|---|
| Sidecar | מעלה בלוקים שהושלמו לאחסון + gRPC לנתונים טריים | קונטיינר Sidecar בפוד Prometheus |
| Store Gateway | קורא נתונים היסטוריים מאחסון אובייקטים, מאחסן אינדקסים במטמון | StatefulSet נפרד |
| Querier | מקבל שאילתות PromQL, ממזג תשובות מ-Sidecar + Store, מבצע דה-דופליקציה | Deployment נפרד (יכול HPA) |
| Compactor | Downsampling (5m/1h), מחיל מדיניות שמירה | Background Job או CronJob |
השוואת אחסון: Prometheus מקומי מול אחסון אובייקטים של Thanos
| פרמטר | Prometheus (מקומי) | Thanos (אחסון אובייקטים) |
|---|---|---|
| שמירת נתונים גולמיים | ~15 ימים (אופייני) | 30+ ימים |
| עלות אחסון | גבוהה (SSD) | נמוכה (S3/אובייקט) |
| Downsampling | לא | כן (5m, 1h) |
| שאילתה גלובלית | לא | כן (Querier) |
למה Thanos על פני Prometheus עצמאי?
Prometheus יעיל עבור אשכול יחיד או קבוצת שרתים. ברגע שמופיע Prometheus שני — עבור אזור אחר, פרויקט או בידוד דיירים — אתה מתמודד עם הבעיה של "משקפיים שבורים." אתה צריך לעבור בין מקורות נתונים ב-Grafana או לכתוב פרוקסים מורכבים. Thanos מאחד את כל המקורות תחת נקודת Query אחת, והשמירה הגלובלית מוגדרת פעם אחת עבור כל הנתונים. הלקוחות שלנו חוסכים עד 40% בעלויות אחסון מדדים בזכות downsampling ושמירה מדורגת.
מניעת כפילות נתונים ב-Thanos
אם Prometheus פועל ב-HA (שני מופעים עם אותו עומס), Thanos Querier יראה סדרות זמן כפולות. דה-דופליקציה מופעלת עם הדגל --query.replica-label=prometheus_replica. אבל יש תנאי: לשני מופעי Prometheus חייבים להיות כל ה-external labels זהים מלבד תווית ה-replica. טעות אופיינית היא ערכים שונים עבור cluster או env. כתוצאה מכך, Querier מתייחס אליהם כמקורות שונים ואינו מבצע דה-דופליקציה — תראה ערכים מוכפלים בגרפים.
דוגמה לתצורה נכונה:
---
global:
external_labels:
cluster: production-eu
env: production
prometheus_replica: replica-0 # для второго инстанса replica-1
---אנו ממליצים להסכים על סכמת ה-external_labels עבור כל מופע Prometheus מראש ולבדוק דה-דופליקציה בסביבת staging.
למה Store Gateway יכול להיות איטי
Store Gateway מאחסן במטמון רק אינדקסים, לא את המדדים עצמם. ללא מטמון, שאילתה לחודש נתונים יכולה להיות איטית (עד 10 שניות). הגדרה אופטימלית: global: external_labels: cluster: production-eu env: production prometheus_replica: replica-0 # для второго инстанса replica-1 ופריסת Redis או Memcached כמטמון משותף. זה מפחית את זמן האחזור פי שניים עד שלושה.
תצורת דלי עם שמירה לנתוני downsampled:
---
type: S3
config:
bucket: metrics-thanos-prod
endpoint: s3.eu-west-1.amazonaws.com
retention:
resolution_raw: 30d
resolution_5m: 90d
resolution_1h: 365d
---
נתונים גולמיים (מרווחים של 15 שניות) נשמרים למשך 30 יום — זה יקר. נתוני downsampled לרזולוציות של 5 דקות ושעה נשמרים זמן רב יותר ובזול יותר. שאילתות לרבעון האחרון עובדות עם 5m, לשנה — עם 1h.
הפחתת עלויות אחסון עם Thanos
Thanos משתמש ב-downsampling: נתונים ישנים שמבוקשים לעתים רחוקות נשמרים בצורה מצטברת (רזולוציה של 5 דקות או שעה). זה מפחית את נפח האחסון פי 10–20 בהשוואה לנתונים גולמיים. לדוגמה, אחסון מדדים גולמיים לשנה ידרוש ~10 TB, בעוד עם downsampling — 500 GB. בנוסף, שמירה מדורגת: גולמי — 30 יום, 5m — 90 יום, 1h — 365 יום. כך, 70% מהנתונים נשמרים באחסון אובייקטים זול, מה שמניב חיסכון של עד 40%. להרחבת Prometheus, Thanos הוא הכרחי: הוא מאפשר לשלב מדדים מאשכולות Kubernetes שונים לאחסון יחיד, ומספק ניטור Kubernetes בשברירי שנייה.
Thanos Ruler: התראות חוצות אשכולות
Thanos Ruler מבצע כללי הקלטה והתראות של Prometheus, תוך שאילתת נתונים דרך Querier. זה מאפשר כללים חוצי אשכולות שאינם זמינים ב-Prometheus רגיל:
---
groups:
- name: cross-cluster.rules
rules:
- alert: ClusterHighMemoryUsage
expr: |
avg by (cluster) ( node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes ) < 0.15
for: 10m
התראה כזו מופעלת כאשר ניצול הזיכרון הממוצע בכל האשכול יורד מתחת ל-15%. ב-Prometheus, תצטרך להריץ שאילתה נפרדת לכל מופע.
תהליך פריסה: 5 שלבים
- ביקורת — מלאי של כל מופעי Prometheus, סכמות תוויות, שמירה נוכחית.
- תכנון — בחירת אחסון אובייקטים, סכמת external_labels, תוכנית שמירה.
- פריסת Sidecar — התקנת Thanos Sidecar לצד כל Prometheus (Helm chart או manifests).
- הגדרת אחסון — יצירת דלי, הגדרת Store Gateway ו-Querier.
- דחיסה וניטור — הפעלת Compactor, הגדרת שמירה באחסון, העברת מקורות נתונים של Grafana ל-Querier.
בכל שלב אנו מבצעים בדיקות: השוואת תוצאות שאילתות מ-Prometheus מול Thanos Querier — הן חייבות להתאים לנתונים טריים.
מה כלול בעבודה שלנו
- תיעוד הארכיטקטורה הפרוסה.
- גישה ל-Thanos Querier לכל הצוותים.
- הכשרת מהנדסים לעבודה עם Thanos (שאילתות בסיסיות, התראות אופייניות).
- תמיכה בשלב הייצוב (שבועיים לאחר הפריסה).
המומחיות והערבויות שלנו
אנחנו צוות של מהנדסי DevOps עם ניסיון של 10+ שנים, מוסמכים ב-Kubernetes ו-AWS. השלמנו מעל 50 פרויקטי ניטור על Prometheus/Thanos, כולל מערכות עם >1 מיליון מדדים בשנייה. אנו מבטיחים שביצועי השאילתות לא יתדרדרו והשמירה תהפוך לניתנת לניהול.
הזמינו ביקורת ניטור — היא אורכת שעה. צרו קשר לפיתוח תוכנית פריסה לתשתית שלכם. קבלו ייעוץ על ניטור תשתית — המומחים שלנו יעזרו לכם לבחור את הארכיטקטורה האופטימלית.