מעקב אחרי אמינות של אשכולות Kafka

במאמר הזה מוסבר איך לנטר אשכול של שירות מנוהל ל-Apache Kafka כדי לוודא את המהימנות של עומסי העבודה של Kafka.

סקירה כללית

מהימנות היא היכולת של מערכת לפעול בצורה נכונה ועקבית לאורך זמן. בעומסי עבודה שמבוססים על Kafka, המהימנות כוללת את אשכולות Kafka עצמם, וגם את אפליקציות הלקוח שמפיקות הודעות וצורכות אותן.

השירות המנוהל ל-Apache Kafka מיועד לסבול כשלים נפוצים רבים ולשחזר את עצמו מהם. לדוגמה, השירות ממקם רפליקות באזורים שונים כדי לספק עמידות בפני תקלות, ומפעיל מחדש באופן אוטומטי ברוקרים שנכשלים. עם זאת, יש גורמים אחרים שמשפיעים על המהימנות ולא נמצאים בשליטה ישירה של השירות, כמו:

  • הגדרת לקוח
  • עומס על האשכול, כולל עומס ממוצע ושיאים
  • מספר המחיצות והעותקים
  • הגדרות של נושאים, כמו משך השמירה של הודעות

כדי להבטיח פעולה מהימנה, חשוב לעקוב אחרי הפרמטרים התפעוליים האלה של האשכול ולשמור אותם בטווחים המומלצים. בקטעים הבאים מתוארים כמה מדדים חשובים שקשורים למהימנות.

קיבולת האשכול

כדי למנוע עומס יתר על אשכול, כדאי לעקוב אחרי האותות הבאים. אתם יכולים ליצור התראות כדי לקבל הודעה אם הם חורגים מהטווח המומלץ למשך תקופה ממושכת.

  • ניצול המעבד (CPU). מומלץ לשמור על ניצול CPU מתחת ל-80% בכל הברוקרים.

  • ניצול הדיסק של הברוקר: חשוב לוודא שניצול הדיסק של הברוקר לא עולה על 80%.

  • מספר המחיצות. מומלץ להגדיר פחות מ-4,000 מחיצות לכל ברוקר ופחות מ-100,000 מחיצות לכל אשכול.

אם הקיבולת של האשכול נמוכה, כדאי לנסות את הפתרונות הבאים:

  • הגדלת מספר ליבות ה-vCPU באשכול. מידע נוסף זמין במאמר בנושא עדכון של אשכול Kafka.

  • מרחיבים את האשכול כדי להוסיף עוד ברוקרים. במאמר Broker provisioning מוסבר איך השירות מספק ברוקרים.

בטבלה הבאה מוצגות שאילתות של Prometheus Query Language‏ (PromQL) למדדים האלה שאפשר להוסיף ללוח בקרה מותאם אישית של Cloud Monitoring.

אותשאילתת PromQL
ניצול יחידת העיבוד המרכזית (CPU) 
rate(
  {
    "managedkafka.googleapis.com/cpu/core_usage_time",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/cpu/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
ניצול הדיסק של המתווך 
max_over_time(
  {
    "managedkafka.googleapis.com/disk/used_bytes",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
גודל הפלח לכל מחיצה 
# Assumes that segment files are 225 MiB. Check your cluster configuration.
2*225*(1024*1024) * max_over_time(
  {
    "managedkafka.googleapis.com/partitions",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
מחיצות לכל ברוקר 
max by (resource_container, location, cluster_id, broker_index) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
מחיצות לכל אשכול 
max by (resource_container, location, cluster_id) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)

חוסר איזון בחלוקה למחיצות

עומס לא אחיד עלול למנוע מאשכול Kafka לטפל בבקשות של לקוחות בצורה תקינה. מספר המחיצות שמוקצות למתווך יחיד צריך להיות בטווח של כ-10% ממספר המחיצות הממוצע לכל מתווך. תאתר ערכים של חריג חשוד טעות במדד הזה.

כדי לשמור על מחיצות מאוזנות, מומלץ להפעיל איזון מחדש אוטומטי בהגדלה באשכול.

בטבלה הבאה מוצגות שאילתות PromQL שאפשר להשתמש בהן כדי לעקוב אחרי חוסר איזון במחיצות.

אותשאילתת PromQL
מספר המחיצות לכל ברוקר 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
חוסר איזון בחלוקה למחיצות 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
/ on (resource_container, location, cluster_id)
  group_left avg by (resource_container, location, cluster_id) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
) - 1

שכפול מחיצות

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

אפשר להשתמש באותות הבאים כדי לעקוב אחרי שכפול המחיצות:

  • Under minimum in-sync replicas (ISRs). אם למחיצה יש פחות רפליקות ISR מסונכרנות מהמינימום שהוגדר (min.insync.replicas), קיים סיכון חמור לאובדן נתונים ולזמינות. בדרך כלל, המצב הזה נגרם בגלל קיבולת לא מספקת באחד או יותר מהברוקרים, או בגלל כשלים בתשתית.

  • מחיצות עם פחות מדי שכפולים. מחיצה לא משוכפלת מספיק אם מספר העותקים המשוכפלים שלה נמוך מגורם השכפול. אם מחיצה לא משוכפלת במשך עשרות דקות, יכול להיות שיש בעיה בברוקרים, בקיבולת האחסון או במשהו אחר.

    במהלך הפעלה מחדש מתגלגלת, המתווכים לא זמינים כי הם מופעלים מחדש, מה שגורם לשכפול חלקי זמני. המצב הזה צפוי ולא דורש התערבות.

בטבלה הבאה מוצגות שאילתות PromQL שאפשר להשתמש בהן כדי לעקוב אחרי השכפול.

אותשאילתת PromQL
מתחת לערכי ה-ISR המינימליים 
max by (
  resource_container,
  location,
  cluster_id
) (
  max_over_time(
    {
      "managedkafka.googleapis.com/broker/under_min_isr_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
במהלך שכפול 
max by (
  resource_container,
  location,
  cluster_id
) (
  min_over_time(
    {
      "managedkafka.googleapis.com/broker/under_replicated_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[10m:${__interval}]
  )
)

המאמרים הבאים