ניטור Serverless: היכן נשברת הנצפות
ניטור Serverless נשבר לא במקום שבו מחפשים אותו בדרך כלל. הפונקציה רצה, החזירה תשובה, ובלוגים — ריק או קטע ללא מזהה בקשה. התקלה מתגלה כעבור שעה, כשמשתמשים כבר כותבים לתמיכה, והמהנדס התורן הולך בשרשרת מהתור, דרך השער, הפונקציה והשירות החיצוני, בלי שום עקבה מקצה לקצה.
שורש הבעיה טמון בטבעה של המודל חסר השרת. כל קריאה חיה בסביבה מבודדת נפרדת, שהפלטפורמה יוצרת ומשמידה לפי שיקול דעתה.
הנצפות של פונקציות חסרות שרת נקרעת בשלושה חיבורים: הקשר הבקשה אינו שורד את הגבול בין הפונקציות, אוסף הלוגים מתחיל לפעול רק לאחר שהשורות הראשונות כבר אבדו, וההפעלה הקרה מוסיפה לזמן התגובה מקטע שלא מוצג בשום מקום כשלב נפרד.
מכאן פועל אפקט ההצטברות. אובדן הקשר בפונקציה אחת הופך את מעקב הבקשות לאוסף אירועים לא קשורים: רואים שהקריאה הייתה, אבל לא רואים עם אילו פרמטרים היא הגיעה ומה החזירה.
כשפונקציות כאלה יש עשרות, שחזור תמונת התקלה אורך שעות של הצלבה ידנית לפי זמן וסימנים עקיפים — ובינתיים הסיבה לכשל כבר אינה משוחזרת.
המחיר של אזור עיוור כזה אינו רק זמן השבתה. בלי תמונה מקצה לקצה הצוות אינו יכול להבחין בין דעיכה של שירות חיצוני לבין מיצוי הרצות מקבילות, ולכן מתקן את הסימפטום במקום את הסיבה וזוכה בכשל חוזר כעבור שבוע.
בהמשך נפרט כיצד זה נסגר: היכן בדיוק להציב איסוף מדדים וטראסות, כך שכל בקשה תישאר ניתנת למעקב מהכניסה ועד הקריאה האחרונה.
מה נותן ניטור serverless: אפקט במספרים
ניטור serverless מתחיל משלושה זרמי טלמטריה בלתי תלויים: איסוף מדדי פונקציות (התחלות קרות, משך, שגיאות, מקביליות), תחקור מבוזר של בקשה מקצה לקצה דרך השער, התור והפונקציה, ותיעוד קריאות עם קורלציה לפי מזהה בקשה. כל עוד זרמים אלה חיים בנפרד, איתור התקלה הופך לסריקה ידנית של לוגים.
מדדים, תחקור ולוגים כמעגל единый
איסוף מדדי פונקציות נותן אות ראשוני: עלייה בשיעור ההתחלות הקרות ובמשך על מטפל מסוים נראית לפני שהשגיאות מתחילות. תחקור מבוזר מקשר קריאות למסלול אחד, ולכן ניתן לראות באיזה קטע בשרשרת הבקשה מאבדת זמן.
תיעוד קריאות עם מזהה משותף מבטל את הסריקה: המהנדס פותח trace אחד ורואה את הסיבה, במקום לאסוף אותה מרשומות מפוזרות.
התראות סף במקום "מנטרים הכל"
התראות סף מוגדרות על גדלים בעלי משמעות הנדסית: שיעור שגיאות למטפל, משך מעל קו הבסיס, זינוק בהרצות מקבילות, מיצוי מגבלת קריאות בו-זמניות. סף שנקבע נכון מקצר את זמן השחזור: התורן מקבל אות עם הקשר, ולא זרם רעש, ואינו מבזבז את הדקות הראשונות על בירור מה בכלל נפל.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אמצעים מובנים של הענן | התחלה מהירה, טלמטריה בסיסית ללא סוכנים | קורלציה חלשה בין שירותים, אחסון מוגבל |
| סטאק עצמאי על כלים בקוד פתוח | נדרש שליטה מלאה בנתונים ובאחסון | דורש תחזוקה והגדרת מאגר נתונים |
| פלטפורמת observability חיצונית | תחקור מקצה לקצה והתראות out of the box | תלות בשירות חיצוני, נפח הנתונים משפיע על האחסון |
מה זה נותן בגדלים מדידים
לאחר מעגל מקצה לקצה, שיעור הקריאות המכוסות בתחקור מגיע לכיסוי מלא של מסלולים קריטיים, וזמן איתור התקלה מתקצר משעות לדקות — המהנדס רואה קטע ספציפי בשרשרת.
נעלם סוג התקלות שאותרו בעבר רק לפי תלונות: דעיכה שקטה של מטפל, עלייה בהתחלות קרות לאחר שינוי תצורה, שגיאות בגבול בין התור לפונקציה.
Datadog ופלטפורמות דומות סוגרות תחקור והתראות out of the box, אך הבחירה בין אמצעים מובנים, סטאק עצמאי ופלטפורמה חיצונית תלויה בכמה מסלולים קריטיים וכמה זמן יש לשמור נתונים.
כיצד אנו מיישמים ניטור: שלבי העבודה
יישום ניטור serverless מתחיל לא בהתקנת סוכנים, אלא בביקורת של מה שכבר נאסף: אילו פונקציות ותורים קיימים, אילו מדדים מספקים שירותי הענן, והיכן Telemetry הולך לאיבוד בין קריאות. ללא שלב זה, לוחות הבקרה הופכים לאוסף גרפים שלא ניתן לאתר לפיהם תקלה. לאחר מכן אנו בונים את המסלול כך שכל שלב יניב תוצאה ניתנת לבדיקה, ולא "הגדרנו ומקווים".
- ביקורת Telemetry. אנו עורכים מלאי של פונקציות, טריגרים, תורים ותלויות חיצוניות, ובודקים אילו מדדים ולוגים כבר נכתבים ואילו נתיבי הרצה נשארים "כהים". התוצר — מפת כיסוי: היכן כל קריאה נראית והיכן לא.
- סכמת איסוף נתונים. אנו מתכננים כיצד Tracing מקשר קריאות לבקשה אחת, כיצד מועבר הקונטקסט בין פונקציות ותורים, היכן נשמרים הלוגים ובאיזה עומק. בנפרד אנו מחליטים מה לדגום כדי לא לשלם על אחסון כל הזרימה.
- הגדרת התראות. אנו מצמידים חוקים לסימפטומים ולא לכל מדד: עלייה בשיעור השגיאות, זינוק בהשהיה, הצטברות בתור, מיצוי הרצות מקבילות. אנו מגדירים ספים וחלונות כך שהתורן יקבל אות על דעיכה אמיתית ולא רעש.
- בדיקה באמצעות תקלות. אנו שוברים את המערכת בכוונה — מנתקים תלות, מכניסים השהיה, מפילים פונקציה — ובודקים אם ההתראה הופעלה והאם יש מספיק נתונים לזיהוי הסיבה. חוקים שלא תפסו את התקלה — אנו כותבים מחדש.
- מסירת תיעוד. אנו מוסרים לוחות בקרה מוגדרים, חוקי התראה, סכמת איסוף והוראות לטיפול בתקריות, כדי שהצוות יוכל לעבוד עם המערכת בלעדינו.
מסלול כזה מניב תוצאה צפויה: עד למסירה יש לכם כיסוי קריאות ב-Tracing, התראות שנבדקו על כשלים אמיתיים, ותיעוד שלפיו מהנדס חדש יטפל בתקרית ללא רמזים בעל פה. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי שלבים.
במה שונה ניטור פונקציות מניטור שרתים?
ניטור שרתים קלאסי נשען על רציפות: סוכן חי על המארח, אוסף עומס מעבד, זיכרון, דיסק ורשת, והתורן מביט בגרף לאורך היממה. בסביבה נטולת שרתים אין רציפות זו. מופע של פונקציה עולה עבור קריאה מסוימת, פועל ומושמד — לעתים קרובות בתוך שבריר שנייה.
מדדי פונקציות נאספים לא מהמכונה, אלא מזרם האירועים: כמה קריאות, מה משך הזמן, כמה שגיאות, כמה התנעות "קרות". מדדי שרתים רגילים כאן או שאינם קיימים, או שמטעים.
מופעים ארעיים שוברים את עצם הרעיון של "מצב המארח". לפונקציה אין תהליך ארוך-טווח שאפשר להתחבר אליו, אין כתובת יציבה, אין סטטיסטיקה מצטברת בין קריאות. במקום זאת, כל יחידת עבודה היא הקשר קריאה נפרד עם מזהה משלו, זמן התחלה וסיום.
הניטור נבנה סביב גבולות הבקשה: מכניסת האירוע ועד רישום התגובה, כולל כל הפניות למסד הנתונים, לתורים ולשירותים חיצוניים בתוך חלון זה.
מכאן ההבדל העיקרי: ניטור שרתים עונה על השאלה "האם המארח בריא", בעוד ניטור serverless — "האם נתיב עיבוד מסוים בריא". אותו קוד יכול לפעול כשורה ב-99% מהקריאות ולהיכשל בתרחיש נדיר עם גוף בקשה גדול או פסק זמן של שירות חיצוני. בלי קישור המדד להקשר הקריאה, כשל כזה אינו נראה: גרפים ממוצעים מטשטשים אותו.
מבחינה מעשית משמעות הדבר שלושה דברים. יש לחתוך את מדדי הפונקציות לפי ממדים: שם הפונקציה, גרסה, מקור האירוע, קוד התגובה. יש לספור שגיאות והשהיות בגבולות הבקשה, ולא לפי המארח. והעקיבה חייבת לקשר קריאה אחת עם כל הפעולות הפנימיות שלה, אחרת לא ברור היכן בדיוק הולך לאיבוד הזמן. מערך כזה נותן את מה שניטור שרתים אינו נותן: תשובה לשאלה איזה תרחיש בדיוק הידרדר ובאיזה שלב.
מקרה בוחן: קיצרנו פי שלושה את זמן איתור סיבת התקלה
שירות ללא שרת (serverless) המבוסס על עשרות פונקציות: כל בקשה עוברת דרך שער API, תור, כמה מטפלים וכתיבה למסד נתונים.
כאשר השגיאות בתצוגה הלכו וגדלו, המהנדסים פתחו את הלוגים של כל רכיב בנפרד ותפרו ידנית את השרשרת לפי מזהה הבקשה — איתור הסיבה ארך בממוצע כשעתיים, וחלק מהתקריות נסגרו "לפי סימפטומים", מבלי להגיע לשורש.
מה היה לפני ההטמעה
הלוגים והמדדים חיו במקומות שונים: שגיאות של פונקציות — בשירות אחד, השהיות של השער — בשני, מצב התורים — בשלישי. התורן ראה זינוק בכשלים, אך לא יכול היה להבין במעבר אחד היכן בדיוק נשברת השרשרת. ניתוח התקלה הפך להתכתבות בין צוותים, ולא לניתוח.
מה שינו
הפעלנו tracing מקצה לקצה: מזהה אחד כעת מקשר את הבקשה לכל אורך הדרך — מקריאת הקלט ועד הכתיבה האחרונה. הרכבנו פאנלים אחידים, שבהם על מסך אחד נראים שיעור השגיאות, ההשהיות בכל חוליה ועומק התורים.
הגדרנו התראות לפי סימפטומים שבאמת חשובים: עלייה בשיעור הכשלים וחריגה מסף זמן התגובה, ולא כל לוג בודד.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| זמן איתור התקלה | ~שעתיים | ~40 דקות |
| שיעור התקריות עם שורש מאותר | חלק | כמעט כולן |
| מעברים בין כלים בזמן הניתוח | 3-4 | 1 |
זמן איתור הסיבה הצטמצם פי שלושה, וניתוח התקלה הפסיק להיות תלוי במי בדיוק נמצא במשמרת. לשם כך השתמשנו ב-Datadog כנקודת איסוף אחידה של tracings, מדדים ולוגים של פונקציות ללא שרת.
מה אם השירות כבר מכוסה חלקית על ידי ניטור? ניתן להפעיל tracing מקצה לקצה בהדרגה, החל מנתיבים קריטיים — שאר הרכיבים מתחברים ללא עצירת העבודה. מה אם מספר הפונקציות יגדל? הסכמה עם מזהה בקשה אחיד מתרחבת יחד עם השירות: מטפלים חדשים קולטים את ה-tracing באופן אוטומטי.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית: נראה כיצד ייראו פאנל אחיד ו-tracing מקצה לקצה בדיוק בשירות שלכם.
תאימות, הרשאות גישה וחזרה לאחור: מה נדון לפני ההתחלה
לפני ההתחלה עולים בדרך כלל שלושה שאלות: האם הניטור ישבור את התהליכים הקיימים, אילו הרשאות גישה יידרשו וכיצד לחזור לאחור אם משהו ישתבש. אנו עונים לפי הסדר — וזה בדיוק תוכן פגישת ההקמה.
מה אם כבר יש לנו איסוף לוגים והתראות מוגדרים? הניטור משתלב מעל הסטאק הקיים, ולא מחליף אותו. טרייסים ומטריקות מקושרים לדאשבורדים ולערוצי ההתראות הנוכחיים, וכללי כפילות מושבתים לאחר בדיקה שהחדשים מכסים את אותם תרחישים. האינטגרציה עם הסטאק הקיים נבדקת על שירות אחד לפני פריסה על השאר.
אילו הרשאות גישה לענן נדרשות? תפקיד לקריאה בלבד של מטריקות ולוגים, חשבון נפרד לאיסוף טלמטריה, ללא הרשאות לשינוי משאבי פרודקשן. מדיניות הגישה מתוארת באופן מפורש: מה קוראים, מה כותבים, היכן הגבולות. כל המפתחות — באחסון מאובטח, עם רוטציה ויומן שימוש.
מה אם הניטור יתחיל להאט את האפליקציה? האיסוף מתבצע באופן אסינכרוני, מחוץ לתהליך הראשי של עיבוד הבקשות. אם עלויות התקורה עולות על הסף המוסכם, אנו משביתים את האיסוף בשירות הבעייתי בהגדרה אחת, מבלי לגעת בשאר.
כיצד נראית תוכנית החזרה לאחור? כל שינוי — בשלב נפרד עם נקודת שחזור: שמרו את הקונפיגורציה, הפעילו, בדקו מטריקות, ובמקרה של סטייה החזירו את המצב הקודם. החזרה לאחור אורכת דקות ואינה דורשת בנייה מחדש של האפליקציה.
מה נקבל לידיים לאחר המסירה?
קונפיגורציית איסוף טלמטריה מוגדרת, תרשימי זרימת נתונים, מדיניות גישה עם תיאור תפקידים, דאשבורדים וכללי התראות, תקנון תורנות והוראות חזרה לאחור. בנוסף העברת ידע לצוות — כדי שמכאן והלאה תוכלו לשנות כללים בעצמכם.
מה הלקוח מקבל לידיים:
- קונפיגורציות לאיסוף מטריקות, לוגים וטרייסים עם הערות לפרמטרים
- תרשים זרימת נתונים: מהשירות ועד הדאשבורד וערוץ ההתראות
- מדיניות גישה עם הפרדת תפקידים וגבולות הרשאות
- סט דאשבורדים וכללי אלרטינג לתרחישי המפתח
- תקנון תורנות והוראות לתוכנית החזרה לאחור
- תיעוד האינטגרציה עם הסטאק הקיים
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית: אילו הרשאות גישה יידרשו, מה ייכלל בשלב הראשון וכיצד תיבנה החזרה לאחור.
