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

VictoriaMetrics בעומס שיא: היכן מטריקות הולכות לאיבוד

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

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

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

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

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

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

מה נותן מאגר מטריקות אחיד במקום מערכות מפוזרות

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

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

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

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

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

אפשרויות פריסה של VictoriaMetrics: השוואת מצבים

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

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

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

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

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

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

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

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

ארטיפקטים של הפרויקט: תצורות, סכימות, נהלים

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

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

החומרים נשארים בקו המתאר שלכם ובחשבונות שלכם, ומשמרת התורנות לומדת מהם — המסירה לא מסתיימת בכתב קבלה.

מקרה בוחן: מאגר מטריקות אחיד לארבעים שירותים

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

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

מטריקות לפני ואחרי

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

במה VictoriaMetrics שונה ממערכות ניטור קלאסיות

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

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

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

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

ספקות אופייניים: קרדינליות, אחסון, העברה

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

איך נשמרת ההיסטוריה ומה עם גיבוי?

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

אפשר להעביר היסטוריה בלי לאבד התראות?

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

נדון במשימה: הטמעת VictoriaMetrics בקו המתאר שלכם

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

מה לשלוח או לספר כדי שנדון במשימה באופן ענייני:

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

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