ניהול InfluxDB עבור מדדים ו-IoT

ניהול InfluxDB: היכן נשבר איסוף המדדים

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

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

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

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

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

כתיבה יציבה, שאילתות מהירות, נפח צפוי

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

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

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

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

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

ניהול InfluxDB: שרתים משלכם, ענן או היברידי

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: איך הסרנו אובדן מדדים במערך תעשייתי

לפני: נקודות אבדו בלי שימו לב

המערך של לקוח תעשייתי – כ-42,000 מקורות: חיישנים, שערים ובקרי קווים עם מרווח סקירה משלהם. הכול נכתב לצומת InfluxDB אחד עם שמירה ללא הגבלת זמן וקרדינליות תגים גדלה.

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

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

מה שינינו

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

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

מדידות לאחר הבנייה מחדש

• מקורות בניטור – כ-42,000, הגידול נמשך בלי לשנות את הסכמה
• אובדן נקודות במשמרות שיא – מ-3–7% לפחות מ-0.1%
• שחזור לאחר כשל צומת – מארבע שעות ל-12 דקות
• המאגר הצטמצם פי שלושה: נתונים גולמיים אינם נשמרים עוד לנצח
• סוג הכשל השתנה: במקום אובדן שקט – פיגור כתיבה מורגש והתראה לתורן

מה לעשות אם בסיס המדדים כבר פרוס ועובד?

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

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

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

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

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

ספקות טכניים: נפח, אובדן, תאימות

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

כיצד להעביר היסטוריה מצטברת בלי לעצור את האיסוף?

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

החלפת סכמה שוברת נתונים ישנים?

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

האם לאחר תקלה ההיסטוריה תשוחזר?

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

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

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

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

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

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

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