הגדרת ניטור תשתיות באמצעות Datadog

כשל מתגלה דרך שיחות מלקוחות, לא דרך מדדים — כך הולכים לאיבוד שעות ומוניטין. אנו מגדירים ניטור Datadog כפתרון מלא: מחברים מקורות טלמטריה, מגדירים התראות ולוחות לפי התרחישים שלכם. הצוות רואה את מצב השירותים בחלון אחד, וזמן איתור הכשלים מתקצר פי כמה.

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

ניטור Datadog: היכן התשתית מאבדת נצפות

תשתית פרוסה לעיתים נדירות היא "אילמת" כולה: מדדים מחלק מהצמתים זורמים, לוחות נבנים, התראות מגיעות. הבעיה אחרת — הכיסוי אינו אחיד, וניטור התשתית של Datadog מציג רק את המעגל שאליו הגיעו הסוכנים.

מחוצה לו נשארים שירותים שהועלו מחוץ לתבנית אחודה: קונטיינרים ללא תגיות שירות וסביבה, תורים שמשמשת בהם צוות אחד, תלות חיצוניות ללא בדיקות זמינות פעילות.

האזור העיוור השני של הנצפות — לוגים מפוזרים. חלק מהשירותים כותבים לזרם הסטנדרטי, חלק לקבצים בתוך הקונטיינר, חלק נשלחים לאוסף משלהם. חסרה תגית משותפת, ולכן אי אפשר לקשר רשומה לבקשה מסוימת או לגרסת מהדורה, וחיפוש סיבת התקלה הופך למעבר ידני בין כמה מאגרים במקום סינון אחד.

צוואר הבקבוק השלישי — ספי התראות. כלל שנבנה על ערך ממוצע בחלון ארוך מחליק את הפיק: גילוי מאוחר של תקלות הופך לנורמה, והתורכן לומד על הבעיה מפניות לתמיכה, לא מהמערכת. ההתראה מגיעה בדיעבד, כשהמשתמשים כבר הבחינו בהידרדרות.

מחיר התצורה הזו נמדד לא בנפח הטלמטריה, אלא בזמן מהתקלה הראשונה ועד אימותה. צוואר הבקבוק של איסוף הטלמטריה אינו רוחב פס, אלא עקביות: כללי שמות אחידים, תיוג מקצה לקצה של בקשות, ספים שנקשרים למסלול המשתמש ולא לצומת בודד. בהמשך נפרט איך זה נסגר — ממיפוי מקורות ועד לכללים שמופעלים לפני פניות.

מה נותנת נצפות מנוהלת: אפקט במדדים מדידים

ניטור נחשב מוצלח לא לפי מספר הלוחות, אלא לפי ארבעה גדלים: זמן גילוי התקלה, זמן מיקום, זמן שחזור השירות ומשך ההשבתה. לפני ההטמעה המשתמש בדרך כלל מגלה את התקלה, והתורכן לומד עליה מצ'אט התמיכה.

אחרי — סטייה מפרופיל המדד הרגיל מעלה התראה תוך שניות, והשאלה כבר אינה "עובד או נפל", אלא "השירות מגיב לאט מהרגיל בקטע מסוים במסלול הבקשה".

תמונה אחודה של מצב השירותים מסירה את השלב היקר ביותר — חיפוש האשם. ב-Datadog מדדים, לוגים וטראסים מקושרים בתגיות משותפות, ולכן מגרף ההידרדרות עוברים לבקשה, לצומת או למהדורה מסוימת בלי השוואה ידנית לפי זמן. המיקום מתקצר משעות של תיאום בין צוותים לדקות בתוך לוח אחד.

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

תוצאה נפרדת — מחיקה של סוג תקלות חוזרות. התראה שאי אפשר לסגור בלי לציין סיבה, וניתוח לאחר אירוע הופכים כל תקלה לתיקון בתצורה או לבדיקה בשלב השחרור. כעבור כמה שבועות שיעור ההתראות השווא יורד, וחלק מהתקלות כלל לא מגיע למשתמש.

דרכי איסוף טלמטריה: סוכנים, אינטגרציות וייצואנים חיצוניים

בחירת דרך האיסוף אינה "או/או": סוכן על הצומת, אינטגרציה עם שירות ענן ואוסף משלנו מכסים שכבות שונות של אותה מערכת. אם למשוך הכול דרך ערוץ אחד, המדדים של שירותים מנוהלים כלל לא יגיעו, והסוכן על המארח יהפוך לצוואר בקבוק בעומס. לכן כמעט תמיד משלבים בין המצבים.

Datadog מקבל טלמטריה בכל שלושת הערוצים בו-זמנית, כך שהשאלה אינה תאימות, אלא איזה מצב נותן את הפירוט הדרוש בעלות תחזוקה סבירה. החלוקה בדרך כלל כזו: הסוכן אחראי למשאבי הצומת, האינטגרציה — לשירותים מנוהלים, והאוסף העצמי — למוני אפליקציה ולמעגלים סגורים.

