ניתוח TSDB בפרומתאוס 2

מסד הנתונים של סדרות הזמן (TSDB) ב-Prometheus 2 הוא דוגמה מצוינת לפתרון הנדסי המציע שיפורים משמעותיים ביחס לאחסון v2 ב-Prometheus 1 מבחינת צבירת נתונים ומהירות ביצוע שאילתות, ויעילות משאבים. הטמענו את Prometheus 2 ב-Percona ניטור וניהול (PMM) והייתה לי ההזדמנות להבין את הביצועים של Prometheus 2 TSDB. במאמר זה אדבר על תוצאות התצפיות הללו.

עומס עבודה ממוצע של פרומתאוס

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

מבחן עומס

במהלך הבדיקה התמקדתי ביכולת לצבור נתונים. פרסתי את Prometheus 2.3.2 הידור עם Go 1.10.1 (כחלק מ-PMM 1.14) בשירות Linode באמצעות הסקריפט הזה: StackScript. ליצירת העומס המציאותי ביותר, השתמש בזה StackScript השקתי מספר צמתי MySQL עם עומס אמיתי (Sysbench TPC-C Test), שכל אחד מהם חיקה 10 צמתים של Linux/MySQL.
כל הבדיקות הבאות בוצעו על שרת Linode עם שמונה ליבות וירטואליות וזיכרון של 32 ג'יגה-בייט, תוך הפעלת 20 סימולציות עומס המנטרות מאתיים מופעי MySQL. או, במונחים של פרומתאוס, 800 מטרות, 440 שריטות בשנייה, 380 אלף שיאים בשנייה ו-1,7 מיליון סדרות זמן פעילות.

תכנית

הגישה הרגילה של מסדי נתונים מסורתיים, כולל זו שבה משתמש Prometheus 1.x, היא מגבלת זיכרון. אם זה לא מספיק כדי להתמודד עם העומס, אתה תחווה זמן השהייה גבוה וחלק מהבקשות ייכשלו. שימוש בזיכרון ב-Prometheus 2 ניתן להגדרה באמצעות מפתח storage.tsdb.min-block-duration, הקובע כמה זמן ההקלטות יישמרו בזיכרון לפני ההדחה לדיסק (ברירת המחדל היא שעתיים). כמות הזיכרון הנדרשת תהיה תלויה במספר סדרות הזמן, התוויות ושריטות שנוספו לזרם הנכנס נטו. מבחינת שטח דיסק, פרומתאוס שואפת להשתמש ב-2 בתים לרשומה (מדגם). מצד שני, דרישות הזיכרון הרבה יותר גבוהות.

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

כפי שניתן לראות מהגרף, שטיפות לדיסק מתרחשות כל שעתיים. אם תשנה את הפרמטר של משך החסימה המינימלית לשעה אחת, האיפוסים הללו יתרחשו כל שעה, החל לאחר חצי שעה.
אם אתה רוצה להשתמש בגרף זה ובגרפים אחרים בהתקנת Prometheus שלך, אתה יכול להשתמש בזה לוּחַ מַחווָנִים. הוא תוכנן עבור PMM אך, עם שינויים קלים, מתאים לכל התקנה של פרומתאוס.
יש לנו בלוק פעיל שנקרא head block אשר מאוחסן בזיכרון; בלוקים עם נתונים ישנים יותר זמינים באמצעות mmap(). זה מבטל את הצורך להגדיר את המטמון בנפרד, אבל גם אומר שעליך להשאיר מספיק מקום עבור המטמון של מערכת ההפעלה אם ברצונך לבצע שאילתות נתונים ישנים יותר ממה שה-head block יכול להכיל.
זה גם אומר שצריכת הזיכרון הווירטואלי של Prometheus תיראה די גבוהה, וזה לא משהו שצריך לדאוג לגביו.

נקודת עיצוב מעניינת נוספת היא השימוש ב-WAL (כתבו קדימה יומן). כפי שניתן לראות מתיעוד האחסון, פרומתאוס משתמשת ב-WAL כדי למנוע קריסות. מנגנונים ספציפיים להבטחת שרידות הנתונים, למרבה הצער, אינם מתועדים היטב. Prometheus גרסה 2.3.2 שוטפת את WAL לדיסק כל 10 שניות ואפשרות זו אינה ניתנת להגדרה על ידי המשתמש.

דחיסות

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

אם תרצו ללמוד עוד על החנות, תוכלו לבחון את קובץ meta.json, שבו יש מידע על הבלוקים הזמינים וכיצד הם נוצרו.

{
       "ulid": "01CPZDPD1D9R019JS87TPV5MPE",
       "minTime": 1536472800000,
       "maxTime": 1536494400000,
       "stats": {
               "numSamples": 8292128378,
               "numSeries": 1673622,
               "numChunks": 69528220
       },
       "compaction": {
               "level": 2,
               "sources": [
                       "01CPYRY9MS465Y5ETM3SXFBV7X",
                       "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                       "01CPZ6NR4Q3PDP3E57HEH760XS"
               ],
               "parents": [
                       {
                               "ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
                               "minTime": 1536472800000,
                               "maxTime": 1536480000000
                       },
                       {
                               "ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                               "minTime": 1536480000000,
                               "maxTime": 1536487200000
                       },
                       {
                               "ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
                               "minTime": 1536487200000,
                               "maxTime": 1536494400000
                       }
               ]
       },
       "version": 1
}

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

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

קוצים בעומס המעבד

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

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

התאוששות לאחר כישלון

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

level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."

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

להתחמם

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

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

עליות עומס המעבד

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

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

אתה יכול גם לשים לב שיצואן Prometheus נכבה לשנייה אחת.

אנו יכולים להבחין בקורלציות עם איסוף אשפה (GC).

מסקנה

TSDB ב-Prometheus 2 מהיר, מסוגל לטפל במיליוני סדרות זמן ובמקביל באלפי רשומות בשנייה תוך שימוש בחומרה צנועה למדי. גם ניצול ה-I/O של המעבד והדיסק מרשים. הדוגמה שלי הראתה עד 200 מדדים לשנייה לכל ליבה בשימוש.

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

כמובן, יש עוד הרבה עבודה לעשות כדי לאלף את קוצי ה-I/O של המעבד והדיסק, וזה לא מפתיע בהתחשב עד כמה צעיר TSDB Prometheus 2 לעומת InnoDB, TokuDB, RocksDB, WiredTiger, אבל לכולם היה דומה בעיות בתחילת מחזור החיים.

מקור: www.habr.com