מערכת ניטור נוספת

16 מודמים, 4 מפעילים סלולריים = מהירות יציאה 933.45 Mbit/s

מבוא

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

О проекте

יש לנו מוצר ספציפי למדי. אנו מייצרים פתרון מקיף לסיכום התפוקה וסובלנות התקלות של ערוצי העברת נתונים. זה כשיש כמה ערוצים, נניח אופרטור1 (40Mbit/s) + Operator2 (30Mbit/s)+ משהו אחר (5Mbit/s), התוצאה היא ערוץ אחד יציב ומהיר, שהמהירות שלו תהיה משהו כמו זה: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

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

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

הצהרת הבעיה

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

1. רכישה סינכרונית בתדר גבוה של מדדים בזמן אמת והעברתם למערכת ניהול התקשורת ללא דיחוי.
   תדר גבוה וסנכרון של מדדים שונים הוא לא רק חשוב, הוא חיוני לניתוח האנטרופיה של ערוצי שידור נתונים. אם בערוץ שידור נתונים אחד ההשהיה הממוצעת היא 30 מילישניות, אזי שגיאה בסנכרון בין המדדים הנותרים של אלפית שניה אחת בלבד תוביל לירידה של מהירות הערוץ המתקבל בכ-5%. אם נתזמן לא נכון את התזמון ב-1 אלפית שנייה על פני 4 ערוצים, הפחתת המהירות יכולה בקלות לרדת ל-30%. בנוסף, האנטרופיה בערוצים משתנה מהר מאוד, כך שאם נמדוד אותה פחות מפעם אחת כל 0.5 מילישניות, בערוצים מהירים עם השהייה קטנה נקבל השפלה במהירות גבוהה. כמובן, דיוק כזה אינו נחוץ עבור כל המדדים ולא בכל התנאים. כאשר ההשהיה בערוץ היא 500 מילי-שניות, ואנחנו עובדים עם כאלה, אז שגיאה של 1 אלפית שנייה כמעט לא תהיה מורגשת. כמו כן, עבור מדדי מערכת תמיכת חיים, יש לנו מספיק קצבי סקרים וסנכרון של 2 שניות, אבל מערכת הניטור עצמה חייבת להיות מסוגלת לעבוד עם קצבי סקרים גבוהים במיוחד וסנכרון מדויק במיוחד של מדדים.
2. צריכת משאבים מינימלית וערימה אחת.
   מכשיר הקצה יכול להיות קומפלקס רב עוצמה על הסיפון שיכול לנתח את המצב בכביש או לבצע הקלטה ביומטרית של אנשים, או מחשב לוח יחיד בגודל כף היד שחייל כוחות מיוחדים עונד מתחת לשריון הגוף שלו כדי להעביר בו וידאו. זמן אמת בתנאי תקשורת גרועים. למרות מגוון כזה של ארכיטקטורות וכוח מחשוב, היינו רוצים לקבל את אותה ערימת תוכנה.
3. ארכיטקטורת מטריות
   יש לאסוף ולצבור מדדים במכשיר הקצה, לאחסן באופן מקומי ולהמחיש אותם בזמן אמת ובדיעבד. אם יש חיבור, העבר נתונים למערכת הניטור המרכזית. כאשר אין חיבור, תור השליחה אמור להצטבר ולא לצרוך זיכרון RAM.
4. API לשילוב במערכת הניטור של הלקוח, כי אף אחד לא צריך הרבה מערכות ניטור. על הלקוח לאסוף נתונים מכל מכשיר ורשת לניטור אחד.

מה קרה

כדי לא להכביד על ה-longread המרשים ממילא, לא אתן דוגמאות ומדידות של כל מערכות הניטור. זה יוביל לכתבה נוספת. אני רק אגיד שלא הצלחנו למצוא מערכת ניטור שמסוגלת לקחת שני מדדים בו-זמנית עם שגיאה של פחות ממילישניה אחת ועובדת באותה יעילות הן בארכיטקטורת ARM עם 1 MB של זיכרון RAM והן בארכיטקטורת x64_86 עם 64 GB של זיכרון RAM. לכן, החלטנו לכתוב משלנו, שיכול לעשות את כל זה. הנה מה שקיבלנו:

סיכום התפוקה של שלושה ערוצים עבור טופולוגיות רשת שונות

הדמיה של כמה מדדי מפתח

אדריכלות

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

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

1. רישום מדדים.
   כל מדד מוגש באמצעות חוט משלו ומסונכרן בין ערוצים. הצלחנו להשיג דיוק סנכרון של עד 10 ננו-שניות.
