יסודות ניטור ולוגים - איך יודעים שהמערכת בסדר לפני שהלקוחות מתלוננים¶
יש רגע מביך שקורה כמעט בכל צוות תוכנה בשלב כלשהו - לקוח מתקשר ומתלונן שהאתר לא עובד, והצוות מגלה שהוא נופל כבר עשרים דקות, ואף אחד לא ידע. הרגע הזה הוא בדיוק הסיבה שניטור ולוגים הם לא "פיצ'ר נחמד להוסיף בהמשך", אלא תשתית בסיסית שכל מערכת רצינית חייבת מהיום הראשון.
למה בכלל צריך את זה¶
אפליקציה שרצה בייצור היא לא כמו קוד שרץ על המחשב שלכם, שאתם רואים אותו עם העיניים בכל רגע. היא רצה על שרת רחוק, אולי בכמה עותקים, אולי בכמה אזורים בעולם, ומשרתת אלפי משתמשים בו זמנית. בלי כלים שמראים לכם מה קורה שם בפנים, אתם עיוורים. אתם לא יודעים אם המערכת איטית, אם היא זורקת שגיאות, אם יש לה מספיק זיכרון, או אם היא בכלל למעלה. ניטור ולוגים הם העיניים שלכם לתוך המערכת.
מטריקות מול לוגים - שני כלים שונים לתפקידים שונים¶
יש בלבול נפוץ בין המושגים האלה, אז בואו נפריד אותם.
מטריקות (Metrics) הן מספרים שנמדדים לאורך זמן - כמה בקשות בשנייה מגיעות לשרת, כמה זיכרון הוא צורך, כמה זמן לוקח לענות על בקשה, אחוז השגיאות. המטריקות מצוינות לראות תמונת מצב כללית ולזהות מגמות - למשל, לראות שהשימוש בזיכרון עולה בהדרגה כל שבוע, מה שמרמז על דליפת זיכרון (memory leak) לפני שהיא בכלל גורמת לקריסה.
לוגים (Logs) הם רשומות טקסט מפורטות של אירועים ספציפיים שקרו במערכת - "משתמש X התחבר בשעה כזאת", "שגיאה בעיבוד בקשה Y, הסיבה היא כך וכך". לוגים מצוינים כשצריך לחקור בעיה ספציפית ולהבין בדיוק מה קרה, שלב אחר שלב.
ההבדל הפשוט: מטריקות אומרות לכם שיש בעיה. לוגים עוזרים לכם להבין מה בדיוק הבעיה ולמה היא קרתה.
איך זה נראה בפועל¶
תארו לעצמכם שמטריקות מראות לכם שאחוז השגיאות בשירות מסוים קפץ פתאום מ-1 אחוז ל-15 אחוז. זה הדגל האדום הראשון - משהו נשבר. אבל המטריקה עצמה לא אומרת לכם למה. אז אתם פונים ללוגים של אותה תקופת זמן, מסננים לפי השגיאות, ומוצאים שהן כולן קשורות לחיבור שנכשל למסד נתונים מסוים. עכשיו אתם יודעים בדיוק איפה לחפש את הבעיה.
מערכות מוצלחות לרוב משלבות גם רכיב שלישי - התראות (Alerts), שמודיעות לצוות ברגע שמטריקה חוצה סף מסוכן, לפני שמישהו בכלל צריך להסתכל על דשבורד. זה ההבדל בין לגלות שהמערכת נפלה מלקוח כועס, לבין לקבל התראה בטלפון ולתקן את זה לפני שמישהו בכלל שם לב.
הכלים המרכזיים בתחום¶
כמה שמות שכדאי להכיר, כי תפגשו אותם כמעט בכל מקום שתעבדו בו:
- Prometheus - כלי פופולרי לאיסוף מטריקות, בעיקר בעולם הקונטיינרים וKubernetes.
- Grafana - כלי להצגת דשבורדים חזותיים מהמטריקות שנאספו, כדי לראות תמונת מצב במבט אחד.
- Elastic Stack (ELK) - שילוב של כלים (Elasticsearch, Logstash, Kibana) שמתמחה באיסוף, חיפוש והצגת לוגים בכמויות גדולות.
- CloudWatch - כלי הניטור המובנה של AWS, שמגיע כברירת מחדל לרוב השירותים שלהם.
הטעות הכי נפוצה - להוסיף ניטור רק אחרי שכבר נשרפתם¶
הרבה צוותים, במיוחד בסטארטאפים בתחילת הדרך, דוחים ניטור ל"אחר כך, כשיהיה לנו זמן". הבעיה היא שברגע שקורה תקלה אמיתית בייצור, ואין שום ניטור, אתם מבזבזים שעות רק כדי להבין מה בכלל השתבש, בזמן שהמערכת ממשיכה להיות שבורה. עדיף בהרבה להשקיע כמה שעות בהתחלה בהקמת ניטור בסיסי, מאשר לגלות בדרך הקשה למה זה היה חשוב.
לא צריך התחלה מושלמת. אפילו לוגים בסיסיים ומטריקה אחת או שתיים חשובות (כמו זמינות ושיעור שגיאות) הם כבר צעד ענק קדימה לעומת כלום.
איך לומדים את זה בפועל¶
ניטור הוא בדיוק אחד מהתחומים שאי אפשר להבין באמת רק מקריאה - צריך לראות איך זה נראה כשמשהו נשבר, ואיך הדשבורד מספר לכם את הסיפור לפני שהלקוחות בכלל מתלוננים. בקורס צד-שרת שלנו יש פרק שלם על Elastic Stack, שמלמד אתכם להקים מערכת ניטור ולוגים אמיתית, לא רק להבין אותה ברמה התיאורטית.
קורס צד-שרת - בעברית, בחינם, עם תרגול מעשי בהקמת מערכות ניטור אמיתיות.
יש לכם מערכת שרצה בייצור בלי ניטור, ולא בטוחים מאיפה להתחיל? זה בדיוק סוג השאלה שכדאי לשאול בקהילה שלנו.
לסיכום¶
ניטור ולוגים הם העיניים שלכם לתוך מערכת שרצה הרחק מהמחשב שלכם. מטריקות מראות לכם שיש בעיה ומזהות מגמות מסוכנות מראש, לוגים עוזרים לכם להבין בדיוק מה קרה ולמה. מערכת שרצה בייצור בלי אף אחד מהם היא לא רק מסוכנת - היא עיוורת, וגלוי שאתם הולכים לגלות את הבעיות שלה בדרך הכי כואבת, מלקוחות כועסים ולא ממסך שמתריע מראש.