שלום לכולם. להלן התמליל .
– מערכת ניטור למערכות ושירותים שונים, בעזרתה יכולים מנהלי מערכות לאסוף מידע על הפרמטרים העדכניים של המערכות ולהגדיר התראות לקבלת הודעות על חריגות בהפעלת המערכות.
הדו"ח יכלול השוואה и - פרויקטים לאחסון לטווח ארוך של מדדי פרומתאוס.
ראשית, אספר לכם על פרומתאוס. זוהי מערכת ניטור שאוספת מדדים מיעדים שצוינו ושומרת אותם לאחסון מקומי. פרומתאוס יכול להקליט מדדים לאחסון מרוחק ויכול ליצור התראות וכללי הקלטה.
מגבלות פרומתאוס:
- אין לו תצוגת שאילתה גלובלית. זה כאשר יש לך מספר מקרים עצמאיים של פרומתאוס. הם אוספים מדדים. ואתה רוצה לבצע שאילתה על כל המדדים האלה שנאספו ממופעי פרומתאוס שונים. פרומתאוס לא מאפשר זאת.
- עם פרומתאוס, הביצועים מוגבלים לשרת אחד בלבד. Prometheus אינו משתנה באופן אוטומטי על פני מספר שרתים. אתה יכול רק לפצל ידנית את המטרות שלך בין פרומתאוס מרובים.
- היקף המדדים ב-Prometheus מוגבל לשרת אחד בלבד מאותה סיבה שהוא לא יכול להתאים באופן אוטומטי למספר שרתים.
- זה לא כל כך קל לארגן את בטיחות הנתונים בפרומתאוס.
פתרונות לבעיות/אתגרים אלו?
הפתרונות הם:
כל הפתרונות הללו מיועדים לאחסון מרחוק של נתונים שנאספו על ידי פרומתאוס. הם פותרים את בעיית האחסון המרוחק מהשקופית הקודמת בדרכים שונות. במצגת זו אדבר רק על שני הפתרונות הראשונים: и .
לראשונה מידע על הופיע על ידי . האדריכלות מתוארת שם ואיך זה עובד.
Thanos לוקח את הנתונים שפרומתאוס שמר לדיסק המקומי ומעתיק אותם ל-S3, אל או לאחסון חפצים אחר.
לפיכך Thanos מספקת תצוגת שאילתה גלובלית. אתה יכול לבצע שאילתות בנתונים המאוחסנים באחסון אובייקטים ממופעי Prometheus מרובים.
Thanos תומך ב-PromQL ו .
Thanos משתמש בקוד Prometheus כדי לאחסן נתונים.
Thanos פותח על ידי אותם מפתחים כמו Prometheus.
על . כאן , שבו דיברנו לראשונה .
VictoriaMetrics מקבלת נתונים מכמה פרומתאוסים פרוטוקול נתמך על ידי פרומתאוס.
VictoriaMetrics מספקת תצוגת שאילתה גלובלית, מכיוון שמספר מופעים של Prometheus יכולים לכתוב נתונים ל-VictoriaMetrics אחד. בהתאם לכך, ניתן לבצע שאילתות על כל הנתונים הללו.
VictoriaMetrics גם תומכת, כמו Thanos, PromQL ו-Prometheus שאילתות API.
שלא כמו Thanos, קוד המקור של VictoriaMetrics נכתב מאפס ומותאם למהירות ולצריכת משאבים.
VictoriaMetrics, בניגוד ל-Thanos, משתנה הן אנכית והן אופקית. לאכול , אשר קנה מידה אנכית. אתה יכול להתחיל עם מעבד אחד ו-1 ג'יגה-בייט של זיכרון ולגדול בהדרגה למאות מעבדים ו-1 TB של זיכרון. VictoriaMetrics יכולה להשתמש בכל המשאבים הללו. הביצועים שלו יעלו בכ-100 פעמים בהשוואה למערכת בעלת ליבה אחת.
ההיסטוריה של תאנוס החלה בנובמבר 2017, כאשר הופיעה ההתחייבות הציבורית הראשונה. לפני כן, Thanos פותחה באופן פנימי .
ביוני 2019 הייתה מהדורה נקודתית 0.5.0, שבה נוהל. הוא הורחק מת'אנוס כי הוא לא הצליח. לעתים קרובות, אשכול Thanos לא פעל כהלכה, צמתים מחוברים אליו בצורה שגויה בגלל פרוטוקול הרכילות. לכן החלטנו לסלק אותו משם. אני חושב שזו ההחלטה הנכונה.
באותו יוני 2019, הם שלחו את מספר הבקשה в .
ואחרי כמה חודשים תאנוס התקבל , הכולל את Prometheus, Kubernetes ופרויקטים פופולריים אחרים.
בינואר 2018 החל הפיתוח של VictoriaMetrics.
בספטמבר 2018, הזכרתי בפומבי את VictoriaMetrics בפעם הראשונה.
בדצמבר 2018 פורסמה גרסת צומת יחיד.
בחודש מאי 2019 מקורות של גרסאות צומת יחיד וגם של אשכול.
ביוני 2019, בדיוק כמו Thanos, הגשנו בקשה לקרן CNCF תחת מספר . החלנו יום אחד לפני שתאנוס החל.
אבל, למרבה הצער, עדיין לא התקבלנו לשם. דרושה עזרה בקהילה.
בואו נסתכל על השקופיות החשובות ביותר המציגות את הארכיטקטורה של Thanos ו-VictoriaMetrics.
בואו נתחיל עם ת'אנוס. הרכיבים הצהובים הם רכיבי פרומתאוס. כל השאר הם רכיבי Thanos. נתחיל עם המרכיב החשוב ביותר. Thanos Sidecar הוא רכיב המותקן ליד כל פרומתאוס. הוא טוען נתוני Prometheus מאחסון מקומי לתוך S3 או אחסון אובייקטים אחר.
יש גם רכיב שנקרא Thanos Store Gateway, שיכול לקרוא נתונים אלה מאחסון אובייקטים לאחר בקשות נכנסות מ-Thanos Query. Thanos Query מיישמת PromQL ו-Prometheus API. כלומר, מבחוץ זה נראה כמו פרומתאוס. מקבל שאילתות PromQL, שולח אותן אל Thanos Store Gateway, Thanos Store Gateway מאחזר את הנתונים הדרושים מ-Object Storage, שולח אותם בחזרה.
אבל אנחנו מאחסנים נתונים ב-Object Storage ללא השעתיים האחרונות בגלל תכונה של מימוש Thanos Sidecar, שלא יכולה להעלות את השעתיים האחרונות ל-Object Storage S3, מכיוון ש-Prometheus עדיין לא יצרה קבצים עבור השעתיים הללו באחסון מקומי.
איך החלטת לעקוף את זה? Thanos Query, בנוסף לבקשות אל Thanos Store Gateway, שולחת בקשות מקבילות לכל Thanos Sidecar, שנמצאת ליד פרומתאוס.
ו-Thanos Sidecar, בתורו, מעביר בקשות נוספות ל-Prometheus, ומחזיר נתונים עבור השעתיים האחרונות.
בנוסף לרכיבים אלו, ישנו גם רכיב אופציונלי שבלעדיו Thanos לא תתפקד טוב. זהו Thanos Compact, שאחראי למיזוג קבצים קטנים ב-Object Storage לקבצים גדולים יותר שהועלו לכאן על ידי Thanos Sidecars. Thanos Sidecar מעלה לשם קבצי נתונים תוך שעתיים. קבצים אלה, אם הם לא ימוזגו לקבצים גדולים יותר, אז מספרם יכול לגדול בצורה משמעותית מאוד. ככל שיותר קבצים כאלה, דרוש יותר זיכרון עבור Thanos Store Gateway, כך נדרשים יותר משאבים להעברת נתונים ברשת ומטא נתונים. Thanos Store Gateway הופך ללא יעיל. לכן, יש צורך להפעיל את Thanos Compact, הממזגת קבצים קטנים לגדולים יותר, כדי שיהיו פחות קבצים כאלה וכדי להפחית את התקורה ב-Thanos Store Gateway.
יש גם רכיב כזה כמו Thanos Ruler. הוא מפעיל כללי התראה של Prometheus ויכול להעריך כללי הקלטה של Prometheus כדי לכתוב נתונים בחזרה ל-Object Storage. אבל לא מומלץ להשתמש ברכיב זה, כי... הוא .
זו התוכנית הפשוטה של תאנוס.
עכשיו בואו נשווה את זה עם ערכת VictoriaMetrics.
ל-VictoriaMetrics יש 2 גרסאות: גרסת צומת יחיד וגרסת אשכול. צומת יחיד פועל על מחשב אחד. לצומת יחיד אין את הרכיבים האלה, רק בינארי אחד. הבינארי הזה בשקופית נראה כמו הריבוע הזה. כל מה שנמצא בתוך הריבוע הוא התוכן של הקובץ הבינארי עבור גרסת ה-Single-node. אתה לא צריך לדעת עליו. אתה פשוט מפעיל את הבינארי והכל עובד בשבילנו.
גרסת האשכול מסובכת יותר. בתוכו ישנם שלושה רכיבים שונים: vmselect, vminsert ו-vmstorage. מהשם שלהם צריך להיות ברור מה כל אחד מהם עושה. רכיב ה-Insert מקבל נתונים בפורמטים שונים: מה-API לכתיבה מרחוק של Prometheus, פרוטוקול Influx line, פרוטוקול Graphite ופרוטוקול OpenTSDB. רכיב ה-Insert מקבל אותם, מנתח אותם ומפיץ אותם בין רכיבי אחסון קיימים, שבהם הנתונים כבר מאוחסנים. הרכיב Select, בתורו, מקבל שאילתות PromQL. הוא מיישם , כמו גם ה-API לשאילתות של Prometheus, והוא יכול לשמש כתחליף ל-Prometheus ב-Grafana או לקוחות אחרים של Prometheus API. Select מקבל בקשת promql, מנתח אותה, קורא את הנתונים הדרושים לביצוע בקשה זו מצמתי אחסון, מעבד נתונים אלה ומחזיר תגובה.
בואו נשווה את המורכבות של התקנת Thanos ו-VictoriaMetrics.
בואו נתחיל עם ת'אנוס. לפני שתתחיל לעבוד עם Thanos, עליך ליצור דלי ב-Object Storage, כגון S3 או GCS, כדי ש-Thanos Sidecar יוכל לכתוב אליו נתונים.
אז עבור כל פרומתאוס אתה צריך להתקין את Thanos Sidecar. לפני כן, עליך לזכור להשבית את דחיסת הנתונים ב-Prometheus. דחיסת נתונים מעת לעת דוחסת נתונים באחסון Prometheus המקומי על מנת להפחית את צריכת המשאבים.
כאשר אתה מתקין את Thanos Sidecar ב-Prometheus שלך, עליך להשבית את הדחסת הנתונים הזו, מכיוון ש-Thanos Sidecar אינו פועל כראוי כאשר דחיסת הנתונים מופעלת. המשמעות היא שה-Prometheus שלך מתחיל לשמור נתונים בבלוקים של שעתיים ומפסיק למזג אותם בלוקים גדולים יותר. בהתאם לכך, אם תבצע שאילתות החורגות מהמשך של השעתיים האחרונות, אז הן לא יפעלו ביעילות כפי שהן יכלו לעבוד אם הדחסת הנתונים הייתה מופעלת.
לכן, Thanos ממליצה לצמצם את זמן שמירת הנתונים באחסון מקומי ל-6-8 שעות על מנת להפחית את התקורה של מספר רב של בלוקים קטנים.
לאחר התקנת Thanos Sidecar, עליך להתקין שני רכיבים עבור כל דלי אחסון אובייקטים. אלה הם Thanos Compactor ו-Thanos Store Gateway.
לאחר מכן, עליך להתקין את Thanos Query ולהגדיר אותה כך שהיא תוכל להתחבר לכל השערים של Thanos Store שיש לך, ויכולה גם להתחבר לכל Thanos Sidecars.
ייתכן שיש כאן בעיה קלה.
עליך להגדיר חיבור אמין ומאובטח מ-Thanos Query לרכיבים אלה. ואם ה-Prometheus שלך ממוקם במרכזי נתונים שונים, או ב-VPCs שונים, אז חיבורים אליהם מבחוץ אסורים. אבל כדי ש-Thanos Query יעבוד, אתה צריך איכשהו להגדיר את החיבור לשם, ואתה צריך למצוא דרך.
אם יש לך הרבה מרכזי נתונים כאלה, אז, בהתאם, האמינות של המערכת כולה פוחתת. מאז Thanos Query חייבת לשמור כל הזמן על קשרים לכל ה-Sidecars של Thanos הממוקמים במרכזי נתונים שונים. עבור כל בקשה נכנסת, הוא ינתב בקשות לכל רכבי הצד של Thanos. אם החיבור יופסק, או שתקבל סט נתונים לא שלם, או שתקבל תגובת "אשכול מנותק".
ב-VictoriaMetrics הכל קצת יותר פשוט. עבור גרסת ה-Single-node, אתה רק צריך להפעיל בינארי אחד והכל עובד.
בגרסת האשכול, מספיק להפעיל את כל שלושת סוגי הרכיבים הנ"ל בכל כמות שתצטרכו, או תשתמשו לאוטומציה של השקת רכיבים ב-Kubernetes. אנחנו גם מתכננים ליצור מפעיל Kubernetes. טבלת ההגה לא מכסה מקרים מסוימים ומאפשרת לך לירות לעצמך ברגל. לדוגמה, זה מאפשר לך להפחית את מספר צמתי האחסון, מה שיוביל לאובדן נתונים.
לאחר שהשקת גרסה בינארית אחת או גרסה מקובצת, אתה רק צריך להוסיף את פרומתאוס לתצורה כך שהוא מתחיל לכתוב נתונים במקביל לאחסון מקומי ואחסון מרוחק. כפי שאתה יכול לראות, תצורה זו אמורה לפעול בצורה אמינה הרבה יותר בהשוואה לתצורת Thanos. אנחנו לא צריכים לשמור על חיבור מ-VictoriaMetrics לכל פרומתאוס, כי פרומתאוס עצמם מתחברים ל-VictoriaMetrics ומשדרים נתונים.
בואו נשקול את התמיכה של Thanos ו-VictoriaMetrics.
Thanos צריך לפקח על Sidecar כדי לוודא שהם לא מפסיקים לטעון נתונים ל-Object Storage. הם עשויים להפסיק את הורדת הנתונים הללו עקב שגיאות הורדה, לדוגמה, חיבור הרשת שלך ל-Object Storage מופרע זמנית, או ש-Object Storage אינו זמין באופן זמני. Thanos Sidecar יבחין בכך ברגע זה, ידווח על שגיאה, עלול לקרוס ואז להפסיק לעבוד. אם לא תפקח עליו, תפסיק להעביר נתונים ל-Object Storage. אם זמן השמירה יעבור (מומלץ 6-8 שעות), אז תאבד נתונים שלא הגיעו ל-Object Storage.
מכבשי Thanos עשויים להפסיק לעבוד עקב . קומפקטורים לוקחים נתונים מאחסון אובייקטים וממזגים אותם לחלקי נתונים גדולים יותר. מכיוון שהקומפקטים אינם מסונכרנים עם Sidecars, עלולים לקרות הדברים הבאים: Sidecar עדיין לא הספיק להשלים את החסימה, קומפאקטור מחליט שבלוק זה נכתב במלואו. קומפקטור מתחיל לקרוא אותו. זה לא קורא את הבלוק במלואו ומפסיק לעבוד. ראה פרטים .
Store Gateway עשוי להחזיר נתונים לא עקביים עקב מירוצים בין Compactor ל-Sidecars. אותו דבר קורה כאן, מכיוון ש- Store Gateway אינו מסונכרן עם מדחסים ו- Sidecars בשום צורה. בהתאם לכך, תנאי מרוץ עשויים להתרחש כאשר שער החנות אינו רואה חלק מהנתונים או רואה נתונים מיותרים.
רכיב השאילתה ב-Thanos כברירת מחדל מחזיר תוצאה חלקית אם חלק מ-Sidecars או Store Gateways אינם זמינים כרגע. תקבלו חלק מהנתונים, ואפילו לא תדעו שלא קיבלתם את כל הנתונים. כך זה עובד כברירת מחדל. במצב דומה, VictoriaMetrics מחזירה נתונים מסומנים כחלקיים.
שלא כמו Thanos, VictoriaMetrics מאבדת נתונים לעתים רחוקות. גם אם החיבור מ-Prometheus ל-VictoriaMetrics נקטע, זו לא בעיה, שכן פרומתאוס ממשיכה לתעד נתונים חדשים נכנסים ב-Write Ahead Log, שגודלו הוא שעתיים. אם תשחזר את החיבור ל-VictoriaMetrics תוך שעתיים, הנתונים שלך לא יאבדו. פרומתאוס .
שלא כמו Thanos, שכותבת נתונים לאחסון אובייקטים רק לאחר שעתיים, Prometheus משכפל אוטומטית נתונים באמצעות פרוטוקול הכתיבה המרוחק לאחסון מרוחק, כגון VictoriaMetrics. אתה לא מפחד לאבד אחסון מקומי בפרומתאוס. אם הוא איבד לפתע אחסון מקומי, אז במקרה הגרוע תאבד את השניות האחרונות של נתונים שלא הספיקו להיקלט באחסון מרוחק.
Kubernetes מנהל אוטומטית את האשכול, שלא כמו Thanos. קשה למקם את כל רכיבי Thanos באשכול Kubernetes אחד, בניגוד לרכיבי אשכול של VictoriaMetrics.
ל-VictoriaMetrics יש עדכון פשוט מאוד לגרסה החדשה. פשוט עצור את VictoriaMetrics, עדכן את הקבצים הבינאריים והפעל אותו. כאשר עוצרים אותם באמצעות אות SIGINT, כל הקבצים הבינאריים של VictoriaMetrics מבצעים כיבוי חינני. הם שומרים בצורה נכונה את הנתונים הדרושים, סוגרים חיבורים נכנסים בצורה נכונה כדי לא לאבד דבר. כך שלא תאבד דבר בעת השדרוג.
VictoriaMetrics מקלה מאוד על הרחבת אשכול. פשוט הוסף את הרכיבים הדרושים והמשך לעבוד.
על המלכודות בת'אנוס וב-VictoriaMetrics.
לתאנוס יש את המלכודות הבאות. פרומתאוס חייב לאחסן נתונים עבור השעתיים האחרונות. אם הם הולכים לאיבוד, אתה תאבד אותם לחלוטין כי הם עדיין לא נכתבו ל-Object Storage כמו S3.
הרכיב Store Gateway ורכיב הדחס יכולים לדרוש זיכרון רב כדי לעבוד עם אחסון אובייקטים גדול אם יש הרבה קבצים קטנים המאוחסנים שם. ככל שמספר הקבצים וגודלם גדולים יותר, כך נדרש יותר זיכרון RAM של Store Gateway ו-Comptor לאחסון מטא-מידע. לתאנוס יש הרבה בעיות בנוגע לעובדה זאת .
Thanos מפורסם בקנה מידה בלתי מוגבל עם כמות הפרומתאוס שיש לך. זה בעצם לא נכון. מכיוון שכל הבקשות עוברות דרך רכיב השאילתה, שעליו לבצע סקר בו-זמנית את כל רכיבי ה- Store Gateway וכל רכיבי Sidecar, משוך משם נתונים ואז מעבד אותם מראש. ברור שמהירות הבקשה מוגבלת על ידי הקישור החלש האיטי ביותר, שער החנות האיטי ביותר או Sidecar האיטי ביותר.
רכיבים אלה עשויים להיות טעונים בצורה לא אחידה. לדוגמה, יש לך פרומתאוס, שאוסף מיליוני מדדים בשנייה. ויש את פרומתאוס, שאוסף אלפי מדדים בשנייה. פרומתאוס, שאוספת מיליוני מדדים בשנייה, מעמיסה עומס הרבה יותר גבוה על השרת שעליו היא פועלת. בהתאם לכך, Sidecar עובד שם לאט יותר. ובכלל הכל עובד שם לאט. ורכיב ה-Query ימשוך משם נתונים לאט מאוד. בהתאם לכך, הביצועים של כל האשכול שלך יוגבלו על ידי Car Sidecar האיטי הזה.
כברירת מחדל, Thanos נותן נתונים חלקיים אם חלק מה-Sidecars או ה- Store Gateway אינם זמינים. לדוגמה, אם ה-Sidecars שלך מפוזרים ברחבי העולם במרכזי נתונים שונים, הסבירות לכשל בחיבור וחוסר זמינות של רכיבים עולה מאוד. בהתאם לכך, ברוב המקרים תקבלו נתונים חלקיים מבלי לדעת זאת.
גם ל-VictoriaMetrics יש מלכודות. המלכודת הראשונה היא האפשרות המגבילה את כמות ה-RAM המשמשת עבור המטמון של VictoriaMetrics. כברירת מחדל, זה שווה ל-60% מזיכרון ה-RAM במחשב שבו פועלת VictoriaMetrics או ל-60% מזיכרון ה-RAM של הפוד של VictoriaMetrics ב-Kubernetes.
אם תשנה ערך זה בצורה שגויה, אתה יכול להרוס את הביצועים של VictoriaMetrics. לדוגמה, אם תגדיר את הערך נמוך מדי, ייתכן שהנתונים לא יתאימו עוד למטמון של VictoriaMetrics. בגלל זה, היא תצטרך לעשות עבודה נוספת ולטעון את המעבד והדיסק. אם אתה הופך את האפשרות הזו לגדולה מדי, זה מגדיל, ראשית, את הסבירות ש-VictoriaMetrics תקרוס עם שגיאת זיכרון אזל, ושנית, זה יוביל לעובדה שיישאר מעט מאוד זיכרון RAM בזיכרון מערכת ההפעלה עבור מטמון קבצים. ו-VictoriaMetrics מסתמכת על מטמון קבצים לביצועים. אם זה לא מספיק, העומס על הדיסק יכול לגדול מאוד. לכן, עצה: אל תשנה את הפרמטר אלא אם כן הכרחי.
אפשרות שניה. זוהי retentionPeriod - תקופה שמוגדרת לחודש אחד כברירת מחדל. זהו משך הזמן שבו VictoriaMetrics מאחסנת נתונים. לאחר תקופה זו, VictoriaMetrics מוחקת את הנתונים.
אנשים רבים מפעילים את VictoriaMetrics ללא הפרמטר הזה ומתעדים נתונים במשך חודש. ואז שואלים: מדוע נעלמו הנתונים של החודש הקודם? כי ברירת המחדל של תקופת השמירה היא חודש אחד. לכן, עליך לדעת ולהגדיר את תקופת השמירה הנכונה.
בואו נסתכל על התכונות הייחודיות.
ל-Thanos יש תכונה הנקראת הורדת דגימה: מרווחים של 5 דקות ושעה, אשר לעתים קרובות . אם תחפשו בגוגל ותסתכלו על הבעיה שלהם ב-github, יש הרבה בעיות שקשורות לדגימה הפחתת הזו, שלפעמים זה לא עובד כמו שצריך, או לא עובד כמו שהמשתמשים מצפים.
ל-Thanos יש מניעת כפילויות של נתונים עבור זוגות HA של פרומתאוס. כאשר שני פרומתאוס אוספים את אותם מדדים מאותם מטרות ות'אנוס מאחסן אותם ב-Object Storage. Thanos יכול לבטל כפילות נתונים אלה כראוי, בניגוד ל-VictoriaMetrics.
ל-Thanos יש רכיב התראה שהיה בסכמטית Thanos. חוץ ממנו .
ל-Thanos יש את היתרון ש-Thanos ו-Prometheus חולקים את אותו קוד. Thanos ו-Prometheus פותחו על ידי אותם מפתחים. עם שיפורים ל-Thanos או Prometheus, הצד השני מנצח.
התכונה העיקרית של VictoriaMetrics היא MetricsQL. אלו הן הרחבות של VictoriaMetrics עבור PromQL, עליהן דיברתי במטאפ הניטור הגדול הקודם.
VictoriaMetrics תומכת בטעינת נתונים באמצעות פרוטוקולים רבים ושונים. VictoriaMetrics יכולה לא רק לקבל נתונים מ-Prometheus, אלא גם באמצעות פרוטוקולי Influx, OpenTSDB ו-Graphite.
נתוני VictoriaMetrics תופסים הרבה פחות מקום בהשוואה ל-Thanos ו-Prometheus.
אם אתה מתעד נתונים אמיתיים, משתמשים מדברים על הפחתה של פי 2-5 בגודל הנתונים בדיסק בהשוואה ל-Prometheus ו-Thanos.
יתרון נוסף של VictoriaMetrics הוא שהיא מותאמת למהירות.
בואו נסתכל על עלות התשתית.
אחד היתרונות של Thanos הוא שהיא מאחסנת נתונים באחסון אובייקטים, שהוא זול יחסית.
בעת אחסון נתונים באחסון אובייקטים, עליך לשלם עבור פעולות כתיבה וקריאה של נתונים ($10 למיליון פעולות). כאשר אתה כותב נתונים לאחסון אובייקטים, אתה משלם את עלויות האירוח שלך עבור העלאת נתונים לאינטרנט; אם האשכול שלך לא נמצא ב-AWS, זה בחינם שם. כשאתה קורא נתונים, אתה משלם בין $10 ל-$230 ל-1TB. זה יכול להיות משמעותי אם אתה מבצע שאילתה תדיר לנתונים היסטוריים מאשכול Thanos.
עבור אשכול Thanos, אתה צריך לשלם עבור שרתים עבור Compact, Store Gateway, רכיבי שאילתה הדורשים זיכרון רב ו-CPU עבור כמויות גדולות של נתונים.
ל-VictoriaMetrics יש את ההוצאות הבאות. אם אתה מאחסן נתונים על כונני GCE HDD, זה יוצא ל-$40 עבור 1TB. עבור VictoriaMetrics, מספיקים כונני HDD רגילים; אין צורך בכונני SSD, שעולים פי חמישה יותר. VictoriaMetrics מותאם עבור HDD.
VictoriaMetrics דורשת שרתים עבור רכיבים: או Single-nod או רכיבים מקובצים, שבניגוד לרכיבי Thanos, דורשים הרבה פחות מעבד ו-RAM - ובהתאם יהיו זולים יותר.
דוגמאות ליישום.
ל-Thanos יש דוגמה ליישום ב-Gitlab. Gitlab פועל כולו על Thanos. אבל לא הכל כל כך חלק שם. אם תסתכל עליהם , אז אתה יכול לראות שיש להם כל הזמן כמה : אין מספיק זיכרון עבור רכיבי Store Gateway או Query. הם צריכים כל הזמן להגדיל את כמות הזיכרון.
בשל כך, העלויות של פתרון בעיות אלו עולות.
היישום השני, שעשוי להיות מוצלח יותר, הוא חברת Improbable, שהחלה לפתח את Thanos. הם פרסמו את קוד המקור של Thanos. Improbable היא חברה שמפתחת מנועי משחק.
ל-VictoriaMetrics יש דוגמאות ליישום ציבורי:
- בונה אתרים wix.com
- אדידס מיישמת את VictoriaMetrics ואף הציגה ב-PromCon 2019 האחרון
- TrafficStars - רשת מודעות
- Seznam.cz הוא מנוע חיפוש צ'כי פופולרי.
ואז היו חברות ללא שם שאני לא יכול למנות עכשיו. הם לא הסכימו.
- מפתח משחק גדול אחד. גדול מבלתי סביר.
- מפתח תוכנה גרפי מרכזי.
- בנק רוסי גדול.
- יצרנית טורבינות רוח אירופית שבדקה בהצלחה את VictoriaMetrics. יצרן זה מיישם את VictoriaMetrics כדי לנטר נתונים שנאספים מטורבינות רוח בקצב של 50 דגימות לשנייה לכל חיישן. לכל טורבינת רוח יש כמה מאות חיישנים. יש להם כמה מאות טורבינות רוח.
- חברות תעופה רוסיות שרוצות ליישם את VictoriaMetrics, אבל עדיין לא יכולות. אנחנו בשלב ההתקשרות איתם.
מסקנות.
VictoriaMetrics ו-Thanos פותרים בעיות דומות, אך בדרכים שונות:
- תצוגת שאילתה גלובלית
- קנה מידה אופקי
- שימור שרירותי
תודה.
מחכים לכם אצלנו .
רק משתמשים רשומים יכולים להשתתף בסקר. בבקשה.
במה אתה משתמש כאחסון לטווח ארוך עבור פרומתאוס?
35,3%Thanos6
0,0%קורטקס0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%אחר4
17 משתמשים הצביעו. 16 משתמשים נמנעו.
מקור: www.habr.com
