הגדרת אחסון ארוך טווח לפרומתאוס עם Cortex

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

אנו מקבלים פניות רבות מצוותים שמדדי ה-Prometheus שלהם כבר לא מתאימים לתקופת השמירה ברירת המחדל של 15 יום. האפשרויות הרגילות הן לוותר על היסטוריה או להקים Prometheus נוסף ולהגדיר פדרציה. במקום זאת, אנו מציעים Cortex — מערכת backend מרובת-דיירים הניתנת להרחבה אופקית, אשר קולטת נתונים דרך remote_write בזמן אמת. במשך למעלה מ-5 שנים בעבודה עם מערכות מבוזרות, הקמנו Cortex לעשרות פרויקטים: מפלטפורמות SaaS ועד ניטור פנימי.

כיצד Cortex פותר אחסון לטווח ארוך?

Cortex מאחסן את כל המדדים באחסון אובייקטים (S3, GCS, MinIO) ומאפשר להגדיר תקופת שמירה של שנים. קליטת הנתונים מתרחשת מיידית: הנתונים נשלחים דרך remote_write, תוך עקיפת העיכוב של כ-2 שעות של Thanos Sidecar. בניגוד ל-Thanos, Cortex אינו דורש Sidecar עבור כל Prometheus ומספק תמיכה מובנית בריבוי דיירים. עבור אחת מהפלטפורמות שלנו עם 2 מיליון סדרות פעילות, צמצמנו את זמן ההשהיה למדדים חדשים משעתיים ל-30 שניות.

מתי Cortex, ולא Thanos

Cortex עדיף כאשר:

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

Cortex מורכב יותר תפעולית: זוהי מערכת מבוזרת עם 8+ רכיבים נפרדים. אבל התוצאה היא אחסון אחיד עם תקופת שמירה של עד שנתיים, SLO של 99.9%, והפרדת נתונים מלאה.

למה ריבוי דיירים חשוב לצוותים?

בארגונים גדולים, כל צוות רואה רק את המדדים שלו. Cortex מיישם הפרדה דרך כותרת X-Scope-OrgID. הגדרנו זאת עבור מוצר SaaS שבו 5 צוותים כתבו נתונים בו-זמנית לאשכול Cortex אחד מבלי לדעת על המדדים של האחרים. אנו מבטיחים הגדרת RBAC נכונה וביקורת גישה.

ארכיטקטורת רכיבים

Prometheus --remote_write--> Distributor --> Ingester (ring) --> Object Storage
| Querier <--> Store Gateway (chunks) <-- Object Storage
\--> Compactor
Query Frontend (cache layer)
| Ruler (recording/alerting rules)
Alertmanager (alerts)

Distributor מקבל remote_write, מבצע hash לסדרות לפי תוויות, ומפיץ ל-Ingesters דרך טבעת hashing עקבית. Ingester מחזיק נתונים בזיכרון ומבצע flush תקופתי לאחסון אובייקטים. הוא פועל בטבעת עם שכפול: כל סדרה נכתבת ל-3 Ingesters. Querier קורא מ-Ingesters (נתונים טריים) ומ-Store Gateway (נתונים היסטוריים). Compactor דוחס ומבצע downsample לבלוקים.

אילו רכיבי Cortex הם עתירי משאבים ביותר?

Ingester הוא הכבד ביותר: הוא מחזיק את השעתיים האחרונות של נתונים בזיכרון. בנפח גבוה (1M+ סדרות פעילות), כל Ingester צורך 8–16 GB RAM. אנו ממליצים לתכנן 2–3 רפליקות Ingester לסבילות לתקלות. רכיבים אחרים (Distributor, Querier) פחות תובעניים — 2 vCPU ו-4 GB RAM מספיקים.

הגדרת Prometheus remote_write

---
remote_write:
  - url: http://cortex-distributor:9009/api/prom/push
    queue_config:
      max_samples_per_send: 10000
      max_shards: 30
      capacity: 20000
    write_relabel_configs:
      - source_labels: [__name__]
        regex: "go_.*"
        action: drop
    headers:
      X-Scope-OrgID: "team-platform"