אפשרות מתי מתאימה מגבלות
סוכן על הצומת מכונות וירטואליות, פלטפורמות קונטיינרים, כל מה שיש בו גישה למערכת ההפעלה נדרשים הרשאות ועדכון בכל צומת; בסביבה ללא שרתים אינו ישים
אינטגרציה עם שירות ענן מסדי נתונים מנוהלים, תורים, מאזני עומס — המדדים נאספים דרך ה-API של הספק השהיית ייצוא, חלק מהמונים הפנימיים אינם זמינים, נדרשות הרשאות קריאה
אוסף נתונים עצמי אפליקציות עם מונים לא סטנדרטיים, מעגלים מבודדים, פורמטים משלהן למדדים תחזוקה בצד שלנו, צריך לעקוב בעצמנו אחר כפילויות ותיוג

לפני החיבור מקבעים סכימת תגיות אחידה וכללי שמות — אחרת מדדים מערוצים שונים לא יתאחדו ללוח מחוונים אחד. בהמשך בודקים שכל מקור מוסר נתונים באופן צפוי, ורק אז מרחיבים את הכיסוי.

סדר הטמעת ניטור Datadog: מביקורת ועד מסירה

הטמעת Datadog מתבצעת בשלבים, וכל שלב מסתיים בארטיפקט שניתן לבדוק. הסדר עקרוני: תחילה להבין מה המערכת כבר מוסרת, ורק אחר כך להפעיל איסוף — אחרת הסוכנים מותקנים בלי כיוון, וכללי ההתראות מתחילים להרעיש על ספים לא ברורים.

  1. ביקורת נצפות. עורכים מיפוי של שירותים, סביבות ואילו מדדים, לוגים וטראסים הם כבר מוסרים. התוצאה — מפת פערים: היכן אין נתונים והיכן יש אבל איש לא קורא אותם.
  2. סכימת איסוף נתונים. בוחרים דרך אספקה: סוכן על המארחים, קליטת טלמטריה מאפליקציות, אינטגרציות עם ענן ומאזני עומס. מקבעים תגיות וכללי שמות, אחרת מדדים של צוותים שונים לא מתאחדים בלוח אחד.
  3. לוחות ורמות יעד. אוספים תצוגות לפי שירותים: השהיה, שיעור שגיאות, רוויה של משאבים, זמינות. רמות יעד מגדירים ממה שחשוב למשתמש, לא מנוחות המדדים הקיימים.
  4. הגדרת כללי התראות. אותות מקשרים לסימפטומים אצל המשתמש, לא לכל מדד. מגדירים קיבוץ, חלונות ודיכוי חזרות, כדי שהתורכן יקבל אות אחד לאירוע.
  5. בדיקת תרחישי כשל. שוברים במתכוון את הסביבה: מכבים צומת, מוסיפים השהיה, מפילים תלות. בודקים אם האות הופעל, אם הגיע לתורכן ואם היו מספיק נתונים לאבחון.
  6. מסירת תפעול. מוסרים נהלי תורנות, הוראות לאירועים טיפוסיים והרשאות. עורכים ניתוח עם הצוות — אחריו הניטור חי ומתפתח בלעדינו.

מה נשאר בתשתית: לוחות, התראות, נהלים

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

  • תצורות איסוף: סוכן על צמתים ושירותים, אינטגרציות עם מסדי נתונים ותורים, כללי תיוג — המדדים נאספים למודל אחיד, לא לקבוצות מפוזרות.
  • לוחות גרפים ב-Datadog: לוח סקירה לפי שירות ולוחות נפרדים לפי צמתים — זמן תגובה, שיעור שגיאות, רוויה של משאבים, מצב משימות רקע.
  • כללי התראות: ספים וחלונות מיצוע, הפרדה בין "מעיר בלילה" ל"מטפלים בשעות העבודה", דיכוי כפילויות בתקלה המונית.
  • מדיניות גישה: תפקידים וקבוצות, מי משנה כללים ולוחות, מי רק צופה, יומן שינויים ותקופת שמירת נתונים.
  • נהלי תורנות: לוח זמנים, סדר הסלמה, זמני תגובה לסוגי התראות שונים ונקודות שבהן מצטרף הפיתוח.
  • סט תיעוד: סכימת איסוף, מה במכוון לא מנטרים ולמה, נימוק הספים, סדר חיבור שירות חדש.
  • סדר שינויים: היכן נשמרות התצורות, איך מתקנים כללים ואיך חוזרים לגרסה קודמת אם החדשה מרעישה.

כל סעיף נבדק בקבלה: מפעילים התראת תרגול, מסירים צומת מאיזון עומסים ובודקים אם המסלול הנדרש הופעל. הרשימה סגורה כשהצוות שלכם עצמו מבצע תיקון בכלל ורואה תוצאה בלי עזרתנו.

מקרה בוחן: איך קיצרנו את זמן גילוי התקלות

איך זה היה לפני

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

