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

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

בעיות גרפיט+לחישה

1. עומס גבוה על תת-מערכת הדיסק

בזמן המעבר, כ-1.5 מיליון מדדים הגיעו אלינו לדקה. עם זרימה כזו, ניצול הדיסק בשרתים היה ~30%. באופן כללי, זה היה די מקובל - הכל עבד ביציבות, נכתב מהר, קרא במהירות... עד שאחד מצוותי הפיתוח הוציא פיצ'ר חדש והתחיל לשלוח לנו 10 מיליון מדדים לדקה. זה הזמן שבו תת-מערכת הדיסק התהדקה, וראינו ניצול של 100%. הבעיה נפתרה במהירות, אך נשארה שארית.

2. חוסר שכפול ועקביות

סביר להניח שכמו כל מי שמשתמש/השתמש ב-Graphite+Whisper, שפכנו את אותו זרם של מדדים על מספר שרתי גרפיט בו זמנית על מנת ליצור סובלנות לתקלות. ולא היו עם זה בעיות מיוחדות - עד לרגע שבו אחד השרתים קרס מסיבה כלשהי. לפעמים הצלחנו לקלוט שרת שנפל מספיק מהר, ו-carbon-c-relay הצליח לטעון לתוכו מדדים מהמטמון שלו, אבל לפעמים לא. ואז היה חור במדדים, שמילאנו ב-rsync. ההליך היה ארוך למדי. החסד המציל היחיד היה שזה קרה לעתים רחוקות מאוד. כמו כן לקחנו מדי פעם קבוצה אקראית של מדדים והשווינו אותם עם אחרים מאותו סוג בצמתים שכנים של האשכול. בכ-5% מהמקרים, כמה ערכים היו שונים, מה שלא היינו מאוד מרוצים מהם.

3. טביעת רגל גדולה

מכיוון שאנו כותבים ב-Graphite לא רק תשתית, אלא גם מדדים עסקיים (ועכשיו גם מדדים מ-Kubernetes), לא פעם אנו מקבלים מצב בו המדד מכיל רק כמה ערכים, וקובץ ה-wsp נוצר תוך התחשבות בכל השמירה תקופה, ותופס כמות מקום שהוקצה מראש, שעבורנו היה ~2MB. הבעיה מחמירה עוד יותר מכך שהרבה קבצים דומים מופיעים עם הזמן, וכאשר בונים עליהם דוחות, קריאת נקודות ריקות גוזלת זמן ומשאבים רבים.

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

עם כל האמור לעיל (בהתחשב בקודם מאמרים), כמו גם עלייה מתמדת במספר המדדים שהתקבלו, הרצון להעביר את כל המדדים למרווח אחסון של 30 שניות. (עד 10 שניות במידת הצורך), החלטנו לנסות את Graphite+ClickHouse כחלופה מבטיחה ל- Whisper.

גרפיט+קליקהאוס. ציפיות

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

ברצוני לקבל את הדברים הבאים:

• להפחית את ניצול תת-מערכת הדיסק מ-30% ל-5%;
• להפחית את כמות השטח התפוסה מ-1TB ל-100GB;
• להיות מסוגל לקבל 100 מיליון מדדים לדקה לתוך השרת;
• שכפול נתונים וסובלנות תקלות מחוץ לקופסה;
• אל תשב על הפרויקט הזה במשך שנה ותעשה את המעבר בתוך מסגרת זמן סבירה;
• מתג ללא זמן השבתה.

די שאפתני, נכון?

גרפיט+קליקהאוס. רכיבים

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

המהדורה האחרונה של ClickHouse, גרסה יציבה 1.1.54253, נבחרה כמסד הנתונים לאחסון סדרות זמן. היו בעיות בעבודה עם זה: הר של שגיאות נשפך לתוך היומנים, ולא היה ברור לגמרי מה לעשות איתן. בדיון עם רומן לומונוסוב (מחבר carbon-clickhouse, graphite-clickhouse ורבים רבים נוספים) המבוגר יותר נבחר גרסה 1.1.54236. השגיאות נעלמו - הכל התחיל לעבוד ברעש גדול.

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

גרפיט+קליקהאוס. מבנה השולחן

"גרפיט" הוא מסד נתונים שיצרנו לניטור טבלאות.

"graphite.metrics" - טבלה עם מנוע ReplicatedReplacingMergeTree (משוכפל מחליףMergeTree). טבלה זו מאחסנת את שמות המדדים והנתיבים אליהם.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

