Fluent: מדוע חשוב להגדיר את מאגר הפלט

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

Fluentd הוא אספן יומנים מודרני ואוניברסלי שצובר יותר ויותר פופולריות והצטרף ל-Cloud Native Computing Foundation, ולכן וקטור הפיתוח שלו מתמקד בשימוש בשילוב עם Kubernetes.

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

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

הבעיה של שכפול מסמכים

בפרויקטים שלנו, Fluentd נפרסת כ-DaemonSet (מושק אוטומטית במופע אחד בכל צומת של אשכול Kubernetes) ומנטרת יומני מיכל סטdout ב-/var/log/containers. לאחר איסוף ועיבוד, היומנים בצורת מסמכי JSON נשלחים אל ElasticSearch, מועלים בצורת אשכול או עצמאית, בהתאם להיקף הפרויקט ולדרישות לביצועים וסובלנות תקלות. Kibana משמש כממשק הגרפי.

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

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

עם זאת, ישנם מספר מסמכים ב-ElasticSearch המכילים הודעה זו:

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "HgGl_nIBR8C-2_33RlQV",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "IgGm_nIBR8C-2_33e2ST",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

יתר על כן, יכולות להיות יותר משתי חזרות.

בזמן תיקון בעיה זו ביומני Fluent, אתה יכול לראות מספר רב של אזהרות עם התוכן הבא:

2020-01-16 01:46:46 +0000 [warn]: [test-prod] failed to flush the buffer. retry_time=4 next_retry_seconds=2020-01-16 01:46:53 +0000 chunk="59c37fc3fb320608692c352802b973ce" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="could not push logs to Elasticsearch cluster ({:host=>"elasticsearch", :port=>9200, :scheme=>"http", :user=>"elastic", :password=>"obfuscated"}): read timeout reached"

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

2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fc3fb320608692c352802b973ce" 
2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fad241ab300518b936e27200747" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fc11f7ab707ca5de72a88321cc2" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fb5adb70c06e649d8c108318c9b" 
2020-01-16 01:47:15 +0000 [warn]: [kube-system] retry succeeded. chunk_id="59c37f63a9046e6dff7e9987729be66f"

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

בקיבנה זה נראה כך:

הפתרון

ישנן מספר אפשרויות לפתרון בעיה זו. אחד מהם הוא המנגנון המובנה בתוסף Fluent-plugin-elasticsearch ליצירת hash ייחודי לכל מסמך. אם תשתמש במנגנון זה, ElasticSearch תזהה חזרות בשלב ההעברה וימנע כפילות של מסמכים. אך עלינו לקחת בחשבון כי שיטה זו לפתרון הבעיה מתקשה בחקירה ואינה מבטלת את השגיאה בהיעדר פסק זמן, ולכן נטשנו את השימוש בה.

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

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

בזמן שהבעיה תועדה, התצורה נראתה כך:

 <buffer>
        @type file
        path /var/log/fluentd-buffers/kubernetes.test.buffer
        flush_mode interval
        retry_type exponential_backoff
        flush_thread_count 2
        flush_interval 5s
        retry_forever
        retry_max_interval 30
        chunk_limit_size 8M
        queue_limit_length 8
        overflow_action block
      </buffer>

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

• flush_interval - מרווח זמן שלאחריו המאגר מנוקה.
• queue_limit_length - המספר המרבי של נתחים בתור.
• request_timeout הוא הזמן שבו נוצר החיבור בין Fluentd ל- ElasticSearch.

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

2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:block

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

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

אם תגדיר את גודל ה-chunk chunk_limit_size ליותר מ-32 מגה-בייט, אז ElasticSeacrh לא יקבל זאת, מכיוון שהחבילה הנכנסת תהיה גדולה מדי. לכן, אם אתה צריך להגדיל את המאגר עוד יותר, עדיף להגדיל את אורך התור המקסימלי queue_limit_length.

כאשר המאגר מפסיק לעלות על גדותיו ונשארת רק ההודעה על פסק זמן לא מספיק, אתה יכול להתחיל להגדיל את הפרמטר request_timeout. עם זאת, אם תגדיר את הערך ליותר מ-20 שניות, האזהרות הבאות יתחילו להופיע ביומני Fluent:

2020-01-21 09:55:33 +0000 [warn]: [test-dev] buffer flush took longer time than slow_flush_log_threshold: elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev" 

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

אלגוריתם הבחירה המוכלל הוא כדלקמן:

1. הגדר request_timeout לערך המובטח גדול מהנדרש (מאות שניות). במהלך ההגדרה, הקריטריון העיקרי להגדרה הנכונה של פרמטר זה יהיה היעלמות האזהרות בגין חוסר פסק זמן.
2. המתן להודעות על חריגה מסף slow_flush_log_threshold. טקסט האזהרה בשדה elapsed_time יציג את הזמן האמיתי שהמאגר נוקה.
3. הגדר את request_timeout לערך הגדול מהערך המקסימלי של elapsed_time שהושג במהלך תקופת התצפית. אנו מחשבים את ערך request_timeout כ-elapsed_time + 50%.
4. כדי להסיר אזהרות על שטיפות מאגר ארוכות מהיומן, אתה יכול להעלות את הערך של slow_flush_log_threshold. אנו מחשבים ערך זה כ-elapsed_time + 25%.

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

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

צומת-1
צומת-2
צומת-3
צומת-4

לפני אחרי
לפני אחרי
לפני אחרי
לפני אחרי

לא הצליח לשטוף את המאגר
1749/2
694/2
47/0
1121/2

ניסיון חוזר הצליח
410/2
205/1
24/0
241/2

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

מסקנה

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

קרא גם מאמרים אחרים בבלוג שלנו:

• לכו ו- Zabbix 5.0 הפכו לחברים
• שדרוג אשכול Kubernetes ללא השבתה
• Kubernetes: מדוע כל כך חשוב להגדיר את ניהול משאבי המערכת?
• שלושה טריקים פשוטים לכווץ תמונות Docker
• גיבוי של מספר רב של פרויקטי אינטרנט הטרוגניים

מקור: www.habr.com