Bioyino - אגרגטור מדדים מבוזר וניתן להרחבה

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

מהמאמרים הקודמים שלנו (1, 2) אתה יכול לגלות שעד זמן מה אספנו סימנים באמצעות ברובק. זה כתוב ב-C. מנקודת מבט של קוד, זה פשוט כמו תקע (זה חשוב כשרוצים לתרום) והכי חשוב, הוא מטפל בנפחים שלנו של 2 מיליון מדדים לשנייה (MPS) בשיא בלי שום בעיות. התיעוד מציין תמיכה ב-4 מיליון MPS עם כוכבית. המשמעות היא שתקבל את הנתון הנקוב אם תגדיר את הרשת בצורה נכונה בלינוקס. (אנחנו לא יודעים כמה MPS אתה יכול לקבל אם תשאיר את הרשת כפי שהיא). למרות היתרונות הללו, היו לנו כמה תלונות רציניות על ברבק.

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

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

כמו שזה היה

איך זה היה צריך להיות

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

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

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

מכיוון שהיה לנו מקום לשינוי קנה מידה, החלטנו להתחיל עם סובלנות תקלות. "על אודות! סובלנות תקלות! זה פשוט, אנחנו יכולים לעשות את זה", חשבנו והשקנו 2 שרתים, והעלינו עותק של brubeck על כל אחד מהם. לשם כך, היינו צריכים להעתיק תעבורה עם מדדים לשני השרתים ואפילו לכתוב בשביל זה שירות קטן. פתרנו את בעיית סבילות התקלות עם זה, אבל... לא ממש טוב. בהתחלה הכל נראה נהדר: כל ברבק אוסף גרסה משלו של צבירה, כותב נתונים ל-Graphite פעם ב-30 שניות, מחליף את המרווח הישן (זה נעשה בצד של גרפיט). אם שרת אחד נכשל פתאום, תמיד יש לנו שרת שני עם עותק משלו של הנתונים המצטברים. אבל הנה הבעיה: אם השרת נכשל, "מסור" מופיע על הגרפים. זאת בשל העובדה שהמרווחים של 30 שניות של ברבק אינם מסונכרנים, וברגע התרסקות אחד מהם אינו מוחלף. כשהשרת השני מתחיל, אותו דבר קורה. די נסבל, אבל אני רוצה יותר טוב! גם בעיית המדרגיות לא נעלמה. כל המדדים עדיין "עפים" לשרת בודד, ולכן אנו מוגבלים לאותם 2-4 מיליון MPS, תלוי ברמת הרשת.

