מדריך לרישום מרכזי עם Grafana Loki, Promtail ו-Alloy

מדריך לאיסוף לוגים מרכזי עם Grafana Loki, Promtail ו-Alloy

לעתים קרובות אנו שומעים מפתחים מתלוננים: "אין לוגים, ואלה שיש נמצאים ב-Elasticsearch, שאוכל 200 GB של זיכרון RAM ועולה הון תועפות." Elasticsearch מבצע אינדוקס לכל דבר, ומספק חיפוש גמיש, אבל במחיר חומרה. Grafana Loki מציעה גישה שונה: אינדוקס רק למטא-דאטה (labels), ואחסון לוגים דחוסים ב-S3. זה מקצץ עלויות פי 3–5 בנפחים מ-100 GB ליום. בהערכות שלנו, מעבר ל-Loki מפחית את עלויות אחסון הלוגים ב-60–70% בהשוואה ל-Elasticsearch. עבור עומס טיפוסי של 100 GB ליום, זה מתורגם לחיסכון של $1,400 בחודש.

למה LogQL הוא המפתח לניתוח לוגים

LogQL היא שפת השאילתות של Loki, המחולקת לבוררי סטרימים (סינון לפי labels) וצינור עיבוד (עיבוד תוכן). הצינור יכול לכלול json, logfmt, regexp, line_format, ופונקציות אגרגציה כמו PromQL. לדוגמה, מדדי שגיאות לפי שירות:

// Stream selector + filter
{namespace="production", app="payment-service"} |= "error"

// Pipeline с JSON-парсингом и форматированием
{app="api-gateway"} | json | status_code >= 500 | line_format "{{.method}} {{.path}} → {{.status_code}} ({{.duration_ms}}ms)"

// Metric query — rate ошибок по сервисам
sum by (app) ( rate( {namespace="production"} | json | status_code >= 500 [5m] ) )

מתוך תיעוד Grafana LogQL

שאילתה זו יכולה לשמש ב-Grafana ככלל התראה — בדיוק כמו מדד Prometheus. שאילתות מדדיות של LogQL מאפשרות SLOs ותקציב שגיאות המבוססים על לוגים.

כיצד להגדיר נכון תיוג ולהימנע מ-Cardinality

Loki מבצע אינדוקס רק ל-labels, לא לתוכן הלוג. Cardinality גבוה של labels פוגע בביצועים — כל שילוב ייחודי של labels יוצר סטרים נפרד. דפוסים אסורים:

---
# ПЛОХО — trace_id в labels создаёт миллионы streams
labels:
  trace_id: "abc123def456..."

# ПЛОХО — user_id в labels
labels:
  user_id: "12345"

# ХОРОШО — только стабильные идентификаторы
labels:
  namespace: "production"
  app: "payment-service"
  pod: "payment-service-7d9f8b-xkqp2"
  level: "error"
---

// Stream selector + filter {namespace="production", app="payment-service"} |= "error" // Pipeline с JSON-парсингом и форматированием {app="api-gateway"} | json | status_code >= 500 | line_format "{{.method}} {{.path}} → {{.status_code}} ({{.duration_ms}}ms)" // Metric query — rate ошибок по сервисам sum by (app) ( rate( {namespace="production"} | json | status_code >= 500 [5m] ) ) צריך להיות בגוף הלוג, לא ב-labels. כדי לקפוץ מ-Loki ל-Jaeger, השתמש ב-# ПЛОХО — trace_id в labels создаёт миллионы streams labels: trace_id: "abc123def456..." # ПЛОХО — user_id в labels labels: user_id: "12345" # ХОРОШО — только стабильные идентификаторы labels: namespace: "production" app: "payment-service" pod: "payment-service-7d9f8b-xkqp2" level: "error" במקור הנתונים של Grafana.

שלבים לפריסת Loki עם Helm

1. התקן את Helm 3 אם אינו מותקן כבר.
2. הוסף את מאגר Grafana: trace_id.
3. צור קובץ derivedFields עם תצורת S3, מדיניות שמירה (לדוגמה, 30 ימים), וסקיילינג.
4. הרץ את פקודת ההתקנה: helm repo add grafana https://grafana.github.io/helm-charts.

