רישום מרכזי של Kubernetes עם הגדרת Datadog Logs

אתה מבזבז שעות בחיפוש אחר שגיאות ביומנים הפזורים על פני מאות פודים של Kubernetes. ריכוז יומנים עם Datadog Logs פותר זאת: איסוף בזמן אמת, אינדוקס והתראות. אבל העלויות יכולות להמריא אם לא שולטים בנפח. מהנדס מנוסה יודע להגדיר מסנני החרגה ומדדים מבוססי יומן כדי לקצץ בהוצאות ב-40-60% מבלי לאבד נתונים קריטיים. אנו מגדירים את Datadog Logs מקצה לקצה תוך 3–7 ימים — מהתקנת ה-Agent ועד לדשבורדים והתראות מוכנים.

כיצד לפרוס את Datadog Agent ב-Kubernetes

---
# datadog-values.yaml для Helm datadog:
apiKey: ${DD_API_KEY}
site: "datadoghq.eu" # или datadoghq.com
logs:
  enabled: true
  containerCollectAll: true
  containerCollectUsingFiles: true
processAgent:
  enabled: false
apm:
  portEnabled: false
clusterAgent:
  enabled: true
agents:
  tolerations:
    - operator: Exists
  resources:
    requests:
      cpu: 200m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 512Mi

helm upgrade --install datadog datadog/datadog \
  --namespace monitoring \
  --create-namespace \
  --values datadog-values.yaml \
  --set datadog.apiKey=$(kubectl get secret datadog-secret -o jsonpath='{.data.api-key}' | base64 -d)

הפריסה אורכת כשעה. לאחר מכן, ה-Agent אוסף אוטומטית יומנים מכל הקונטיינרים — אבל ללא פענוח, הם מגיעים כ-JSON עם שדות מקוננים עמוק. כדי להפוך אותם לנתונים מובנים, יש צורך ב-annotations וב-Log Pipelines. כפי שמצוין בתיעוד Datadog: "Datadog Agent אוסף אוטומטית יומנים מהקונטיינרים שלך" — תיעוד Datadog.

כיצד להגדיר Annotations לפענוח אוטומטי

Datadog תומך ב-Pod annotations להגדרת איסוף ופענוח יומנים אוטומטי:

---
# Deployment с аннотациями для Datadog metadata:
annotations:
  ad.datadoghq.com/app.logs: |
    [{ "source": "python", "service": "payments-api", "log_processing_rules": [{ "type": "multi_line", "name": "python_traceback", "pattern": "Traceback|^\\s+File" }] }]

עבור NGINX:

---
ad.datadoghq.com/nginx.logs: |
  [{ "source": "nginx", "service": "web-frontend", "tags": ["env:production", "team:frontend"] }]
---

ללא # datadog-values.yaml для Helm datadog: apiKey: ${DD_API_KEY} site: "datadoghq.eu" # или datadoghq.com logs: enabled: true containerCollectAll: true containerCollectUsingFiles: true processAgent: enabled: false apm: portEnabled: false clusterAgent: enabled: true agents: tolerations: - operator: Exists resources: requests: cpu: 200m memory: 256Mi limits: cpu: 500m memory: 512Mi , שגיאות מרובות שורות (traces) מגיעות כערכים נפרדים — מה שהופך את הניתוח לבלתי אפשרי. הניסיון שלנו מראה ש-80% מבעיות איסוף היומנים נובעות מהיעדר כללי multi-line.

כיצד להפחית את הנפח הנקלט עם Exclusion Filters

Datadog Logs מחויב לפי נפח הנקלט. ניתן להגדיר מסנני החרגה ב-helm upgrade --install datadog datadog/datadog \ --namespace monitoring \ --create-namespace \ --values datadog-values.yaml \ --set datadog.apiKey=$(kubectl get secret datadog-secret -o jsonpath='{.data.api-key}' | base64 -d) של ה-Agent או דרך הממשק:

---
# /etc/datadog-agent/datadog.yaml
logs_config:
  processing_rules:
    - type: exclude_at_match
      name: exclude_health_checks
      pattern: "GET /health HTTP"
    - type: exclude_at_match
      name: exclude_debug_staging
      pattern: '"level":"debug"'

