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

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

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

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

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

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

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

אפשרות אחרת היא להעביר את היומנים ל-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 ושל stderr אל פרויקטGoogle Cloud , אפשר לאסוף יומנים של stdout ושל stderr בקבצים בדיסק ולהגדיר את הסוכן כך שיגרד אותם וישלח אותם אל Logging. מידע נוסף זמין במדריך ההגדרה של סוכן תפעול.

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

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

האם Fluentd כבר פועל במערכת שלכם?

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

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

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

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

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

התשובה לשאלה הזו עוזרת לכם להחליט אם האפליקציה יכולה ליצור יומנים מובנים. מערכת 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. הוא לא תומך בהמרת קידוד.

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

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