Zabbix היא מערכת ניטור. כמו כל מערכת אחרת, היא מתמודדת עם שלוש בעיות עיקריות של כל מערכות הניטור: איסוף ועיבוד נתונים, אחסון היסטוריה וניקיון.
שלבי הקבלה, העיבוד וההקלטה של נתונים לוקחים זמן. לא הרבה, אבל עבור מערכת גדולה זה יכול לגרום לעיכובים גדולים. בעיית האחסון היא בעיית גישה לנתונים. הם משמשים לדוחות, בדיקות וטריגרים. השהיות בגישה לנתונים משפיעות גם על הביצועים. כאשר מסדי נתונים גדלים, יש למחוק נתונים לא רלוונטיים. הסרה היא פעולה קשה שגם גוזלת משאבים מסוימים.
בעיות של עיכובים במהלך איסוף ואחסון ב-Zabix נפתרות על ידי מטמון: מספר סוגי מטמון, מטמון במאגר. כדי לפתור את הבעיה השלישית, מטמון לא מתאים, אז Zabbix השתמש ב-TimescaleDB. הוא יספר לך על זה אנדריי גושצ'ין - מהנדס תמיכה טכנית . אנדריי תומך ב-Zabix כבר יותר מ-6 שנים ויש לו ניסיון ישיר בביצועים.
איך TimescaleDB עובד, אילו ביצועים הוא יכול לתת בהשוואה ל- PostgreSQL רגיל? איזה תפקיד ממלא Zabbix עבור מסד הנתונים TimescaleDB? איך להתחיל מאפס ואיך לעבור מ-PostgreSQL ולאיזו תצורה יש ביצועים טובים יותר? על כל זה מתחת לגזרה.
אתגרי פרודוקטיביות
כל מערכת ניטור מתמודדת עם אתגרי ביצועים ספציפיים. אדבר על שלושה מהם: איסוף ועיבוד נתונים, אחסון וניקוי היסטוריה.
איסוף ועיבוד נתונים מהירים. מערכת ניטור טובה צריכה לקבל במהירות את כל הנתונים ולעבד אותם לפי ביטויי טריגר - לפי הקריטריונים שלה. לאחר העיבוד, על המערכת גם לשמור את הנתונים הללו במהירות במסד הנתונים לשימוש מאוחר יותר.
אחסון היסטוריה. מערכת ניטור טובה צריכה לאחסן היסטוריה במסד נתונים ולספק גישה קלה למדדים. יש צורך בהיסטוריה כדי לשמש בדוחות, גרפים, טריגרים, ספים ופריטי נתוני התראות מחושבים.
ניקוי היסטוריה. לפעמים מגיע יום שבו אתה לא צריך לאחסן מדדים. למה אתה צריך נתונים שנאספו לפני 5 שנים, חודש או חודשיים: חלק מהצמתים נמחקו, חלק מהמארחים או מדדים אינם נחוצים יותר כי הם מיושנים וכבר לא נאספים. מערכת ניטור טובה צריכה לאחסן נתונים היסטוריים ולמחוק אותם מעת לעת כדי שמסד הנתונים לא יגדל.
ניקוי נתונים מיושנים הוא נושא קריטי שמשפיע מאוד על ביצועי מסד הנתונים.
מטמון ב-Zabix
ב-Zabbix, הקריאה הראשונה והשנייה נפתרות באמצעות מטמון. זיכרון RAM משמש לאיסוף ועיבוד נתונים. לאחסון - היסטוריה בטריגרים, גרפים ורכיבי נתונים מחושבים. בצד מסד הנתונים יש קצת מטמון עבור בחירות בסיסיות, למשל, גרפים.
שמירה במטמון בצד שרת Zabbix עצמו היא:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
שקול אותם בפירוט רב יותר.
ConfigurationCache
זהו המטמון הראשי שבו אנו מאחסנים מדדים, מארחים, פריטי נתונים, טריגרים - כל מה שאנו צריכים עבור PreProcessing ולאיסוף נתונים.
כל זה מאוחסן ב-ConfigurationCache כדי לא ליצור שאילתות מיותרות במסד הנתונים. לאחר הפעלת השרת, אנו מעדכנים את המטמון הזה, יוצרים ומעדכנים מדי פעם תצורות.
איסוף נתונים
התרשים הוא די גדול, אבל העיקר בו הוא קוטפים. מדובר ב"פולרים" שונים - תהליכי הרכבה. הם אחראים על סוגים שונים של הרכבה: הם אוספים נתונים באמצעות SNMP, IPMI, ומעבירים את הכל ל-PreProcessing.
האספנים מסומנים בכתום.
Zabbix חישבה פריטי צבירה הדרושים לצבירה של צ'קים. אם יש לנו אותם, אנחנו מביאים את הנתונים עבורם ישירות מה-ValueCache.
PreProcessing HistoryCache
כל האספנים משתמשים ב-ConfigurationCache כדי לקבל עבודות. ואז הם מעבירים אותם ל-PreProcessing.
PreProcessing משתמש ב-ConfigurationCache כדי לקבל שלבי PreProcessing. הוא מעבד את הנתונים הללו בדרכים שונות.
לאחר עיבוד הנתונים באמצעות PreProcessing, אנו שומרים אותם ב- HistoryCache לעיבוד. בכך מסתיים איסוף הנתונים ואנחנו עוברים לתהליך הראשי ב-Zabix - סנכרון היסטוריה, שכן מדובר בארכיטקטורה מונוליטית.
הערה: עיבוד מוקדם היא פעולה די קשה. עם v 4.2 זה הועבר ל-proxy. אם יש לך Zabbix גדול מאוד עם מספר רב של רכיבי נתונים ותדירות איסוף, אז זה מקל בהרבה על העבודה.
מטמון ValueCache, היסטוריה ומגמות
סינכרון היסטוריה הוא התהליך העיקרי שמעבד באופן אטומי כל אלמנט נתונים, כלומר כל ערך.
סינכרון ההיסטוריה לוקח ערכים מ- HistoryCache ובודק את התצורה עבור נוכחות של טריגרים לחישובים. אם הם קיימים, זה מחושב.
סינכרון ההיסטוריה יוצר אירוע, הסלמה ליצירת התראות אם נדרש על ידי התצורה ורשומות. אם יש טריגרים לעיבוד עוקב, אז הוא מאחסן את הערך הזה ב-ValueCache כדי לא לגשת לטבלת ההיסטוריה. כך מתמלא ValueCache בנתונים הדרושים לחישוב טריגרים ואלמנטים מחושבים.
סינכרון ההיסטוריה כותב את כל הנתונים למסד הנתונים, והוא כותב לדיסק. תהליך העיבוד מסתיים כאן.
שמירה במטמון במסד הנתונים
בצד מסד הנתונים ישנם מטמונים שונים כאשר אתה רוצה להציג גרפים או דוחות על אירועים:
Innodb_buffer_poolבצד MySQL;shared_buffersבצד PostgreSQL;effective_cache_sizeבצד של אורקל;shared_poolבצד DB2.
ישנם מטמונים רבים אחרים, אך אלו הם העיקריים עבור כל מסדי הנתונים. הם מאפשרים לך לאחסן נתונים ב-RAM הנחוצים לעתים קרובות עבור שאילתות. יש להם טכנולוגיות משלהם בשביל זה.
ביצועי מסד נתונים הם קריטיים
שרת Zabbix כל הזמן אוסף נתונים וכותב אותם. כאשר הוא מופעל מחדש, הוא גם קורא מההיסטוריה כדי למלא את ValueCache. משתמש בסקריפטים ודוחות API של Zabbix, אשר בנוי על ממשק אינטרנט. Zabbix API ניגש למסד הנתונים ומחזיר את הנתונים הדרושים עבור גרפים, דוחות, רשימות אירועים ובעיות אחרונות.
להדמיה - גרפנה. זהו פתרון פופולרי בקרב המשתמשים שלנו. הוא יכול לשלוח בקשות ישירות דרך ה-API של Zabbix ולבסיס הנתונים, ויוצר תחרות מסוימת על קבלת נתונים. לכן, יש צורך בכוונון עדין וטוב יותר של מסד הנתונים כדי להתאים למסירה המהירה של התוצאות והבדיקות.
מנהלת משק בית
אתגר הביצועים השלישי ב-Zabix הוא ניקוי היסטוריה באמצעות Housekeeper. זה עוקב אחר כל ההגדרות - רכיבי הנתונים מציינים כמה זמן לאחסן את הדינמיקה של שינויים (מגמות) בימים.
אנו מחשבים את TrendsCache תוך כדי תנועה. כאשר הנתונים מגיעים, אנו אוספים אותם למשך שעה אחת ורושמים אותם בטבלאות עבור הדינמיקה של שינויי מגמה.
עוזרת הבית מתחילה ומוחקת מידע ממסד הנתונים באמצעות ה"בחירה" הרגילה. זה לא תמיד יעיל, כפי שניתן לראות מגרפים של ביצועים של תהליכים פנימיים.
הגרף האדום מראה שמסנכרן ההיסטוריה עסוק כל הזמן. הגרף הכתום בחלק העליון הוא Housekeeper, שפועל ללא הרף. הוא ממתין למסד הנתונים כדי למחוק את כל השורות שהוא ציין.
מתי כדאי להשבית את עוזרת הבית? לדוגמה, יש "מזהה פריט" ואתה צריך למחוק את 5 השורות האחרונות בתוך זמן מסוים. כמובן שזה קורה לפי מדד. אבל בדרך כלל מערך הנתונים גדול מאוד, ומסד הנתונים עדיין קורא מהדיסק ומכניס אותו למטמון. זו תמיד פעולה מאוד יקרה עבור בסיס הנתונים ובהתאם לגודל בסיס הנתונים, עלולה להוביל לבעיות ביצועים.
עוזרת בית קלה להשבית. בממשק האינטרנט יש הגדרה ב"ניהול כללי" עבור עוזרת בית. אנו משביתים את ניהול הבית הפנימי עבור היסטוריית מגמות פנימית והיא כבר לא מנהלת את זה.
עוזרת הבית כבתה, הגרפים התיישרו - אילו בעיות יכולות להיות במקרה הזה ומה יכול לעזור לפתור את אתגר הביצועים השלישי?
חלוקה - חלוקה או חלוקה
בדרך כלל, חלוקה למחיצות מוגדרת בצורה שונה בכל מסד נתונים יחסי שרשמתי. לכל אחד יש טכנולוגיה משלו, אבל הם דומים באופן כללי. יצירת מחיצה חדשה מובילה לעתים קרובות לבעיות מסוימות.
בדרך כלל, מחיצות מוגדרות בהתאם ל"התקנה" - כמות הנתונים שנוצרת ביום אחד. ככלל, מחיצה מונפקת ביום אחד, זה המינימום. לטרנדים של אצווה חדשה - חודש אחד.
הערכים עשויים להשתנות אם "ההגדרה" גדולה מאוד. אם "הגדרה" קטנה היא עד 5 nvps (ערכים חדשים לשנייה), בינונית היא מ-000 עד 5, אז גדול הוא מעל 000 nvps. מדובר בהתקנות גדולות וגדולות מאוד הדורשות הגדרה קפדנית של מסד הנתונים.
בהתקנות גדולות מאוד, פרק זמן של יום אחד עשוי להיות לא אופטימלי. ראיתי מחיצות MySQL של 40 GB או יותר ליום. מדובר בכמות גדולה מאוד של נתונים שעלולה לגרום לבעיות וצריך לצמצם.
מה נותנת החלוקה?
טבלאות מחיצות. לרוב מדובר בקבצים נפרדים בדיסק. תוכנית השאילתות בוחרת מחיצה אחת בצורה אופטימלית יותר. בדרך כלל משתמשים במחיצות לפי טווח - זה נכון גם עבור Zabbix. אנו משתמשים שם ב"חותמת זמן" - זמן מאז תחילת העידן. אלו מספרים רגילים עבורנו. אתה קובע את ההתחלה והסוף של היום - זו מחיצה.
הסרה מהירה - DELETE. נבחר קובץ/טבלת משנה אחד, במקום מבחר שורות למחיקה.
מאיץ באופן משמעותי את אחזור הנתונים SELECT - משתמש במחיצה אחת או יותר, במקום בכל הטבלה. אם אתה ניגש לנתונים בני יומיים, הם מאוחזרים מהמסד מהר יותר מכיוון שאתה צריך רק לטעון קובץ אחד למטמון ולהחזיר אותו, לא טבלה גדולה.
לעתים קרובות גם מאגרי מידע רבים מואצים INSERT - כניסות לטבלת הילד.
טווח זמנים DB
עבור גרסה 4.2, הפנינו את תשומת לבנו ל-TimescaleDB. זוהי הרחבה עבור PostgreSQL עם ממשק מקורי. ההרחבה עובדת ביעילות עם נתוני סדרות זמן, מבלי לאבד את היתרונות של מסדי נתונים יחסיים. TimescaleDB גם מחיצה אוטומטית.
ל-TimescaleDB יש מושג hypertable (היפרטי) שאתה יוצר. זה מכיל נתחים - מחיצות. נתחים הם קטעי היפרטבל מנוהלים אוטומטית שאינם משפיעים על קטעים אחרים. לכל נתח יש טווח זמן משלו.
TimescaleDB לעומת PostgreSQL
TimescaleDB עובד ביעילות רבה. יצרני התוסף טוענים שהם משתמשים באלגוריתם נכון יותר של עיבוד שאילתות, במיוחד inserts . ככל שגודל התוספת של מערך הנתונים גדל, האלגוריתם שומר על ביצועים קבועים.
לאחר 200 מיליון שורות, PostgreSQL בדרך כלל מתחיל לצנוח משמעותית ומאבד ביצועים ל-0. TimescaleDB מאפשר לך להכניס ביעילות "תוספות" לכל כמות נתונים.
התקנה
התקנת TimescaleDB קלה למדי עבור כל חבילה. IN הכל מתואר בפירוט - זה תלוי בחבילות PostgreSQL הרשמיות. TimescaleDB ניתן גם לבנות ולהרכיב באופן ידני.
עבור מסד הנתונים של Zabbix אנו פשוט מפעילים את התוסף:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
אתה מפעיל extension וליצור אותו עבור מסד הנתונים Zabbix. השלב האחרון הוא יצירת היפרטבל.
העברת טבלאות היסטוריה ל-TimescaleDB
יש פונקציה מיוחדת לכך create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
לפונקציה שלושה פרמטרים. ראשון - טבלה במסד הנתונים, שעבורו אתה צריך ליצור היפרטבל. שנית - שדה, לפיו אתה צריך ליצור chunk_time_interval - מרווח של נתחי מחיצה לשימוש. במקרה שלי, המרווח הוא יום אחד - 86.
פרמטר שלישי - migrate_data. אם תגדיר true, אז כל הנתונים הנוכחיים מועברים לנתחים שנוצרו מראש. השתמשתי בזה בעצמי migrate_data. היה לי בערך 1 TB, שלקח יותר משעה. אפילו במקרים מסוימים, במהלך הבדיקה, מחקתי נתונים היסטוריים של סוגי תווים שלא נדרשו לאחסון, כדי לא להעביר אותם.
צעד אחרון - UPDATE: ב db_extension לָשִׂים timescaledbכך שמסד הנתונים יבין שההרחבה הזו קיימת. Zabbix מפעילה אותו ומשתמשת נכון בתחביר ובשאילתות למסד הנתונים - אותן תכונות הנחוצות ל-TimescaleDB.
תצורת חומרה
השתמשתי בשני שרתים. ראשון - מכונת VMware. הוא די קטן: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz מעבדים, 16 GB של זיכרון RAM ו-200 GB SSD.
התקנתי עליו PostgreSQL 10.8 עם Debian 10.8-1.pgdg90+1 OS ומערכת הקבצים xfs. הגדרתי הכל באופן מינימלי לשימוש במסד הנתונים המסוים הזה, פחות מה Zabbix עצמה תשתמש.
על אותה מכונה היה שרת Zabbix, PostgreSQL ו סוכני עומס. היו לי 50 סוכנים פעילים שהשתמשו בהם LoadableModuleכדי ליצור במהירות רבה תוצאות שונות: מספרים, מחרוזות. מילאתי את מסד הנתונים בהרבה נתונים.
בתחילה התצורה הכילה 5 אלמנטים נתונים לכל מארח. כמעט כל אלמנט הכיל טריגר כדי להפוך אותו לדומה למתקנים אמיתיים. בחלק מהמקרים היה יותר מטריגר אחד. עבור צומת רשת אחד היו 3-000 טריגרים.
מרווח עדכון פריט נתונים - 4-7 שניות. הסדרתי את העומס עצמו על ידי שימוש לא רק ב-50 סוכנים, אלא הוספתי עוד. כמו כן, באמצעות רכיבי נתונים, כיוונתי באופן דינמי את העומס והקטנתי את מרווח העדכון ל-4 שניות.
PostgreSQL. 35 nvps
הריצה הראשונה שלי על החומרה הזו הייתה על PostgreSQL טהור - 35 אלף ערכים לשנייה. כפי שניתן לראות, הכנסת נתונים אורכת שברירי שנייה - הכל טוב ומהיר. הדבר היחיד הוא שדיסק SSD בנפח 200 גיגה-בייט מתמלא במהירות.
זהו לוח מחוונים סטנדרטי לביצועי שרת Zabbix.
הגרף הכחול הראשון הוא מספר הערכים בשנייה. הגרף השני מימין הוא טעינת תהליכי הבנייה. השלישי הוא טעינת תהליכי בנייה פנימיים: מסנכרני היסטוריה ו-Housekeeper, שפועל כאן די הרבה זמן.
הגרף הרביעי מציג את השימוש HistoryCache. זהו סוג של מאגר לפני הכנסתו למסד הנתונים. הגרף החמישי הירוק מציג את השימוש ב-ValueCache, כלומר, כמה כניסות של ValueCache לטריגרים - זה כמה אלפי ערכים בשנייה.
PostgreSQL. 50 nvps
ואז העליתי את העומס ל-50 אלף ערכים לשנייה על אותה חומרה.
בעת הטעינה מבית עוזרת הבית, הכנסת 10 אלף ערכים ארכה 2-3 שניות.
עוזרת הבית כבר מתחילה להפריע לעבודה.
הגרף השלישי מראה שבאופן כללי, העומס על הלוכדים ומסנכרני ההיסטוריה עדיין עומד על 60%. בגרף הרביעי, HistoryCache כבר מתחיל להתמלא די פעיל במהלך פעולת Housekeeper. הוא מלא ב-20%, שהם בערך 0,5 GB.
PostgreSQL. 80 nvps
ואז הגדלתי את העומס ל-80 אלף ערכים לשנייה. מדובר בכ-400 אלף רכיבי נתונים ו-280 אלף טריגרים.
עלות הטעינה של שלושים מסנכרני היסטוריה כבר די גבוהה.
כמו כן, הגדלתי פרמטרים שונים: סינכרי היסטוריה, מטמונים.
בחומרה שלי, הטעינה של מסנכרני היסטוריה עלתה למקסימום. HistoryCache התמלא במהירות בנתונים - נתונים לעיבוד הצטברו במאגר.
כל הזמן הזה ראיתי איך נעשה שימוש במעבד, בזיכרון RAM ובפרמטרים נוספים של המערכת, וגיליתי שניצול הדיסק היה מקסימלי.
השגתי את השימוש יכולות דיסק מקסימליות על החומרה הזו ועל המחשב הווירטואלי הזה. בעוצמה כזו, PostgreSQL החל לשטוף נתונים די פעיל, ולדיסק כבר לא היה זמן לכתוב ולקרוא.
שרת שני
לקחתי שרת אחר, שכבר היו בו 48 מעבדים ו-128 גיגה-בייט של זיכרון RAM. כיוונתי אותו - הגדרתי אותו לסינכרון היסטוריה 60, והשגתי ביצועים מקובלים.
למעשה, זה כבר גבול הפרודוקטיביות שבו צריך לעשות משהו.
TimescaleDB. 80 nvps
המשימה העיקרית שלי היא לבדוק את היכולות של TimescaleDB מול עומס Zabbix. 80 אלף ערכים לשנייה זה הרבה, תדירות איסוף המדדים (למעט Yandex, כמובן) ו"התקנה" גדולה למדי.
יש צניחה בכל גרף - זו בדיוק העברת הנתונים. לאחר כשלים בשרת Zabbix, פרופיל הטעינה של סינכרון ההיסטוריה השתנה מאוד - הוא ירד שלוש פעמים.
TimescaleDB מאפשר לך להכניס נתונים כמעט פי 3 מהר יותר ולהשתמש בפחות HistoryCache.
בהתאם לכך, תקבלו נתונים בזמן.
TimescaleDB. 120 nvps
לאחר מכן הגדלתי את מספר רכיבי הנתונים ל-500 אלף. המשימה העיקרית הייתה לבדוק את היכולות של TimescaleDB - קיבלתי ערך מחושב של 125 אלף ערכים לשנייה.
זהו "התקנה" עובדת שיכולה לעבוד לאורך זמן. אבל מכיוון שהדיסק שלי היה רק 1,5 TB, מילאתי אותו תוך כמה ימים.
הדבר החשוב ביותר הוא שבמקביל נוצרו מחיצות TimescaleDB חדשות.
זה לגמרי לא מורגש מבחינת הביצועים. כשיוצרים מחיצות ב-MySQL, למשל, הכל שונה. זה קורה בדרך כלל בלילה מכיוון שהוא חוסם הכנסה כללית, עובד עם טבלאות ויכול ליצור פגיעה בשירות. זה לא המקרה עם TimescaleDB.
כדוגמה, אראה גרף אחד מרבים בקהילה. בתמונה, TimescaleDB מופעל, שבזכותו ירד העומס על השימוש ב-io.weight על המעבד. גם השימוש במרכיבי תהליך פנימיים ירד. יתרה מכך, מדובר במכונה וירטואלית רגילה על דיסקים פנקייקים רגילים, לא ב-SSD.
ממצאים
TimescaleDB הוא פתרון טוב ל"התקנה" קטנה, אשר משפיעים על ביצועי הדיסק. זה יאפשר לך להמשיך לעבוד היטב עד שבסיס הנתונים יועבר לחומרה במהירות האפשרית.
TimescaleDB קל להגדרה, נותן שיפורי ביצועים, עובד היטב עם Zabbix ו יש יתרונות על פני PostgreSQL.
אם אתה משתמש ב-PostgreSQL ולא מתכוון לשנות אותו, אני ממליץ השתמש ב-PostgreSQL עם סיומת TimescaleDB בשילוב עם Zabbix. פתרון זה עובד ביעילות עד ל"הגדרה" בינונית.
כשאנחנו אומרים "ביצועים גבוהים" אנחנו מתכוונים . לא תצטרך לחכות זמן רב כדי ללמוד על הטכנולוגיות והפרקטיקות המאפשרות לשירותים לשרת מיליוני משתמשים. רשימה עבור 7 ו-8 בנובמבר כבר אספנו, אבל כאן ניתן להציע יותר.
הירשמו לנו и , בו אנו חושפים את המאפיינים של הכנס הקרוב, ומגלים כיצד להפיק ממנו את המרב.
מקור: www.habr.com