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

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

סקירה כללית

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

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

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

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

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

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

  • ניצול המעבד (CPU). נסו לשמור על ניצולת מעבד (CPU) של פחות מ-80% בכל ה-brokers.

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

  • גודל הדיסק. כנקודת התחלה בטוחה, מומלץ להגדיר לפחות 2*(segment.bytes) לכל מחיצה לכל ברוקר. בפועל, דרישות הדיסק בפועל הן לעיתים קרובות נמוכות בהרבה.

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

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

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

בטבלה הבאה מוצגות שאילתות ב-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 לשרת בקשות של לקוחות בצורה תקינה. מספר המחיצות שמוקצות ל-broker יחיד צריך להיות בטווח של כ-10% ממספר המחיצות הממוצע ל-broker. חפשו ערכים חריגים במדד הזה.

כדי לשמור על מחיצות מאוזנות, מומלץ להפעיל באשכול את האפשרות auto rebalancing on scale up.

בטבלה הבאה מוצגות שאילתות 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

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

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

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

  • פחות מהמספר המינימלי של רפליקות מסונכרנות (ISR). אם למחיצה יש פחות עותקים משוכפלים מסונכרנים (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}]
  )
)

מעקב אחרי מכסת בקשות ההרשאה

כשלקוח מתחבר לאשכול, אישור החיבור נספר במכסה Cluster authenticate connection requests per minute per project per region. כל האשכולות בפרויקט ובאזור חולקים את המכסה הזו, ואם חורגים ממנה, חיבורים חדשים של לקוחות נחסמים. נסו לשמור על ניצול מכסה של פחות מ-80%, וצרו התראות שיודיעו לכם אם הניצול נשאר גבוה.

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

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

  • לבקש להגדיל את המכסה. מידע נוסף על מכסות ומגבלות

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

אותשאילתת PromQL
שלושת הפרויקטים והאזורים עם ניצול המכסה הגבוה ביותר של בקשות הרשאה 
topk(3,
  sum by (project_id, location) (
    rate(
      {
        "serviceruntime.googleapis.com/quota/rate/net_usage",
        monitored_resource="consumer_quota",
        service="managedkafka.googleapis.com",
        quota_metric="managedkafka.googleapis.com/cluster_authenticate_requests"
      }[${__interval}]
    )
  )
  / (
    min by (project_id, location) (
      min_over_time(
        {
          "serviceruntime.googleapis.com/quota/limit",
          monitored_resource="consumer_quota",
          service="managedkafka.googleapis.com",
          quota_metric="managedkafka.googleapis.com/cluster_authenticate_requests",
          limit_name="ClusterAuthPerMinutePerProjectPerRegion"
        }[${__interval}]
      )
    )
    / 60
  )
)

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

‫Apache Kafka®‎ הוא סימן מסחרי רשום של The Apache Software Foundation או של השותפים העצמאיים שלה בארצות הברית או במדינות אחרות.