רישום לוגים נכון בבקאנד - רמות לוג ומה שווה לתעד¶
כל מפתח בקאנד כותב עשרות שורות לוג ביום, כמעט בלי לחשוב על זה - שורת log.info פה, שורת log.error שם. הבעיה היא שרוב המפתחים אף פעם לא למדו איך לעשות את זה נכון, והתוצאה היא לוגים שאף אחד לא באמת יכול להשתמש בהם כשקורה תקלה אמיתית באמצע הלילה.
רמות לוג ומתי להשתמש בכל אחת¶
לרוב ספריות הלוגים יש כמה רמות קבועות, ולכל אחת תפקיד ברור. רמת debug מיועדת לפרטים טכניים שמעניינים אתכם רק כשאתם ממש חוקרים בעיה - ערכי משתנים, זרימת קוד מפורטת. ברמת ייצור רגילה, רמה כזו בדרך כלל כבויה לגמרי, כי היא מייצרת רעש עצום. רמת info מתעדת אירועים תקינים וצפויים - "משתמש התחבר בהצלחה", "הזמנה נוצרה" - דברים שמעניינים אתכם כתמונת מצב כללית של מה שקורה במערכת. רמת warn מתריעה על משהו לא תקין אבל לא הרסני - קריאה לשירות חיצוני שלקחה יותר זמן מהצפוי, ניסיון גישה עם הרשאות חלקיות. ורמת error שמורה למקרים שבהם משהו באמת נכשל ודורש תשומת לב - בקשה שקרסה, כשל בחיבור למסד נתונים.
הכלל הפשוט הוא לשאול את עצמכם - אם השורה הזו תופיע הרבה מאוד פעמים ביום בייצור, האם עדיין אכפת לי לראות אותה? אם לא, היא כנראה ברמה נמוכה מדי או גבוהה מדי ביחס למה שבאמת קורה.
לוגים מובנים במקום טקסט חופשי¶
הרגל נפוץ אצל מפתחים הוא לכתוב שורת לוג כמו משפט חופשי - "המשתמש ביצע הזמנה בסכום מסוים". זה קריא לעין, אבל קשה מאוד לחפש ולסנן אותו בכלים אוטומטיים. הגישה הטובה יותר היא לוג מובנה, בפורמט כמו JSON, שבו כל פרט נשמר כשדה נפרד - מזהה משתמש, מזהה הזמנה, סכום. כשיש לכם המון שורות לוג ביום, לוג מובנה הוא מה שמאפשר לכם לשאול שאלה כמו "תראו לי את כל השגיאות של המשתמש הזה בשעה האחרונה" בלי לחפש טקסט באופן ידני.
מזהה מתאם שעוקב אחרי בקשה שלמה¶
בעיה נפוצה במיוחד היא לנסות לשחזר מה קרה במהלך בקשה אחת שעברה בכמה שכבות קוד, או אפילו כמה שירותים שונים. הפתרון הוא request ID, ערך ייחודי שנוצר ברגע שהבקשה מגיעה, ונשמר לאורך כל הטיפול בה - כל שורת לוג שקשורה לאותה בקשה כוללת את אותו מזהה. כשמשהו משתבש, מספיק לחפש את המזהה הזה בכל הלוגים, ומקבלים תמונה מלאה של כל מה שקרה, בסדר הנכון, גם אם זה עבר בין כמה שירותים.
מה אסור לרשום ללוג לעולם¶
יש כלל שאסור לשבור בשום מקרה - סיסמאות, טוקנים, מספרי כרטיסי אשראי מלאים, ומידע אישי רגיש אחר, אף פעם לא נכנסים לשורת לוג, גם לא ל"בדיקה מהירה" שהבטחתם לעצמכם למחוק אחר כך. לוגים נשמרים לאורך זמן, מועברים בין כלים, ולפעמים נגישים ליותר אנשים ממה שחשבתם. אם צריך לזהות משתמש בלוג, משתמשים במזהה פנימי, לא במידע האישי עצמו.
הבעיה של יותר מדי לוגים¶
זו נקודה שמפתחים רבים מפספסים - לוגר יותר מדי גרוע כמעט כמו לוגר פחות מדי. כשכל שורת קוד מייצרת עשר שורות לוג, השורה החשובה טובעת בים של רעש, ואף אחד לא באמת קורא את זה. כדאי לשאול לפני כל שורת לוג חדשה אם היא באמת עוזרת למישהו שמנסה להבין בעיה, או שהיא רק "נחמד לדעת".
בקורס צד שרת עובדים עם לוגים אמיתיים בפרויקטים מעשיים, ורואים בדיוק איך רמות לוג נכונות ומזהה מתאם הופכים חקירת תקלה מסיוט לתהליך של כמה דקות.
לסיכום¶
לוגים טובים הם לא עניין של לכתוב הרבה, אלא לכתוב נכון - הרמה המתאימה, פורמט מובנה שאפשר לחפש בו, מזהה שמחבר בין כל שורות אותה בקשה, ולעולם לא מידע רגיש. תשקיעו בזה מחשבה מראש, ותודו לעצמכם בפעם הבאה שמשהו נשבר באמצע הלילה.
יש לכם דוגמה ללוג שקשה לכם לפענח, או שאלה על איך לבנות מערכת לוגים בפרויקט שלכם? דברו איתנו בדיסקורד.