אם אתה חושב קצת על הבעיה ובו בזמן לחפור שלג עם חפירה, ייתכן שהרעיון הברור הבא יעלה בראשך: אתה צריך סטטיסטיקה שיכולה לעבוד במצב מבוזר. כלומר, כזה שמיישם סנכרון בין צמתים בזמן ובמדדים. "כמובן, פתרון כזה כנראה כבר קיים," אמרנו והלכנו לגוגל... והם לא מצאו כלום. לאחר שעברתי על התיעוד עבור נתונים סטטיסטיים שונים (https://github.com/etsy/statsd/wiki#server-implementations נכון ל-11.12.2017 בדצמבר XNUMX), לא מצאנו שום דבר. ככל הנראה, לא המפתחים ולא המשתמשים של הפתרונות הללו עדיין נתקלו בכל כך הרבה מדדים, אחרת הם בהחלט היו מעלים משהו.

ואז נזכרנו ב-"toy" statsd - bioyino, שנכתב בהאקתון Just for Fun (שם הפרויקט נוצר על ידי התסריט לפני תחילת ההאקתון) והבנו שאנחנו זקוקים בדחיפות לסטטיסטיקה משלנו. בשביל מה?

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

על מה לכתוב? כמובן, ברוסט. למה?

• כי כבר היה פתרון אב טיפוס,
• כי מחבר המאמר כבר הכיר את Rust באותה תקופה והיה להוט לכתוב בו משהו להפקה עם ההזדמנות לשים אותו בקוד פתוח,
• מכיוון ששפות עם GC אינן מתאימות לנו בגלל אופי התעבורה המתקבלת (כמעט בזמן אמת) והפסקות GC הן כמעט בלתי קבילות,
• כי אתה צריך ביצועים מקסימליים בהשוואה ל-C
• כי Rust מספקת לנו במקביליות חסרת פחד, ואם היינו מתחילים לכתוב את זה ב-C/C++, היינו גוררים אפילו יותר נקודות תורפה, הצפת חוצץ, תנאי גזע ומילים מפחידות אחרות מברובק.

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

הזמן עבר...

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

כל צומת מקבל סט מדדים משלו וצובר אותם, ואינו צובר מדדים עבור אותם סוגים שבהם נדרשת הסט המלא שלהם לצבירה סופית. הצמתים מחוברים זה לזה על ידי סוג של פרוטוקול נעילה מבוזר, המאפשר לבחור ביניהם את היחיד (כאן בכינו) שראוי לשלוח מדדים ל-Great One. בעיה זו נפתרת כעת על ידי קוֹנסוּל, אבל בעתיד השאיפות של המחבר מתרחבות עד משלו יישום רפסודה, שבה הראוי ביותר יהיה, כמובן, צומת מנהיג הקונצנזוס. בנוסף לקונצנזוס, צמתים לעתים קרובות למדי (פעם בשנייה כברירת מחדל) שולחים לשכניהם את אותם חלקים של מדדים מצטברים מראש שהם הצליחו לאסוף באותה שנייה. מסתבר שקנה ​​המידה וסובלנות התקלות נשמרים - כל צומת עדיין מחזיק בסט שלם של מדדים, אבל המדדים נשלחים כבר מצטברים, דרך TCP ומקודדים לפרוטוקול בינארי, כך שעלויות השכפול מופחתות משמעותית בהשוואה ל-UDP. למרות המספר הרב למדי של מדדים נכנסים, צבירה דורשת מעט מאוד זיכרון ואפילו פחות מעבד. עבור ה-Mertics הניתנים לדחיסה, מדובר רק בכמה עשרות מגה-בייט של נתונים. כבונוס נוסף, אנחנו לא מקבלים שכתוב נתונים מיותרים ב-Graphite, כפי שהיה במקרה של burbeck.

מנות UDP עם מדדים אינן מאוזנות בין צמתים בציוד רשת באמצעות Round Robin פשוט. כמובן שחומרת הרשת לא מנתחת את תוכן החבילות ולכן יכולה למשוך הרבה יותר מ-4M מנות לשנייה, שלא לדבר על מדדים שהיא לא יודעת עליהם כלום. אם ניקח בחשבון שהמדדים לא מגיעים אחד בכל פעם בכל חבילה, אז אנחנו לא צופים בעיות ביצועים במקום הזה. אם שרת קורס, התקן הרשת מזהה במהירות (בתוך 1-2 שניות) עובדה זו ומסיר את השרת הקורס מסיבוב. כתוצאה מכך, ניתן להפעיל ולכבות צמתים פסיביים (כלומר, שאינם מובילים) כמעט מבלי לשים לב לחסרונות בתרשימים. הכי הרבה שאנחנו מפסידים זה חלק מהמדדים שנכנסו בשנייה האחרונה. אובדן/כיבוי פתאומי של מוביל עדיין ייצור חריגה מינורית (המרווח של 30 השניות עדיין לא מסונכרן), אבל אם יש תקשורת בין צמתים, ניתן למזער את הבעיות הללו, למשל, על ידי שליחת מנות סנכרון .

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

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

הרבה יותר בעיות במהלך הפיתוח נגרמו על ידי חלק הרשת שאחראי על קבלת מדדים. המטרה העיקרית של הפרדת זרימות רשת לישויות נפרדות הייתה הרצון לצמצם את הזמן שזרימה מבלה לא כדי לקרוא נתונים מהשקע. האפשרויות המשתמשות ב-UDP אסינכרוני ו-recvmsg רגיל נעלמו במהירות: הראשונה צורכת יותר מדי מעבד של שטח משתמש לעיבוד אירועים, השנייה דורשת יותר מדי מתגי הקשר. לכן הוא משמש כעת recvmmsg עם חוצצים גדולים (וחצצים, רבותי קצינים, הם כלום בשבילכם!). תמיכה ב-UDP רגיל שמורה למקרים קלים שבהם אין צורך ב-recvmmsg. במצב ריבוי הודעות, אפשר להשיג את העיקר: ברוב המוחלט של הזמן, חוט הרשת מגרף את תור מערכת ההפעלה - קורא נתונים מהשקע ומעביר אותם למאגר ה-userspace, רק מדי פעם עובר לתת את המאגר המלא ל אגרגטורים. התור בשקע כמעט לא מצטבר, מספר החבילות שנפלו כמעט לא גדל.

שים לב

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

לבסוף, כמה תרשימים לאוהבי תרשימים.

סטטיסטיקה על מספר המדדים הנכנסים עבור כל שרת: יותר מ-2 מיליון MPS.

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

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

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

פירוט של מדדים נכנסים (שמות מדדים מוסתרים).

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

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

עם זה נאמר, זה הכל אנשים, קנו את הפילים שלנו!

מקור: www.habr.com