שלבים אלה מיועדים למצב SimpleScalable. התקנות מורכבות יותר דורשות הגדרה נוספת של Kafka ו-Consul.

ארכיטקטורת פריסה

Loki פועלת במספר מצבים. עבור רוב המקרים בייצור, loki-values.yaml דרך Helm מתאים:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm upgrade --install loki grafana/loki \
  --namespace logging \
  --create-namespace \
  -f loki-values.yaml

---
# loki-values.yaml
loki:
  auth_enabled: false
  commonConfig:
    replication_factor: 1
  storage:
    type: s3
    s3:
      endpoint: s3.eu-west-1.amazonaws.com
      region: eu-west-1
      bucketnames: my-loki-chunks
      access_key_id: ${AWS_ACCESS_KEY_ID}
      secret_access_key: ${AWS_SECRET_ACCESS_KEY}
      s3forcepathstyle: false
      insecure: false
  schemaConfig:
    configs:
      - from: "2020-01-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  limits_config:
    ingestion_rate_mb: 64
    ingestion_burst_size_mb: 128
    max_query_parallelism: 32
    max_streams_per_user: 10000
    retention_period: 744h
    reject_old_samples: true
    reject_old_samples_max_age: 168h
  compactor:
    retention_enabled: true
deploymentMode: SimpleScalable
backend:
  replicas: 2
read:
  replicas: 2
write:
  replicas: 2
minio:
  enabled: false

השוואת מצבי פריסה

SimpleScalable הוא הפשרה האופטימלית לעומסים עד 50 GB ליום. במצב זה, הרכיבים (read, write, backend) מופרדים ויכולים להתקנה בקנה מידה עצמאי, ללא המורכבות הנוספת של microservices (Kafka, Consul). עבור צוותים קטנים, זה מקצר את זמן היציאה לשוק ומפשט את התפעול.

השוואת סוכני איסוף לוגים

טעויות אופייניות עם Loki

• Cardinality גבוה של labels — שימוש ב-helm upgrade --install loki grafana/loki --namespace logging --create-namespace -f loki-values.yaml או simple-scalable כ-labels פוגע בביצועים. בדוק תמיד את לשונית 'Series' ב-Grafana.
• מדיניות שמירה חסרה — ללא הגדרת compactor ומדיניות שמירה, מסד הנתונים של הלוגים גדל ללא הגבלה, וגורם לגלישת אחסון.
• Single-binary בייצור — מצב single-binary חסר סובלנות לתקלות וסקיילינג. השתמש ב-SimpleScalable או Microservices.
• התעלמות מסכימת אינדוקס — מגרסה 13, נעשה שימוש ב-tsdb store. אל תשתמש בסכמות ישנות (boltdb-shipper) שלא לצורך.

מה כלול בשירות שלנו

אנו מציעים שירות סוהר:

• ביקורת של תשתית הלוגים הנוכחית (נפחים, מקורות, מדיניות שמירה).
• פריסת Loki (מצב SimpleScalable או Microservices) עם Helm, הגדרת אחסון S3.
• התקנה והגדרה של Promtail/Alloy על כל המארחים.
• כתיבת כללי תיוג ושאילתות LogQL למדדים מרכזיים.
• יצירת לוחות מחוונים והתראות ב-Grafana (SLI, תקציב שגיאות).
• תיעוד והדרכת צוות.
• גישה ללוחות מחוונים של Grafana ואחסון לוגים.
• תמיכה לאחר הפריסה למשך 30 ימים.

לצוות שלנו ניסיון של למעלה מ-5 שנים ב-DevOps ועשרות הטמעות של Loki בפרויקטים מסטארטאפים ועד ארגונים. אנו מספקים ערבות יציבות ו-SLA לאירועים.

צור קשר לביקורת של תשתית הלוגים שלך — אנו נעריך נפחים ונבחר תצורה אופטימלית. הזמן הטמעת Loki והפחת את עלויות הלוגים ללא אובדן פונקציונליות.