תאימות ההגדרות ל-Fluentd במעלה הזרם

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

שינויים בתחביר בין סוכן ה-Logging מדור קודם לבין Fluentd במעלה הזרם

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

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

הגדרת תוסף הפלט

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

תחביר של סוכן Logging מדור קודם תחביר Fluentd של מקור נתונים הערות
לא רלוונטי <buffer> תוספי הפלט של Fluentd תומכים בקטע <buffer>, מתחת לקטע <match>, כדי להגדיר את האגירה של אירועים. מידע נוסף זמין במאמר בנושא הגדרה: קטע מאגר הנתונים הזמני במסמכי התיעוד של Fluentd.
buffer_type @type
buffer_path path
buffer_chunk_limit chunk_limit_size
disable_retry_limit retry_forever
retry_limit retry_max_times
max_retry_wait retry_max_interval
num_threads flush_thread_count
partial_success לא רלוונטי צריך להסיר את הפרמטר הזה. ב-Fluentd במעלה הזרם, האפשרות 'הצלחה חלקית' מופעלת כברירת מחדל, והמערכת משמיטה רק שורות לא תקינות.

הדוגמה הבאה מציגה את ההגדרה של פלאגין הפלט google-cloud בסוכן Logging מדור קודם:

<match **>
  @type google_cloud
  buffer_type file
  buffer_path /var/log/google-fluentd/buffers
  buffer_chunk_limit 512KB
  flush_interval 5s
  disable_retry_limit false
  retry_limit 3
  retry_wait 10
  max_retry_wait 300
  num_threads 8
</match>

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

<match **>
  @type google_cloud
  <buffer>
    @type file
    path /var/log/google-fluentd/buffers
    chunk_limit 512KB
    flush_interval 5s
    retry_forever false
    retry_max_times 3
    retry_wait 10
    retry_max_interval 300
    flush_thread_count 8
  </buffer>
</match>

הגדרת פלאגין קלט

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

תחביר של סוכן Logging מדור קודם תחביר Fluentd של מקור נתונים הערות
format <parse> מידע נוסף זמין במאמר Config: Parse Section במאמרי העזרה של Fluentd.
protocol_type <transport> מציינים את הפרוטוקול של syslog התעבורה, כלומר udp, ‏ tcp, או tls.
auto_typecast צריך להסיר את הפרמטר הזה כשמשתמשים בו בפלאגין json parse.

הדוגמה הבאה מציגה הגדרה של תוסף קלט בסוכן Logging מדור קודם:

<source>
    @type tail
    path /var/log/my-app.log
    format json
</source>

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

<source>
    @type tail
    path /var/log/my-app.log
    <parse>
      @type json
    </parse>
</source>

סריאליזציה של אובייקטים ב-Ruby Time

ב-Fluentd במעלה הזרם נדרש המרה מפורשת לאובייקטים גולמיים של Ruby‏ Time שמשמשים בתוך מסנני <record>, כמו record_transformer. בלי המרה מפורשת, האובייקטים האלה גורמים לשגיאת סריאליזציה קריטית במהלך ניקוי המאגר.

אם ההגדרה שלכם משתמשת ב-${time} עם enable_ruby true, אתם צריכים להמיר את האובייקט באופן מפורש לסוג פרימיטיבי, למספר שלם או למחרוזת.

הדוגמה הבאה מציגה הגדרה של תוסף מסנן בסוכן Logging מדור קודם:

<filter foo.bar>
  @type record_transformer
   enable_ruby true
  <record>
    raw_timestamp ${time}
  </record>
</filter>

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

<filter foo.bar>
  @type record_transformer
   enable_ruby true
  <record>
    raw_timestamp ${time.to_i}
  </record>
</filter>

הגדרות ברירת מחדל של העברה ודחיסה ב-gRPC

תוסף הפלט google_cloud מאפשר להגדיר אם להשתמש ב-gRPC במקום ב-REST/JSON כדי לתקשר עם Cloud Logging API.

כדי לשפר את הביצועים, מומלץ להפעיל את ההעברה של gRPC ולהגדיר את grpc_compression_algorithm gzip. השילוב הזה ממזער את התקורה של הרשת ואת צריכת ה-CPU, במיוחד כשמעבדים נפחים גדולים של יומנים.

כדי להטמיע את האופטימיזציות האלה, משתמשים בהגדרה הבאה:

<match **>
  @type google_cloud
  use_grpc true
  grpc_compression_algorithm gzip
</match>

בנוסף, מכיוון ש-gRPC מסתמך על סטרימינג של HTTP/2 ביציאה 443, צריך לוודא שתשתית הרשת מאפשרת תנועה של gRPC/HTTP/2. בסביבות שבהן השימוש ב-gRPC מוגבל, צריך להגדיר במפורש את use_grpc false כדי לחזור לתקשורת רגילה של HTTP/REST.

תבנית של ביטוי רגולרי ב-RabbitMQ

דפוסי הביטויים הרגולריים שבהם משתמש סוכן Logging מדור קודם לרישום ביומן של RabbitMQ, לרוב לא תואמים לפורמטים של הפלט בגרסאות מודרניות של RabbitMQ. הפערים האלה עלולים לגרום לעיבוד שגוי של היומנים או להשלכה שלהם בשקט במהלך תהליך האיסוף.

יומני RabbitMQ מודרניים כוללים חותמות זמן עם דיוק של אלפיות השנייה, כמו YYYY-MM-DD HH:MM:SS.L, וסמנים ספציפיים של חומרה ומזהי תהליך (PID) כמו [info] <0.213.0>, שהביטוי הרגולרי מדור קודם לא הצליח להתאים להם.

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

בדוגמה הבאה מוצגת ההגדרה של תוסף הקלט של RabbitMQ לסוכן Logging מדור קודם:

<source>
  @type tail
  path /var/log/rabbitmq/*.log
  pos_file /var/lib/google-fluentd/pos/rabbitmq.pos
  tag rabbitmq
  format multiline
  format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/
  format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(?<severity>\w+)\] (?<message>.*)/
  time_format %Y-%m-%d %H:%M:%S
</source>

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

<source>
  @type tail
  path /var/log/rabbitmq/*.log
  pos_file /var/log/fluentd/pos/rabbitmq.pos
  read_from_head true
  tag rabbitmq
  <parse>
    @type multiline
    format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}/
    format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) \[(?<severity>[^\]]+)\] <(?<pid>[^>]+)> (?m:(?<message>.*))$/
    time_format %Y-%m-%d %H:%M:%S.%L
  </parse>
</source>