אחסון לטווח ארוך של Prometheus עם הגדרת Grafana Mimir

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

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

שמירת נתונים של 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 כדי למנוע "שכנים רועשים".

  1. הכנת קלאסטר Kubernetes (1.29+) עם PersistentVolume ו-NetworkPolicy לבידוד רשת.
  2. התקנת ה-Helm chart עם תצורת ריבוי דיירים ושכפול מודע לאזורים.
  3. הגדרת אחסון אובייקטים (S3, GCS, או MinIO) עבור blocks_storage.
  4. הגדרת Ingester, Store Gateway, Compactor עם משאבים תחת עומס.
  5. יצירת דיירים דרך API והעלאת כללי התראות.
  6. הגדרת כתיבה מרחוק (remote write) מ-Prometheus או Grafana Agent ל-Mimir.
  7. אינטגרציה עם 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 וקבל תיעוד מלא.