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

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

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

מדדים בצד השרת

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

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

תפוקה

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

  • קצב ההודעות, לכל ברוקר ולכל נושא.
  • קצב בייטים, לכל ברוקר ולכל נושא.
  • קצב בקשות. לקוח שהוגדר בצורה שגויה עלול להציף את המתווכים בבקשות קטנות (0-1,000 בייטים לבקשה) בקצב גבוה, וכך להפחית את קצב העברת הנתונים.
  • זמן אחזור של בקשה. עליות חדות בזמן האחזור של בקשות של יצרנים יכולות להצביע על עומס לא מאוזן או על בעיה בהגדרת הלקוח.

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

שיעורי השגיאות בבקשות

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

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

  • כשלים באשכול עלולים למנוע מהברוקר להגיב לבקשות בכלל.

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

הזמן שעובר עד שהצרכן קונה

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

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

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

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

אותשאילתת PromQL
תפוקה: קצב ההודעות לכל מתווך 
sum by (resource_container, location, cluster_id, broker_index) (
  rate(
    {
      "managedkafka.googleapis.com/message_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
קצב העברת נתונים: שיעורי ההודעות לכל מתווך לכל נושא, ל-5 הנושאים הגדולים ביותר 
topk(5,
  sum by (resource_container, location, cluster_id, broker_index, topic_id) (
    rate(
      {
        "managedkafka.googleapis.com/message_in_count",
        monitored_resource="managedkafka.googleapis.com/Topic"
      }[${__interval}]
    )
  )
)
תפוקה: רוחב פס לכל נושא וברוקר 
sum by (resource_container, location, cluster_id, broker_index, topic_id) (
  rate(
    {
      "managedkafka.googleapis.com/byte_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
קצב בקשות 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/request_count",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "request"="Produce"
    }[${__interval}]
  )
)
קצב בקשות, סה"כ באשכול 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_request_count",
      monitored_resource="managedkafka.googleapis.com/Topic",
      "request"="Produce"
    }[${__interval}]
  )
)
זמן האחזור של הבקשה 
sum by (resource_container, location, cluster_id, broker_index, request) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/request_latencies",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "percentile"="95",
      "request"="Produce"
    }[${__interval}]
  )
)
מספר השגיאות בבקשות 
sum by (resource_container, location, cluster_id, broker_index, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_error_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
פיגור צרכן: 5 המחיצות המובילות לפי פיגור היסט 
topk(5,
  max by (resource_container, location, cluster_id, topic_id, partition_index) (
    max_over_time(
      {
        "managedkafka.googleapis.com/offset_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup"
      }[${__interval}]
    )
  )
)
פיגור צרכנים: 5 קבוצות הצרכנים המובילות לפי פיגור היסט 
topk(5,
  max by (resource_container, location, cluster_id, consumer_group_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/offset_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup"
      }[${__interval}]
    )
  )
)

מדדים בצד הלקוח

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

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

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

אם הלקוחות שלכם פועלים ב-Compute Engine, ב-Google Kubernetes Engine או ב-Cloud Run, אתם יכולים להשתמש במדדים מבוססי-יומנים ב-Cloud Monitoring כדי לזהות שיעורי שגיאות גבוהים ביומנים. עם זאת, חלק מלקוחות Kafka מסתירים חריגות שמובילות לניסיונות חוזרים ממושכים, אלא אם מגדירים רמות גבוהות יותר של רישום ביומן. לכן, כדאי גם לעקוב אחרי זמני האחזור של הבקשות.

לקוחות Java חושפים מדדים רבים דרך Java Management Extensions‏ (JMX). למידע נוסף, קראו את המאמר Monitoring במסמכי התיעוד של Apache Kafka. אם אפשר, כדאי לתת עדיפות להגדרת הלקוחות כך שידווחו על המדדים הבאים:

  • שיעורי השגיאות בבקשות (kafka.producer:type=producer-metrics,client-id="{client-id}")
  • זמן אחזור ממוצע של בקשה (kafka.producer:type=producer-metrics,client-id="{client-id}")

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

השבתה זמנית של אותות אכיפה

אם נתקלתם בבעיות באפליקציות הלקוח, נסו את הפתרונות הבאים:

  • מחפשים עומס לא מאוזן בין המתווכים (מתווכים חמים). מוודאים שהאיזון האוטומטי מופעל באשכול.

  • אם קצב הבקשות נראה גבוה באופן חריג, כדאי לבדוק אם הלקוח שולח מספר גדול של בקשות קטנות. בודקים את ההגדרות של max.request.size ו-batch.size אצל המפיק.

  • בודקים את הגדרות הלקוח לאימות, לרשת ולבקרת זרימה.

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

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

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

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