2. אחסון מדדים
   בחרנו בין כתיבת אחסון משלנו לסדרות זמן או להשתמש במשהו שכבר היה זמין. בסיס הנתונים נחוץ לנתונים רטרוספקטיביים הכפופים להדמיה לאחר מכן, כלומר, הוא אינו מכיל נתונים על עיכובים בערוץ כל 0.5 מילישניות או קריאות שגיאות ברשת התחבורה, אלא ישנה מהירות בכל ממשק כל 500 מילישניות. בנוסף לדרישות הגבוהות לצלב פלטפורמות וצריכת משאבים נמוכה, חשוב לנו ביותר להיות מסוגלים לעבד. הנתונים הם המקום שבו הם מאוחסנים. זה חוסך משאבי מחשוב אדירים. אנו משתמשים ב-Tarantool DBMS בפרויקט זה מאז 2016 ועד כה איננו רואים תחליף לו באופק. גמיש, עם צריכת משאבים אופטימלית, יותר מתמיכה טכנית מספקת. Tarantool גם מיישמת מודול GIS. כמובן, זה לא חזק כמו PostGIS, אבל זה מספיק עבור המשימות שלנו של אחסון כמה מדדים הקשורים למיקום (רלוונטיים לתחבורה).
3. ויזואליזציה של מדדים
   הכל כאן יחסית פשוט. אנו לוקחים נתונים מהמחסן ומציגים אותם בזמן אמת או בדיעבד.
4. סנכרון נתונים עם מערכת הניטור המרכזית.
   מערכת הניטור המרכזית קולטת נתונים מכל המכשירים, מאחסנת אותם עם היסטוריה מוגדרת ושולחת אותם למערכת הניטור של הלקוח באמצעות API. בניגוד למערכות ניטור קלאסיות, שבהן "הראש" מסתובב ואוסף נתונים, יש לנו תוכנית הפוכה. המכשירים עצמם שולחים נתונים כאשר יש חיבור. זוהי נקודה חשובה ביותר, שכן היא מאפשרת לקבל נתונים מהמכשיר עבור אותם פרקי זמן שבהם הוא לא היה זמין ולא לטעון ערוצים ומשאבים בזמן שהמכשיר אינו זמין. אנו משתמשים בשרת ניטור Influx כמערכת ניטור מרכזית. שלא כמו האנלוגים שלו, הוא יכול לייבא נתונים רטרוספקטיביים (כלומר, עם חותמת זמן שונה מרגע קבלת המדדים). המדדים שנאספו מומחשים על ידי Grafana, משתנים עם קובץ. מחסנית סטנדרטית זו נבחרה גם מכיוון שיש לה שילובי API מוכנים עם כמעט כל מערכת ניטור לקוחות.
5. סנכרון נתונים עם מערכת מרכזית לניהול מכשירים.
   מערכת ניהול המכשירים מיישמת Zero Touch Provisioning (עדכון קושחה, תצורה וכו') ובניגוד למערכת הניטור, מקבלת רק בעיות לכל מכשיר. אלו הם טריגרים לתפעול שירותי שמירה על חומרה על הלוח וכל המדדים של מערכות תומכות חיים: טמפרטורת מעבד ו-SSD, עומס מעבד, מקום פנוי ותקינות SMART על דיסקים. גם האחסון של תת המערכת בנוי על Tarantool. זה נותן לנו מהירות משמעותית בצבירה של סדרות זמן על פני אלפי מכשירים, וגם פותר לחלוטין את נושא סנכרון הנתונים עם המכשירים הללו. ל-Tarantool מערכת תור מעולה ומערכת משלוחים מובטחת. הוצאנו את התכונה החשובה הזו מהקופסה, נהדר!

מערכת ניהול רשת

מה הלאה

עד כה, החוליה החלשה ביותר שלנו היא מערכת הניטור המרכזית. הוא מיושם ב-99.9% בערימה סטנדרטית ויש לו מספר חסרונות:

1. InfluxDB מאבד נתונים כאשר החשמל אבד. ככלל, הלקוח אוסף מיידית את כל מה שמגיע מהמכשירים והמאגר עצמו אינו מכיל נתונים מעל 5 דקות, אך בעתיד הדבר עלול להפוך לכאב.
2. לגרפאנה יש מספר בעיות עם צבירת נתונים וסנכרון של התצוגה שלו. הבעיה הנפוצה ביותר היא כאשר מסד הנתונים מכיל סדרת זמן עם מרווח של 2 שניות שמתחיל, למשל, 00:00:00, ו-Grafana מתחילה להציג נתונים בצבירה מ-+1 שנייה. כתוצאה מכך, המשתמש רואה גרף רוקד.
3. כמות מוגזמת של קוד לשילוב API עם מערכות ניטור של צד שלישי. אפשר לעשות את זה הרבה יותר קומפקטי וכמובן לשכתב ב-Go)

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

מסקנה

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

אם למישהו יש שאלות מעבר לתחום המאמר הזה, אתה יכול לכתוב לי בכתובת a.rodin @ qedr.com

מקור: www.habr.com