Observability מוסבר - לוגים, מטריקות וטרייסים¶
כתבתי כבר על Logging נכון בבקאנד ועל Health Check Endpoints - שני מרכיבים חשובים, אבל הם רק חלק מתמונה גדולה יותר שנקראת Observability. אם אתם עובדים במערכות production אמיתיות, ובמיוחד במיקרוסרביסים, זה מושג שכדאי להבין לעומק - לא רק כמונח באזז, אלא כדרך חשיבה שלמה על איך בונים מערכות שאפשר לתחזק אותן באמת.
מה ההבדל בין Monitoring ל-Observability¶
הרבה אנשים מתבלבלים בין שני המושגים, אבל ההבדל חשוב. Monitoring עונה על שאלות שאתם כבר יודעים לשאול מראש - "האם ה-CPU מעל 80%?", "האם השרת עונה?". זה מבוסס על דשבורדים והתראות שהוגדרו מראש, על סמך תרחישים שחזיתם.
Observability הולכת צעד אחד קדימה - היא נותנת לכם את היכולת לענות על שאלות שלא חשבתם עליהן מראש, כשמשהו מוזר קורה בפרודקשן. במקום "האם המערכת בריאה", השאלה הופכת ל"למה המערכת לא בריאה, ומה בדיוק קרה בשרשרת האירועים שהובילה לזה". זה ההבדל בין לדעת שמשהו נשבר לבין להבין באמת למה.
שלושת עמודי התווך של Observability¶
לוגים (Logs) - רשומות טקסטואליות של אירועים ספציפיים שקרו במערכת, ברמת פירוט משתנה. כתבתי כבר בהרחבה על איך בוחרים רמות לוג נכונות ומה שווה לתעד. לוגים הם הכי "גולמיים" מבין שלושת העמודים - הם נותנים את התמונה המפורטת ביותר, אבל גם הכי יקרים לאחסן ולחפש בהם בקנה מידה גדול.
מטריקות (Metrics) - מספרים שנמדדים לאורך זמן - זמן תגובה ממוצע, קצב שגיאות, מספר בקשות לשנייה, שימוש בזיכרון. בניגוד ללוגים, מטריקות הן קומפקטיות מאוד ויעילות לאחסון, ומצוינות לזיהוי מגמות ולהצגה בדשבורדים - אבל הן לא נותנות הקשר מפורט על מקרה בודד ספציפי.
טרייסים (Traces) - המושג הכי פחות מוכר מבין השלושה, וגם הכי חשוב במיקרוסרביסים. Trace עוקב אחרי בקשה בודדת של משתמש לאורך כל השירותים שהיא עוברת דרכם - מרגע שהיא נכנסת לשרת הראשון, דרך כל קריאה למיקרוסרביס נוסף, ועד התשובה הסופית. כל שלב כזה (span) מתועד עם משך הזמן שלו, ומאפשר לראות בדיוק היכן בשרשרת הארוכה נתקעה הבקשה או התרחשה השגיאה.
למה טרייסים קריטיים דווקא במיקרוסרביסים¶
בארכיטקטורת מונוליט, אם בקשה איטית, בדרך כלל אפשר להסתכל על לוג אחד ולהבין למה. אבל במיקרוסרביסים, בקשה בודדת של משתמש עשויה לעבור דרך עשרה שירותים שונים לפני שהיא מקבלת מענה - ואם היא איטית, איך יודעים איזה מתוך העשרה הוא האשם? בלי טרייסים, זה הופך לחיפוש מייגע בלוגים נפרדים של כל שירות, מנסים להתאים חותמות זמן ידנית. עם טרייסים, רואים ויזואלית בדיוק כמה זמן לקח כל שלב, ואיזה מהם היה צוואר הבקבוק - זו בדיוק הסיבה שכתבתי גם על ארכיטקטורת מיקרוסרביסים ועל האתגר של איך שירותים מוצאים אחד את השני ברשת, כי כל השכבות האלה ביחד יוצרות את המורכבות שobservability אמורה לפתור.
תקן OpenTelemetry - השפה המשותפת¶
עד לפני כמה שנים, כל ארגון בנה פתרון Observability מותאם אישית, עם ספריות שונות לכל שפת תכנות ולכל ספק ניטור. OpenTelemetry (בקיצור OTel) הוא פרויקט קוד פתוח שהפך לתקן דה-פקטו לאיסוף לוגים, מטריקות וטרייסים בצורה אחידה - בלי קשר לאיזו שפת תכנות אתם כותבים בה, ובלי להיות נעולים לספק ניטור ספציפי. זה משמעותי כי זה מאפשר לצוות לאמץ Observability הדרגתית, ולהחליף ספקי ניטור בעתיד בלי לשכתב את כל קוד המדידה מחדש.
איך זה נראה בפועל¶
צוות שמיישם Observability נכון בדרך כלל משלב את שלושת העמודים יחד: מטריקות בדשבורד נותנות התראה ראשונית ("זמן תגובה עלה פי 3 בעשר הדקות האחרונות"), טרייס ספציפי מראה איזה שירות בשרשרת הוא האשם, ולוגים מאותו שירות באותו חלון זמן נותנים את ההקשר המדויק - השגיאה המלאה, הפרמטרים שנשלחו, ומה בדיוק נכשל. שילוב כזה הופך תחקור תקלה ממשימה שיכולה לקחת שעות למשהו שנפתר תוך דקות.
תכירו את קורס פיתוח צד שרת שלנו כאן
לסיכום¶
Observability היא לא "עוד כלי ניטור" - היא דרך חשיבה שמכינה מערכת מראש לשאלות שעוד לא נשאלו, דרך שילוב של לוגים, מטריקות וטרייסים. ככל שהארכיטקטורה מורכבת יותר, במיוחד במיקרוסרביסים, כך היכולת הזאת הופכת מ"נחמד שיהיה" ל"הכרחי לשרוד" - בלי טרייסים, תקלה במערכת מבוזרת יכולה להפוך לחיפוש מחט בערימת שחת של לוגים נפרדים.
אם אתם רוצים לדבר על זה עם אנשים אחרים מעולם ה-DevOps, יש לנו קהילה שלמה בדיסקורד.