הזמן עד הגילוי נע בין 25–40 דקות, ובניתוח נתקלנו בדבר אחד: לא ברור באיזה רגע המדד השתנה ומה השתנה לפני כן.

מה עשינו

התחלנו ממיפוי — איחדנו שירותים, מארחים ותלויות לקטלוג אחיד ועל בסיסו פרסנו איסוף מדדים, לוגים וטראסים ב-Datadog. אחר כך ויתרנו על סף אחד להכול: קישרנו כללים לזמינות ולהשהיה של שירות מסוים, ובדיקות רועשות שהופעלו לעתים קרובות יותר מאשר אירועים שוכתבו או כובו. לכל אות הוספנו בעלים, קישור לגרפים וסדר פעולות לדקות הראשונות.

מה השתנה במספרים

הזמן עד הגילוי ירד מ-25–40 דקות ל-3–5: פיק של שגיאות והידרדרות בהשהיה נראים לפני שהלקוחות מבחינים בהם. שיעור התראות השווא ירד מכ-70% ל-12%, והערות לילה בגלל רעש כמעט פסקו.

בנפרד נסגר סוג תקלות שלא נתפס כלל קודם: הידרדרות הדרגתית תחת עומס בלי קריסת השירות — לפי שרשרת הקריאות רואים מיד איזו חוליה החלה להאט.

חלק מהזמן הושקע לא בלוחות מחוונים, אלא בתיוג שירותים ובעלים: בלעדיו כל מערכת נצפות הופכת למזבלה של גרפים.

מה לעשות אם המדדים כבר נשלחים למערכת אחרת?

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

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

הכפילות מבזבזת חלק מהמשאבים על שליחה, אבל מסירה את הסיכון המרכזי: ברגע המעבר אף לוח תצפית ואף כלל התראה לא נעלמים.

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

ההיסטוריה בגישה הזו לא מועברת פיזית — לארכיון של המערכת הישנה שומרים גישה לכל תקופת השמירה, והנתונים החדשים נכתבים כבר למעגל החדש. אפשר לוותר על הסכימה הקודמת כשאף לוח ואף התראה לא נקראים ממנה, הסוכנים מותקנים בכל המארחים, והשוואת הפערים עוברת באופן יציב. ליתר ביטחון משאירים בדרך כלל כמה חודשים, ואחר כך מכבים מקלטים מיותרים.

ספקות בנוגע להרשאות, נפח נתונים ולוחות זמנים

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

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

אילו הרשאות אתם מבקשים ואיך אתם מגבילים אותן?

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

כמה יגדל נפח הנתונים הנשמרים?

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

כמה זמן תופסת ההטמעה?

מעגל פיילוט מקימים בתוך ימים ספורים, כיסוי מלא תופס שבועות. עובדים בגלים: תחילה סוכנים ומדדים בסיסיים, אחר כך לוחות מחוונים והתראות — כל גל אפשר לעצור בלי לאבד את מה שכבר נאסף.

מה יידרש מהצוות שלנו?

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

נדון במשימה: מה צריך כדי להתחיל בעבודה

כדי לדון במשימה לגופו של עניין, אין צורך בגישה מלאה לסביבות הייצור ובמפרט טכני מוכן. מספיק לתאר מה כבר פרוס ואילו שאלות נצפות צריך לסגור — זה קובע את ארכיטקטורת איסוף המדדים, הלוגים והטראסים. להלן הסט המינימלי שאחריו נחזור עם הערכה ותוכנית עבודה.

  • רשימת שירותים וסביבות: מה אנחנו מנטרים כעת והיכן נשארים "אזורים עיוורים" — קונטיינרים, מכונות וירטואליות, מסדי נתונים, מאזני עומס, תורים.
  • סכימת המעגל: איך השירותים מתקשרים ביניהם ואילו תלויות חיצוניות קריטיות לזמינות.
  • דרך התקנת הסוכן ומגבלות הרשת: מקטעים סגורים, פרוקסי, חיבורים יוצאים — מזה תלויה אספקת הנתונים ל-Datadog.
  • הרשאות ותפקידים: מפתחות רק לקליטת נתונים, משתמש נפרד להגדרת לוחות וכללי התראה, מי מאשר שינויים מצד המזמין.
  • מקורות אותות נוכחיים: איך נאספים מדדים ולוגים, איך מאורגנות תורנויות, היכן מוגדרים ספי הפעלה.
  • תרחישים קריטיים: שירותים שהשבתה שלהם אסורה, וזמן תגובה מותר לתקלה — מזה אוספים ספים והסלמה.
  • נקודת קשר: מהנדס שמכיר את התשתית ומאשר הרשאות. איתו מתאמים את הרכב הצוות ואת מועד תחילת ההטמעה.

בהמשך — הערכה ותוכנית עבודה: שלבים, איזה מהמהנדסים שלנו מכסה מה, ומה יידרש מצדכם בכל שלב. אין תנאים מקדימים להתחלה: כתבו מה כבר נעשה ומה כואב — נחזור עם תוכנית.