דרך ממשק Datadog: Log Pipelines → Filters → הוסף מסנן החרגה עם התנאי # Deployment с аннотациями для Datadog metadata: annotations: ad.datadoghq.com/app.logs: | [{ "source": "python", "service": "payments-api", "log_processing_rules": [{ "type": "multi_line", "name": "python_traceback", "pattern": "Traceback|^\\s+File" }] }] . זה מפחית את הנפח הנקלט ב-40-60% בסביבות staging. בפועל, שילוב של מסננים לפי env, status ו-source מוריד משמעותית את עלויות Datadog החודשיות לפרויקט עם 50 GB ליום.

למה Log-Based Metrics חוסכים בתקציב

Datadog מאפשר לייצר מדדים מיומנים מבלי לאחסן את היומנים עצמם — שימושי למגמות מבלי להגדיל עלויות אחסון:

ב-Logs → Generate Metrics: צור ad.datadoghq.com/nginx.logs: | [{ "source": "nginx", "service": "web-frontend", "tags": ["env:production", "team:frontend"] }] מהפילטר log_processing_rules. המדד זמין ב-Datadog Metrics ובדשבורדים לצד מדדי מערכת.

מדדים מבוססי יומן מאפשרים לקבל מגמות לשגיאות, זמן השהיה, ספירת בקשות לפי status — מבלי לאחסן את היומנים הגולמיים. זה אומר שאתה משלם רק על נפח המדדים (שקטן בהרבה) ולא על ג'יגה-בייט של יומנים. תכונה זו מובנית ב-Datadog: פשוט הגדר פילטר ומדוד. אנו מגדירים 5-10 מדדים מרכזיים לפרויקט — מספיק לניטור בסיסי. אופטימיזציה כזו מובילה לחיסכון משמעותי בתקציב ה-observability.

בעיות טיפוסיות והפתרונות שלהן

אם ה-Agent לא רואה יומנים, בדוק קודם RBAC: ה-ClusterRole של ה-Agent חייב להיות עם גישה ל-pods/logs ו-events. לאחר מכן tolerations: אם ה-Agent לא מתוזמן על הצמתים, יומנים לא נאספים. טעות נפוצה היא לשכוח להגדיר datadog.yaml ב-values. מניסיוננו, רוב המקרים נפתרים תוך 15 דקות לאחר הגדרה נכונה.

תהליך ההגדרה מקצה לקצה

1. ביקורת על התשתית הקיימת — סביבות, אפליקציות, פורמטי יומנים.
2. תכנון ה-pipeline — מקורות, מסנני החרגה, retention, מדדים מבוססי יומן, דשבורדים.
3. יישום — פריסת ה-Agent, annotations, הגדרת Pipeline, בדיקות.
4. מסירת תיעוד — runbook להוספת מקורות חדשים, פתרון תקלות.
5. הדרכת צוות — כיצד להשתמש ב-Datadog Logs, חיפוש, בניית התראות.

ציר זמן: 3 עד 7 ימים תלוי במספר השירותים. העלות מחושבת באופן אישי — אנו מעריכים את הפרויקט שלך.

מה כלול

• Helm chart עבור Datadog Agent עם הגדרות אופטימליות לתשתית שלך.
• הגדרת Log Pipeline: פענוח, מסנני החרגה, כללי multi-line.
• סט מדדים מבוססי יומן לשירותים מרכזיים (שגיאות, זמן השהיה, RPS).
• דשבורדים של Datadog: סיכום יומנים, התראות שגיאות.
• Runbook לצוות שלך: הוראות שלב-אחר-שלב להוספת מקורות חדשים ובעיות נפוצות.
• הדרכת צוות (סדנה של שעתיים).

השוואת גישות לרישום יומנים

Datadog מנצח בפשטות התפעול אבל יקר יותר בנפחים גבוהים. הבחירה תלויה בתקציב ובזמינות DevOps. בהשוואה ל-Elasticsearch: Datadog נפרס פי 2 מהר יותר (שעות לעומת ימים) ואינו דורש תקורה תפעולית.

מסנני החרגה מומלצים

למהנדסים שלנו יש ניסיון של למעלה מ-5 שנים עם Datadog Logs ויותר מ-50 פרויקטי observability. אנו מבטיחים שהיומנים ייאספו כראוי, הדשבורדים ישקפו מדדים מרכזיים, ומסנני ההחרגה יחסכו בתקציב שלך. קבל ייעוץ לפרויקט שלך. הזמן ביקורת על הגדרת היומנים הנוכחית שלך — נכין הצעה עם תוכנית מפורטת.