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

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

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

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

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

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

תפוקה

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

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

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

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

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

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

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

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

עיכוב בעדכון המרות

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

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

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

מומלץ ליצור לוחות בקרה והתראות בהתאמה אישית כדי לעקוב אחרי האותות האלה. בטבלה הבאה מוצגות שאילתות של Prometheus Query Language (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, broker_index, topic_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/consumer_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartition"
      }[${__interval}]
    )
  )
)

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

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

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

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

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

לקוחות Java חושפים מדדים רבים באמצעות Java Management Extensions‏ (JMX). מידע נוסף זמין במאמר בנושא מעקב במסמכי התיעוד של 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 במפיק.

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

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

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

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