"graphite.data" - טבלה עם מנוע ReplicatedGraphiteMergeTree (משוכפל GraphiteMergeTree). טבלה זו מאחסנת ערכי מדדים.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

"graphite.date_metrics" היא טבלה עם מילוי מותנה עם מנוע ReplicatedReplacingMergeTree. טבלה זו מתעדת את השמות של כל המדדים שנתקלו במהלך היום. הסיבות ליצירתו מתוארות בסעיף "בעיות" בסוף מאמר זה.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

"graphite.data_stat" - טבלה שמולאה בהתאם לתנאי, עם מנוע ReplicatedAggregatingMergeTree (משוכפל צבירהMergeTree). טבלה זו מתעדת את מספר המדדים הנכנסים, בחלוקה ל-4 רמות קינון.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

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

גרפיט+קליקהאוס. העברת נתונים

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

• כלל נוסף ל-carbon-c-relay כדי לשלוח זרם נוסף של מדדים ל-carbon-clickhouse של אחד השרתים המשתתפים בשכפול של טבלאות ClickHouse.

• כתבנו סקריפט קטן ב-python, שבאמצעות ספריית whisper-dump, קרא את כל קבצי ה-wsp מהאחסון שלנו ושלחנו את הנתונים האלה ל-carbon-clickhouse המתואר לעיל ב-24 שרשורים. מספר הערכים המטריים המקובלים ב-carbon-clickhouse הגיע ל-125 מיליון לדקה, ו-ClickHouse אפילו לא הזיעה.

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

• כדי להחליף את עומס הקריאה בהגדרות האיזון, שינינו את נקודות הקצה מ-graphite-api (ממשק API עבור Graphite+Whisper) ל-carbonapi.

גרפיט+קליקהאוס. תוצאות

• הפחתת ניצול תת-מערכת הדיסק מ-30% ל-1%;

  

• הפחית את כמות השטח התפוסה מ-1 TB ל-300 GB;
• יש לנו את היכולת לקבל 125 מיליון מדדים לדקה לתוך השרת (שיאים בזמן ההגירה);
• העביר את כל המדדים למרווח אחסון של שלושים שניות;
• שכפול נתונים שהתקבלו וסובלנות תקלות;
• התחלף ללא זמן השבתה;
• זה לקח בערך 7 שבועות כדי להשלים הכל.

גרפיט+קליקהאוס. בעיות

במקרה שלנו, היו כמה מלכודות. זה מה שנתקלנו בו לאחר המעבר.

1. ClickHouse לא תמיד קורא מחדש הגדרות תוך כדי תנועה; לפעמים צריך לאתחל אותו מחדש. לדוגמה, במקרה של התיאור של אשכול שומר גן החיות בתצורת ClickHouse, לא נעשה בו שימוש עד שה-Clickhouse-שרת אותחל מחדש.
2. בקשות גדולות של ClickHouse לא עברו, אז ב-graphite-clickhouse מחרוזת החיבור שלנו ל-ClickHouse נראית כך:

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. ClickHouse משחררת לעתים קרובות גרסאות חדשות של מהדורות יציבות; הן עשויות להכיל הפתעות: היזהר.
4. קונטיינרים שנוצרו באופן דינמי ב-kubernetes שולחים מספר רב של מדדים עם אורך חיים קצר ואקראי. אין הרבה נקודות למדדים כאלה, ואין בעיות עם שטח. אבל בעת בניית שאילתות, ClickHouse קולט מספר עצום של אותם מדדים מטבלת ה'מדדים'. ב-90% מהמקרים אין נתונים עליהם מעבר לחלון (24 שעות). אבל הזמן מושקע בחיפוש אחר הנתונים האלה בטבלת 'נתונים', ובסופו של דבר נתקל בפסק זמן. על מנת לפתור בעיה זו, התחלנו לשמור על תצוגה נפרדת עם מידע על מדדים שנתקלו בהם במהלך היום. לפיכך, בעת בניית דוחות (גרפים) עבור קונטיינרים שנוצרו באופן דינמי, אנו מבצעים שאילתות רק לאותם מדדים שנתקלו בחלון נתון, ולא במשך כל הזמן, מה שהאיץ משמעותית את בניית הדוחות עליהם. עבור הפתרון המתואר לעיל, אספתי גרפיט-קליק האוס (מזלג), הכולל הטמעת עבודה עם טבלת date_metrics.

גרפיט+קליקהאוס. תגים

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

גרפיט+קליקהאוס. גלאי אנומליות

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

הירשם, לחץ על החץ למעלה והיה מאושר!

מקור: www.habr.com