VictoriaMetrics וניטור ענן פרטי. פאבל קולובייב

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

שמי קולובייב פאבל. DevOps, SRE, LeroyMerlin, הכל כמו קוד - הכל תלוי בנו: עלי ובקשר לעובדים אחרים של LeroyMerlin.

https://bit.ly/3jf1fIK

יש ענן המבוסס על OpenStack. יש קישור קטן לרדאר הטכני.

הוא בנוי על חומרת Kubernetes, כמו גם על כל השירותים הקשורים ל-OpenStack ולרישום.

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

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

הפתרון הראשון הוא שאנו משתמשים בפדרציה כאשר יש לנו Prometheus של צד שלישי, כאשר אנו עוברים לאשכול Kubernetes דרך מנגנון הפדרציה.

אבל יש כאן כמה בעיות קטנות. במקרה שלנו, הבעיות התחילו כשהיו לנו 250 מדדים, וכשהיו 000 מדדים, הבנו שאנחנו לא יכולים לעבוד ככה. הגדלנו scrape_timeout ל-400 שניות.

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

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

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

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

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

האפשרות הראשונה היא שאנחנו רוצים לנטוש את מנגנון הפדרציה כי הוא איטי מאוד.

מפתחי Prometheus אומרים בבירור, "חבר'ה, השתמשו ב-TimescaleDB אחר כי אנחנו לא נתמוך באחסון מדדים לטווח ארוך." זו לא המשימה שלהם.

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

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

עכשיו יש לנו סביבת מפתחים ופרודים. ב-dev זה בערך 9 גיגה-בייט עבור 350 מדדים. בתפוקה מדובר ב-000 גיגה-בייט וקצת יותר מ-14 מדדים. יחד עם זאת, זמן השמירה שלנו הוא 780 דקות בלבד. זה רע. ועכשיו אסביר למה.

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

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

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

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

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

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

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

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

החסרונות לפי הסדר בצורה שבה רשמנו אותם לעצמנו:

• מחייב העלאת מדדים חיצונית.
• צריכת משאבים גבוהה.
• אין דרך להגביל את צריכת הזיכרון.
• יישום מורכב ועתיר משאבים של HA.

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

זיהינו לעצמנו דרישות נוספות שאנו צריכים. זֶה:

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

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

למה? כי:

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

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

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

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

אנו משווים שני מקורות נתונים של אותם נתונים. בפרומתאוס אנו רואים את אותם נתונים חסרים. הכל בסדר ב-VictoriaMetrics.

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

אנו גם חוסכים בצריכת משאבי זיכרון. בזמן הבדיקה, פרסו לנו את פרומתאוס במכונה וירטואלית - 8 ליבות, 24 גיגה-בייט. פרומתאוס אוכל כמעט הכל. הוא נפל על OOM Killer. במקביל, רק 900 מדדים פעילים נוצקו לתוכו. זה בערך 000-25 מדדים לשנייה.

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

המעבד הפך להרבה יותר טוב בהשוואה ל-Prometheus. כאן פרומתאוס צורך 2,5 ליבות, ו-VictoriaMetrics צורכת רק 0,25 ליבות. בהתחלה - 0,5 ליבות. כשהיא מתמזגת, היא מגיעה לליבה אחת, אבל זה מאוד מאוד נדיר.

במקרה שלנו, הבחירה נפלה על VictoriaMetrics מסיבות ברורות; רצינו לחסוך כסף ועשינו זאת.

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

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

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

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

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

באיטרציות הראשונות, בדקנו את VictoriaMetrics Single Node. לאחר מכן נעבור לגרסת האשכולות של VictoriaMetrics.

כאן יש לנו יד חופשית להפריד בין שירותים שונים ב-VictoriaMetrics בהתאם למה שהם יפעלו ואיזה משאבים הם יצרכו. זהו פתרון מאוד גמיש ונוח. השתמשנו בזה על עצמנו.

המרכיבים העיקריים של VictoriaMetrics Cluster Version הם vmstsorage. יכול להיות מספר N מהם. במקרה שלנו יש 2 מהם עד כה.

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

Vminsert תומך בפרוטוקולי OpenTSDB, Graphite, InfluxDB ו-RemoteWrite מ-Prometheus.

יש גם vmselect. המשימה העיקרית שלו היא לעבור ל-vmstorage, לקבל מהם נתונים, לבטל כפילות של נתונים אלה ולתת אותם ללקוח.

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

שירות מעולה נוסף הוא vmalert, המאפשר לך להשתמש ב-VictoriaMetrics כ-backend, לקבל נתונים מעובדים מ-vminsert ולשלוח אותם ל-vmselect. הוא מעבד את ההתראות עצמן, כמו גם את הכללים. במקרה של התראות, אנו מקבלים את ההתראה דרך alertmanager.

יש רכיב wmauth. אנו עשויים או לא (עדיין לא החלטנו על כך) להשתמש בו כמערכת הרשאה עבור גרסת ריבוי הנכסים של אשכולות. הוא תומך ב-remoteWrite עבור Prometheus ויכול לאשר על סמך כתובת ה-URL, או ליתר דיוק החלק השני שלה, שבו אתה יכול או לא יכול לכתוב.

יש גם vmbackup, vmrestore. זהו, בעצם, שחזור וגיבוי של כל הנתונים. יכול לעשות S3, GCS, קובץ.

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

כאן אסתיג שכאשר עברנו מ-VictoriaMetrics Single Node ל-VictoriaMetrics Cluster Version, עדיין נשארנו עם אותם משאבים נצרכים, כלומר העיקרי שבהם הוא הזיכרון. כך בערך הופצו הנתונים שלנו, כלומר צריכת משאבים.

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

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

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

יש לנו התראה. אנחנו משתמשים בו. אנו משתמשים ב-alertmanager מ-Prometheus. אנו משתמשים ב-Opsgenie ובטלגרם כערוץ מסירת התראה. בטלגרם מוזגים מ-dev, אולי משהו מ-prod, אבל בעיקר משהו סטטיסטי, שדרוש למהנדסים. ואופסגני היא קריטית. אלו שיחות, ניהול אירועים.

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

אנו מסיימים את הרשימה שלנו ביישום HA.

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

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

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

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

ישנן הצעות לשיפור יישום האשכול. ציינתי אותם למעלה.

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

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

נשתמש ב-VictoriaMetrics בבית כי מאוד אהבנו את זה. זה מה שהיה ומה שהפך להיות.

https://t.me/VictoriaMetrics_ru1

כמה קודי QR לצ'אט של VictoriaMetrics, אנשי הקשר שלי, רדאר טכני של LeroyMerlin.

מקור: www.habr.com