מה עדיף להשתמש: סוכן Logging או ספריית לקוח?

במאמר הזה מוסבר איך להשתמש בספריות לקוח או בסוכן רישום ביומן כדי לשלוח יומנים של אפליקציות ל-Cloud Logging באופן פרוגרמטי. המידע הזה יעזור לכם להחליט אם כדאי לכם לעשות את זה. סוכני רישום ביומן שולחים נתונים שנכתבו לקובץ, כמו stdout או קובץ, כיומנים ל-Cloud Logging. שירותים כמו Google Kubernetes Engine, הסביבה הגמישה של App Engine ופונקציות Cloud Run, כוללים סוכן רישום ביומן משולב. ב-Compute Engine, אפשר להתקין את סוכן התפעול או את סוכן Cloud Logging מדור קודם. הסוכנים האלה אוספים יומנים ממיקומי קבצים ידועים או משירותי רישום ביומן כמו Windows Event Log,‏ journald או syslogd.

אם אתם לא יכולים להשתמש בספריית לקוח או בסוכן Logging, או אם אתם רוצים רק להתנסות, אתם יכולים לכתוב יומנים באמצעות הפקודה gcloud logging write או באמצעות שליחת פקודות HTTP לנקודת קצה ל-API של Cloud Logging‏ entries.write. ‫Cloud Logging API תומך בקריאות HTTP ו-gRPC. ‫סוכן תפעול ורוב ספריות הלקוח של Logging מבצעים קריאה ל-gRPC Logging API. ספריית הלקוח של סוכן הרישום ביומן מדור קודם ושפות מסוימות קוראות ל-API של REST Logging.

בחירת סוכן או ספריות לקוח

כשאתם מתלבטים בין שימוש בסוכן לבין שימוש בספריות הלקוח, כדאי לשקול את השאלות הבאות:

האם האפליקציה שלכם פועלת מחוץ ל- Google Cloud?

אם האפליקציה לא פועלת ב- Google Cloud, צריך למצוא דרך לשלוח יומנים אל Logging API. כדי לנתב יומנים ממערכות מקומיות ל-Logging, מומלץ להשתמש ב-Bindplane, שמבצע פריסה ומנהל את אוספי OpenTelemetry כדי לשלוח טלמטריה אל Google Cloud. מידע נוסף זמין במאמר מידע על Bindplane.

בעזרת Bindplane אפשר לאסוף נתוני טלמטריה ממגוון מקורות ולייצא את הנתונים האלה אל Cloud Monitoring ו-Cloud Logging.

אפשרות אחרת היא להעביר את היומנים ל-Logging ישירות מהאפליקציה באמצעות ספריות לקוח. בסביבות ארעיות, כמו מחשוב בלי שרת (serverless computing), צריך להשתמש בספריות לקוח כדי לבצע קריאות ישירות ל-Logging API.

האם השירות Google Cloud שמריץ את האפליקציה תומך
לכתוב תוכן stdout וstderr לפרויקט?

יש Google Cloud שירותים שמנוהלים באופן מלא, כך שלא צריך להשתמש בסוכנים כדי לשלוח יומנים לפרויקט Google Cloud . אתם יכולים להשתמש בכל מסגרת רישום מוכרת בשפה שתבחרו, כמו Go,‏ Node.js ו-Python, כדי לשלוח יומנים אל Logging במוצרים שבהם stdout ו-stderr נתמכים כברירת מחדל. יתרון בשימוש ב-stdout וב-stderr במקום בספריות לקוח הוא שקריסות של האפליקציה לא יפסיקו את שליחת היומנים לפרויקט. מידע על שליחת יומנים מובנים דרך stdout ו-stderr מופיע בקטע האם האפליקציה שלך גמישה מספיק כדי לשנות את פורמט היומן?.

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

האם צריך שתהיה גישה ליומני האפליקציה בסביבה המקומית?

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

כשמריצים את האפליקציה ב Google Cloud שירותים שלא תומכים בשליחה אוטומטית של יומנים שנכתבו אל stdout ו- לפרויקטGoogle Cloud , אפשר לאסוף יומנים של stdout ו- בקבצים בדיסק ולהגדיר את הסוכן כך שיגרד אותם וישלח אותם אל Logging.stderrstderr למידע נוסף, אפשר לעיין במדריך ההגדרה של סוכן תפעול או של סוכן Logging.

האם תהליך ההתקנה של הסוכן הוא ידני או אוטומטי?

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

האם אתם כבר מריצים את Fluentd במערכת שלכם?

סוכן ה-Logging מדור קודם מבוסס על Fluentd.

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

האם אתם אוספים גם מדדי אפליקציות ל-Cloud Monitoring?

במכונות וירטואליות ב-Compute Engine, סוכן התפעול יכול לאסוף יומנים ורוב המדדים. מידע נוסף זמין במאמר בנושא תכונות של סוכן תפעול.

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

האם האפליקציה שלך מאפשרת לשנות את פורמט היומן?

השאלה הזו עוזרת לכם להחליט אם האפליקציה יכולה ליצור יומני רישום מובנים. מערכת Logging מזהה יומנים מובנים אם שולחים את היומנים ל-Logging API בפורמט של יומנים מובנים. ספריות הלקוח מספקות את השיטות לטיפול בפורמט הזה.

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

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

סיכום של כל אפשרות

דיאגרמה של דפוסי רישום ביומן

  • ספריות הלקוח של Cloud Logging

    • יתרונות

      • אפשר להעביר יומנים ישירות אל Cloud Logging API.
      • בשפות מסוימות אפשר להפיק יומני רישום ל-stdout ול-stderr באמצעות הספרייה.

    • חסרונות

      • קריסות של אפליקציות מונעות את שליחת היומנים ל Google Cloud פרויקט.

  • סוכן תפעול

    • יתרונות

      • סוכן התפעול יכול לשלוח יומנים ומדדים באמצעות טכנולוגיות יציבות בקוד פתוח: Fluent Bit לאיסוף יומנים ו-OpenTelemetry Collector לאיסוף מדדים.
      • אתם יכולים לאסוף גם יומנים וגם מדדים מאפליקציות נפוצות רבות. מידע נוסף זמין במאמר בנושא מעקב אחר יומנים ואיסוף יומנים מאפליקציות של צד שלישי.
      • אתם יכולים לשמור יומנים בסביבה המקומית שלכם.
      • יכול להיות שתוכלו לשחזר יומנים מקריסות של אפליקציות.
      • סוכן התפעול נמצא בפיתוח פעיל.

    • חסרונות

      • ‫Fluent Bit תומך רק בקידוד UTF-8. הוא לא תומך בהמרת קידוד.

  • סוכן Logging מדור קודם

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

  • יומנים של stdout ושל stderr נשלחים אוטומטית אל Google Cloud הפרויקט

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