Prometheus --remote_write--> Distributor --> Ingester (ring) --> Object Storage | Querier <--> Store Gateway (chunks) <-- Object Storage \--> Compactor Query Frontend (cache layer) | Ruler (recording/alerting rules) Alertmanager (alerts) הוא כותרת חובה עבור Cortex מרובה-דיירים.

תצורת Cortex מינימלית (תהליך יחיד)

לבדיקות, ניתן להריץ כבינארי יחיד:

---
target: all
auth_enabled: true
server:
  http_listen_port: 9009
ingester:
  ring:
    kvstore:
      store: memberlist
    replication_factor: 3
blocks_storage:
  backend: s3
  s3:
    bucket_name: cortex-blocks
    region: eu-west-1
  tsdb:
    dir: /tmp/cortex/tsdb
  compactor:
    data_dir: /tmp/cortex/compactor
store_gateway:
  sharding_enabled: true
  sharding_ring:
    replication_factor: 3
limits:
  ingestion_rate: 100000
  max_label_names_per_series: 30
  retention_period: 90d

ייצור: מצב מיקרוסרביסים

בייצור, כל רכיב נפרס בנפרד דרך Helm:

helm repo add cortex-helm https://cortexproject.github.io/cortex-helm-chart
helm install cortex cortex-helm/cortex --namespace monitoring -f values.yaml

סעיפים מרכזיים של remote_write: - url: http://cortex-distributor:9009/api/prom/push queue_config: max_samples_per_send: 10000 max_shards: 30 capacity: 20000 write_relabel_configs: - source_labels: [__name__] regex: "go_.*" action: drop headers: X-Scope-OrgID: "team-platform" :

---
config:
  auth_enabled: true
  blocks_storage:
    backend: s3
    s3:
      bucket_name: cortex-production
      endpoint: s3.amazonaws.com
  ingester:
    replicas: 6
    resources:
      requests:
        memory: 8Gi
        cpu: 2
  distributor:
    replicas: 3
  store_gateway:
    replicas: 3
    persistentVolume:
      size: 50Gi

ריבוי דיירים ב-Grafana

כדי להפריד נתונים, הגדר datasource של Grafana עם כותרת דייר:

---
datasources:
  - name: Cortex-Team-Platform
    type: prometheus
    url: http://cortex-query-frontend:9009/api/prom
    jsonData:
      httpHeaderName1: "X-Scope-OrgID"
    secureJsonData:
      httpHeaderValue1: "team-platform"
  - name: Cortex-Team-Backend
    type: prometheus
    url: http://cortex-query-frontend:9009/api/prom
    jsonData:
      httpHeaderName1: "X-Scope-OrgID"
    secureJsonData:
      httpHeaderValue1: "team-backend"
---

Cortex מול Thanos: השוואה מעשית

Cortex עדיף בתרחישים הדורשים הפרדת נתונים קפדנית וזמן אמת. למקרים פשוטים, Thanos עשוי להיות זול יותר.

מה כלול בהקמת Cortex שלנו

• ביקורת תשתית Prometheus קיימת
• עיצוב ארכיטקטורה: בחירת אחסון אובייקטים, סכמת דיירים, מדיניות שמירה
• פריסת Cortex במצב בינארי יחיד או מיקרוסרביסים
• אינטגרציה עם Prometheus קיים (remote_write) ו-Grafana
• הגדרת ניטור Cortex (לוחות מחוונים של Grafana, התראות)
• תיעוד תפעולי ו-runbook
• העברת ידע לצוות הלקוח

לוח זמנים: 3 עד 10 ימים תלוי במורכבות. העלות מחושבת באופן אישי.

למה לבחור בנו?

5 שנות ניסיון עם Prometheus, Cortex ו-Thanos. למעלה מ-20 פרויקטים מוצלחים בפריסת ערימות observability. אנו מבטיחים SLA של 99.9% על אשכול Cortex. קבלו ייעוץ למשימה שלכם — נבחן את הפרויקט ונציע את הפתרון האופטימלי. צרו קשר כדי לדון בפרטים.