שמירת נתונים של 15 יום ב-Prometheus אינה מכסה דוחות רבעוניים. ככל שמספר השירותים גדל, מספר סדרות הזמן עולה על מיליונים, וביצועי השאילתות מתדרדרים. אנו פורסים ומכוונים את Grafana Mimir — פתרון מדרגי לאחסון מדדים עם ריבוי דיירים (multi-tenancy) וזמינות גבוהה. הוא מאפשר אחסון נתונים למשך שנים באמצעות אחסון אובייקטים ומספק גישה מהירה למדדים היסטוריים דרך Grafana או PromQL. גרפים לדוחות רבעוניים, ניטור SLA לתקופות עבר, מגמות — כל אלה דורשים גישה למדדים ישנים מ-30 יום. Mimir פותר זאת על ידי מתן אחסון אחיד לכל סדרות הזמן עם יכולות שאילתה מהירות. בינתיים, התשתית נשארת ניתנת לניהול הודות לכלי ניטור מובנים עבור Mimir עצמו.
לפי התיעוד הרשמי של Mimir, הוא תומך בעד מיליון מדדים בשנייה לכל מופע (תיעוד Grafana Mimir).
למה Mimir, ולא Thanos?
Mimir פשוט יותר לתפעול: הוא אינו דורש רכיב Sidecar נפרד, וה-Alertmanager מרובה הדיירים מוטמע ישירות בליבה. בפרויקטים שלנו, Mimir מציג זמן תגובה לשאילתות מהיר פי 2–3 מ-Thanos בעת אחסון שנה של מדדים. זה מושג באמצעות מנגנון דחיסה מבוזר (sharded compactor) ו-Store Gateway אופטימלי.
כיצד Mimir מתמודד עם תקלות ומבטיח זמינות גבוהה?
Mimir משתמש בארכיטקטורה עם קנה מידה אופקי ושכפול. Ingester משכפל נתונים על פני מספר אזורים, Distributor מאזן את העומס, ו-Store Gateway משרת שאילתות לאחסון ארוך טווח. כאשר רכיב נכשל, התעבורה מועברת למופעים בריאים. מנגנון ה-ring hash המובנה מספק גיבוב עקבי כדי למזער העברת נתונים במהלך קנה מידה.
בעיות שאנו פותרים
- נפח אחסון: Prometheus אינו יכול לשמור נתונים יותר מ-30 יום ללא פגיעה בביצועים. Mimir דוחס בלוקים ומעביר אותם ל-S3, וחוסך עד 60% מעלויות האחסון.
- ריבוי דיירים: כל צוות מקבל דייר משלו עם מדדים, התראות ומכסות מבודדים. אין חפיפה בנתונים.
- מורכבות תפעולית: לוחות מחוונים מובנים לניטור Mimir דרך ה-
grafana/mimir-mixinמציגים את מצב כל הרכיבים: קצב קליטה, שחזור WAL, בתי דחיסה.
איך אנחנו עושים את זה: פריסת Mimir על Kubernetes
אנו משתמשים ב-Helm chart של grafana/mimir-distributed. אנו ממליצים על צמתים ייעודיים עבור ingester ו-store gateway כדי למנוע "שכנים רועשים".
- הכנת קלאסטר Kubernetes (1.29+) עם PersistentVolume ו-NetworkPolicy לבידוד רשת.
- התקנת ה-Helm chart עם תצורת ריבוי דיירים ושכפול מודע לאזורים.
- הגדרת אחסון אובייקטים (S3, GCS, או MinIO) עבור blocks_storage.
- הגדרת Ingester, Store Gateway, Compactor עם משאבים תחת עומס.
- יצירת דיירים דרך API והעלאת כללי התראות.
- הגדרת כתיבה מרחוק (remote write) מ-Prometheus או Grafana Agent ל-Mimir.
- אינטגרציה עם Grafana והגדרת לוחות מחוונים לניטור Mimir.
דוגמת תצורת Helm
---
# mimir-values.yaml (ключевые секции)
mimir:
structuredConfig:
multitenancy_enabled: true
blocks_storage:
backend: s3
s3:
bucket_name: mimir-production
limits:
compactor_blocks_retention_period: 1y
ingestion_rate: 200000
ingester:
replicas: 6
zoneAwareReplication:
enabled: true
resources:
requests:
cpu: 2
memory: 12Gi
limits:
memory: 16Gi
store_gateway:
replicas: 3
zoneAwareReplication:
enabled: true
persistentVolume:
size: 100Gi
compactor:
replicas: 3
distributor:
replicas: 3
query_frontend:
replicas: 2
מה זה ריבוי דיירים ואיך מגדירים אותו?
ריבוי דיירים מופעל באמצעות הפרמטר # mimir-values.yaml (ключевые секции) mimir: structuredConfig: multitenancy_enabled: true blocks_storage: backend: s3 s3: bucket_name: mimir-production limits: compactor_blocks_retention_period: 1y ingestion_rate: 200000 ingester: replicas: 6 zoneAwareReplication: enabled: true resources: requests: cpu: 2 memory: 12Gi limits: memory: 16Gi store_gateway: replicas: 3 zoneAwareReplication: enabled: true persistentVolume: size: 100Gi compactor: replicas: 3 distributor: replicas: 3 query_frontend: replicas: 2 . כל דייר מזוהה על ידי כותרת multitenancy_enabled: true. עבור כל דייר ניתן להגדיר מגבלות נפרדות, כללי התראות וכללי הקלטה. המנהל מנהל את הדיירים דרך API או קובץ YAML.
# Создание нового тенанта и загрузка конфига алертинга
curl -X POST http://mimir/api/v1/tenant/register \
-H "Content-Type: application/json" \
-d '{"id":"team-platform","limits":{"ingestion_rate":100000}}'
curl -X POST http://mimir/api/v1/alerts \
-H "X-Scope-OrgID: team-platform" \
--data-binary @alertmanager-config.yaml
---
# alertmanager-config.yaml для тенанта team-platform
route:
receiver: slack-platform
routes:
- match:
severity: critical
receiver: pagerduty-platform
receivers:
- name: slack-platform
slack_configs:
- api_url: "https://hooks.slack.com/services/..."
channel: "#alerts-platform"
- name: pagerduty-platform
pagerduty_configs:
- routing_key: "team_platform_key"
---כל צוות מנהל את הכללים שלו באופן עצמאי.
כללי הקלטה דרך Ruler
# Загрузка recording rules для тенанта
curl -X POST http://mimir/api/v1/rules/infrastructure \
-H "X-Scope-OrgID: team-platform" \
--data-binary @rules.yaml
הכללים מאוחסנים באחסון אובייקטים; Ruler מעריך אותם במרווח זמן מוגדר.
Grafana Agent כשולח קל משקל
במקום Prometheus מלא, אנו משתמשים ב-Grafana Agent (או Alloy). הוא אינו מאחסן נתונים מקומית, רק אוסף ושולח. חיסכון בזיכרון של עד 40%.
---
# grafana-agent.yaml
metrics:
global:
scrape_interval: 15s
remote_write:
- url: http://mimir-nginx.monitoring.svc:80/api/v1/push
headers:
X-Scope-OrgID: team-platform
דרישות מינימליות לקלאסטר ייצור (6 דיירים, 10 מיליון מדדים)
| רכיב | עותקים (Replicas) | CPU | זיכרון | אחסון |
|---|---|---|---|---|
| Ingester | 6 | 2 | 16 Gi | - |
| Store Gateway | 3 | 4 | 8 Gi | 100 Gi SSD |
| Compactor | 3 | 4 | 8 Gi | - |
| Distributor | 3 | 2 | 4 Gi | - |
| Query Frontend | 2 | 1 | 2 Gi | - |
השוואת פרמטרי תצורה לתרחישים שונים
| תרחיש | קצב קליטה | שמירת נתונים | עותקי Ingester | משאבי Store Gateway |
|---|---|---|---|---|
| צוות קטן (דייר אחד) | 50,000 | 6 חודשים | 2 | 1x 8GB RAM, 50GB SSD |
| פרויקט בינוני (6 דיירים) | 200,000 | שנה | 6 | 3x 8GB RAM, 100GB SSD |
| ארגוני (20+ דיירים) | 1,000,000 | שנתיים | 12 | 6x 16GB RAM, 200GB SSD |
מה כלול בעבודה
- ביקורת על תשתית הניטור הקיימת
- תכנון ארכיטקטורת Mimir לפי העומס שלך
- פריסת קלאסטר ב-Kubernetes (Helm, מודע לאזורים, HA)
- הגדרת ריבוי דיירים, מגבלות, שמירת נתונים
- אינטגרציה עם Grafana והגדרת לוחות מחוונים
- יצירת runbook ותיעוד
- הדרכת צוות (2–3 שעות)
- תמיכה בחודש הראשון לאחר ההשקה
הניסיון וההבטחות שלנו
אנחנו צוות של מהנדסי SRE עם ניסיון בניטור עם Prometheus ו-Mimir, לאחר שהשלמנו מעל 50 פרויקטים של פריסת Mimir בייצור. אנו מחזיקים בהסמכות Grafana ויש לנו ניסיון עם קלאסטרים של עד 50 מיליון מדדים. אנו מבטיחים SLA על זמן תגובה במהלך תקלות.
לוח זמנים: בין 3 ל-7 ימים לפריסה מלאה כולל הדרכה.
כדי לדון בתרחיש שלך, צור קשר עם המהנדסים שלנו. הזמן יישום Mimir — קבל ייעוץ ממומחה.
לחישוב משאבים לפי העומס שלך, צור קשר עם המהנדסים שלנו. הזמן יישום Mimir וקבל תיעוד מלא.







