HighLoad++, Mikhail Makurov, Maxim Chernetsov (Intersvyaz): Zabbix, 100kNVPS בשרת אחד

כנס HighLoad++ הבא יתקיים ב-6 וב-7 באפריל 2020 בסנט פטרסבורג פרטים וכרטיסים по ссылке. HighLoad++ מוסקבה 2018. אולם "מוסקבה". 9 בנובמבר, 15:00. תזות ו הצגה.

* ניטור - אונליין ואנליטיקה.
* מגבלות בסיסיות של פלטפורמת ZABBIX.
* פתרון להגדלת אחסון האנליטיקה.
* אופטימיזציה של שרת ZABBIX.
* אופטימיזציה של ממשק המשתמש.
* ניסיון בהפעלת המערכת בעומסים של יותר מ-40k NVPS.
* מסקנות קצרות.

מיכאיל מקורוב (להלן – מ"מ): - שלום לכולם!

מקסים צ'רנצוב (להלן – MCH): - אחר הצהריים טובים!

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

MCH: – ואני רוצה לספר לך על מיכאיל. מיכאיל הוא מפתח C. הוא כתב כמה פתרונות לעיבוד תעבורה בעומס גבוה עבור החברה שלנו. אנחנו חיים ועובדים ב-Ural, בעיר של גברים קשוחים צ'ליאבינסק, בחברת Intersvyaz. החברה שלנו היא ספקית של שירותי אינטרנט וטלוויזיה בכבלים למיליון איש ב-16 ערים.

מ"מ: - וכדאי לומר ש-Intersvyaz היא הרבה יותר מסתם ספק, היא חברת IT. רוב הפתרונות שלנו מיוצרים על ידי מחלקת ה-IT שלנו.

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

על Zabbix והארכיטקטורה שלו

MCH: - ועכשיו אנסה לקבוע שיא אישי ולומר תוך דקה מה זה זאביקס (להלן "זאביקס").

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

בקצרה על אדריכלות. אנו יכולים לומר שהוא מורכב משלושה מרכיבים:

• שרת. כתוב ב-C. עם עיבוד והעברת מידע מורכבים למדי בין שרשורים. כל העיבוד מתבצע בו: מהקבלה ועד השמירה למסד הנתונים.
• כל הנתונים מאוחסנים במסד הנתונים. Zabbix תומך ב-MySQL, PostreSQL ו-Oracle.
• ממשק האינטרנט כתוב ב-PHP. ברוב המערכות הוא מגיע עם שרת Apache, אבל עובד בצורה יעילה יותר בשילוב עם nginx + php.

היום ברצוננו לספר סיפור אחד מחיי החברה שלנו הקשור ל-Zabix...

סיפור מחייה של חברת אינטרסוויאז. מה יש לנו ומה אנחנו צריכים?

לפני 5 או 6 חודשים. יום אחד אחרי העבודה...

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

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

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

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

MCH: - הדבר הראשון שאתה צריך להתמודד איתו הוא מסד הנתונים. MySQL נטען כל הזמן, מאחסן מדדים חדשים, וכאשר Zabbix מתחיל להפיק חבורה של אירועים, מסד הנתונים נכנס להילוך יתר לכמה שעות. כבר סיפרתי לכם על אופטימיזציה של התצורה, אבל ממש השנה הם עדכנו את החומרה: לשרתים יש יותר ממאה גיגה-בייט של זיכרון ומערכי דיסקים ב-SSD RAIDs – אין טעם לגדל את זה ליניארי בטווח הארוך. מה אנחנו עושים?

מ"מ: - זה ברור. באופן כללי, MySQL הוא מסד נתונים של LTP. ככל הנראה, הוא כבר לא מתאים לאחסון ארכיון של מדדים בגודל שלנו. בוא נבין את זה.

MCH: - בואו!

שילוב של Zabbix ו- Clickhouse כתוצאה מההאקתון

לאחר זמן מה קיבלנו נתונים מעניינים:

רוב השטח במסד הנתונים שלנו נכבש על ידי ארכיון המדדים ופחות מ-1% שימש עבור תצורה, תבניות והגדרות. עד אז כבר הפעלנו את פתרון Big Data המבוסס על Clickhouse במשך יותר משנה. כיוון התנועה היה ברור לנו. בהאקתון האביב שלנו, כתבתי את השילוב של Zabbix עם Clickhouse עבור השרת והחזית. באותו זמן, ל-Zabix כבר הייתה תמיכה ב-ElasticSearch, והחלטנו להשוות ביניהם.

השוואה בין Clickhouse ו- Elasticsearch

מ"מ: – לשם השוואה, יצרנו עומס זהה לזה ששרת Zabbix מספק ובדקנו איך המערכות יתנהגו. כתבנו נתונים באצוות של 1000 שורות, באמצעות CURL. הנחנו מראש שקליקהאוס יהיה יעיל יותר עבור פרופיל העומס שעושה Zabbix. התוצאות אפילו עלו על הציפיות שלנו:

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

בסך הכל, Clickhouse הייתה עדיפה משמעותית על Elastix מבחינת צריכת מעבד ומהירות. יחד עם זאת, עקב דחיסת נתונים, Clickhouse משתמש פי 11 פחות בכונן הקשיח ומבצע בערך פי 30 פחות פעולות דיסק:

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

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

הקלנו על מסד הנתונים הראשי של MySQL עד כדי כך שיכולנו לשלב אותו במכונה אחת עם שרת Zabbix ולנטוש את השרת הייעודי ל-MySQL.

איך עובד הסקרים בזאביקס?

חודשים לפני 4

מ"מ: – נו, נוכל לשכוח מהבעיות בבסיס?

MCH: - זה בטוח! בעיה נוספת שעלינו לפתור היא איסוף נתונים איטי. כעת כל 15 שרתי ה-proxy שלנו עמוסים בתהליכי SNMP וסקר. ואין דרך מלבד להתקין שרתים חדשים וחדשים.

מ"מ: - גדול. אבל קודם כל, ספר לנו איך עובד הסקרים ב-Zabix?

MCH: – בקיצור, יש 20 סוגי מדדים ותריסר דרכים להשיג אותם. Zabbix יכולה לאסוף נתונים במצב "תגובה לבקשה", או להמתין לנתונים חדשים דרך "ממשק ה-Trapper".

ראוי לציין שבזאביקס המקורי שיטה זו (Trapper) היא המהירה ביותר.

ישנם שרתי פרוקסי להפצת עומסים:

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

מ"מ: - הכל ברור עם אדריכלות. צריך להסתכל על המקורות...

כעבור יומיים

הסיפור של איך nmap fping ניצחה

מ"מ: "אני חושב שחפרתי משהו."

MCH: - תגיד לי!

מ"מ: – גיליתי שכאשר בודקים זמינות, Zabbix בודק לכל היותר 128 מארחים בכל פעם. ניסיתי להגדיל את המספר הזה ל-500 ולהסיר את מרווח המנות בין המנות בפינג (פינג) שלהם - זה הכפיל את הביצועים. אבל אני רוצה מספרים גדולים יותר.

MCH: – בתרגול שלי, אני צריך לפעמים לבדוק את הזמינות של אלפי מארחים, ומעולם לא ראיתי משהו מהיר יותר מ-nmap בשביל זה. אני בטוח שזו הדרך המהירה ביותר. בואו ננסה את זה! אנחנו צריכים להגדיל משמעותית את מספר המארחים לכל איטרציה.

מ"מ: – לבדוק יותר מחמש מאות? 600?

MCH: לפחות כמה אלפים.

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

MCH: - גדול! ומתי?

מ"מ: – כרגיל, אתמול.

MCH: - השווינו את שתי הגרסאות של fping ושל nmap:

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

אופטימיזציה של סקרים

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

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

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

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

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

הניסויים שלנו הראו שהמספר האופטימלי של בקשות באיטרציה אחת הוא כ-8 אלף עם סקר SNMP. בסך הכל, המעבר למצב אסינכרוני אפשר לנו להאיץ את ביצועי הסקרים פי 200, פי כמה מאות.

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

לפני כשלושה חודשים

שנה את הארכיטקטורה - הגדל את העומס!

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

MCH: אוקיי, בוא נתכנן את זה. הגיע הזמן לעבור מנקודת המתה של 5 מדדים לשנייה.

בוקר אחרי השדרוג

MCH: - מישה, עדכנו את עצמנו, אבל עד הבוקר התגלגלנו אחורה... נחשו מה המהירות שהצלחנו להשיג?

מ"מ: – 20 אלף מקסימום.

MCH: כן, 25! למרבה הצער, אנחנו בדיוק איפה שהתחלנו.

מ"מ: - למה? האם הפעלת איזשהו אבחון?

MCH: - כן בטח! הנה, למשל, טופ מעניין:

מ"מ: - בואו נצפה. אני רואה שניסינו מספר עצום של שרשורי סקרים:

אבל באותו זמן הם לא יכלו למחזר את המערכת אפילו בחצי:

והביצועים הכוללים די קטנים, בערך 4 מדדים לשנייה:

האם יש משהו אחר?

MCH: – כן, גזרה של אחד הסוקרים:

מ"מ: – כאן ניתן לראות בבירור שתהליך הסקרים ממתין ל"סמפורות". אלו המנעולים:

MCH: - לא ברור.

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

והביצועים הכוללים של עבודה עם משאב כזה מוגבלים על ידי המהירות של ליבה אחת:

ישנן שתי דרכים לפתור בעיה זו.

שדרג את החומרה של המכונה, עבור לליבות מהירות יותר:

או לשנות את הארכיטקטורה ובו זמנית לשנות את העומס:

MCH: – אגב, במכונת הבדיקה נשתמש בפחות ליבות מאשר בזו הקרבית, אבל הן מהירות פי 1,5 בתדירות לכל ליבה!

מ"מ: - ברור? אתה צריך להסתכל על קוד השרת.

נתיב נתונים בשרת Zabbix

MCH: - כדי להבין את זה, התחלנו לנתח כיצד מועברים נתונים בתוך שרת Zabbix:

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

הם משדרים את המדדים שנאספו דרך שקע למנהל Preprocessor, שם הם נשמרים בתור:

"מנהל המעבד המוקדם" מעביר נתונים לעובדיו, אשר מבצעים הוראות עיבוד מקדים ומחזירים אותם בחזרה דרך אותו שקע:

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

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

מ"מ: – הדבר הראשון שראינו היה שרוב השרשורים מתחרים על מה שנקרא "מטמון התצורה" (אזור הזיכרון שבו מאוחסנות כל תצורות השרת). שרשורים האחראים לאיסוף נתונים עושים חסימה רבה במיוחד:

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

סקרים לא צריכים להתנגש

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

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

מנהל מעבד קדם חייב להיות מסוגל לתעדף

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

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

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

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

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

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

לכן, עשינו ארבעה, עם ארבעה סטים של שקעים, פועלים:

וזה איפשר לנו להגביר את המהירות לכ-130 אלף מדדים:

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

לפני כ-2,5 חודשים

סירוב מ-snmp-community הגדיל את ה-NVPs פי אחד וחצי

מ"מ: – מקס, אני צריך מכונית מבחן חדשה! אנחנו כבר לא מתאימים לזה הנוכחי.

MCH: - מה יש לך עכשיו?

מ"מ: – עכשיו – 130 NVPs ומעבד מוכן למדף.

MCH: - וואו! מגניב! רגע, יש לי שתי שאלות. לפי החישובים שלי, הצורך שלנו הוא בסביבות 15-20 אלף מדדים לשנייה. למה אנחנו צריכים יותר?

מ"מ: "אני רוצה לסיים את העבודה." הייתי רוצה לראות כמה אנחנו יכולים לסחוט מהמערכת הזו.

MCH: - אבל…

מ"מ: "אבל זה חסר תועלת לעסקים."

MCH: - זה ברור. והשאלה השנייה: האם אנחנו יכולים לתמוך במה שיש לנו עכשיו לבד, בלי עזרה של מפתח?

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

MCH: "אז אנחנו צריכים סוג של אלטרנטיבה."

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

MCH: - מדהים! אני מציע שנפסיק כאן.

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

לדוגמה, נטישת מאקרו snmp-community, שנמצא לעתים קרובות בתיעוד ובדוגמאות, במקרה שלנו אפשרה להאיץ עוד יותר את ה-NVP בכפי 1,5.

לאחר יומיים בהפקה

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

MCH: - מישה, אנחנו משתמשים במערכת כבר יומיים, והכל עובד. אבל רק כשהכל עובד! תכננו עבודה עם העברה של פלח די גדול ברשת, ושוב בדקנו עם הידיים מה עלה ומה לא.

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

MCH: - כן, אני מבין הכל: שרת, מסד נתונים, top, austat, logs - הכל מהיר... אבל אנחנו מסתכלים על ממשק האינטרנט, ויש מעבד "במדף" בשרת וזה:

מ"מ: - זה ברור. בואו לצפות באינטרנט. מצאנו שבמצב שבו היו מספר רב של אירועים פעילים, רוב הווידג'טים החיים החלו לעבוד לאט מאוד:

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

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

אחרי העבודה. לפני 2 חודשים

MCH: - מישה, אתה עוזב? אנחנו חייבים לדבר.

מ"מ: - לא התכוונתי. שוב משהו עם Zabbix?

MCH: - לא, תירגע! רק רציתי לומר: הכל עובד, תודה! יש לי בירה.

Zabbix יעיל

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

• אתה יכול להשתמש בכלים מובנים בצורה של אינטגרציה עם Elasticsearch או העלאת היסטוריה לקבצי טקסט (זמין מגרסה XNUMX);
• אתה יכול לנצל את הניסיון והשילוב שלנו עם Clickhouse.

כדי להגביר באופן דרמטי את מהירות איסוף המדדים, אסוף אותם בשיטות אסינכרוניות ושדרו אותם דרך ממשק ה-Trapper לשרת Zabbix; או שאתה יכול להשתמש בתיקון כדי להפוך את המשאלים של Zabbix לא-סינכרוניים.

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

אותו תיקון Zabbix

מ"מ: - אני רוצה להוסיף כמה נקודות. כל הדוח הנוכחי, כל הבדיקות, המספרים ניתנים עבור התצורה שבה אנו משתמשים. כעת אנו לוקחים ממנו כ-20 אלף מדדים לשנייה. אם אתה מנסה להבין אם זה יעבוד בשבילך, אתה יכול להשוות. מה שנדון היום פורסם ב-GitHub בצורה של תיקון: github.com/miklert/zabbix

התיקון כולל:

• אינטגרציה מלאה עם Clickhouse (הן שרת Zabbix והן חזיתית);
• פתרון בעיות עם מנהל המעבד;
• סקר אסינכרוני.

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

תודה על תשומת הלב שלך.

שאלות

שאלה מהקהל (להלן – א): – צהריים טובים! בבקשה תגיד לי, האם יש לך תוכניות לאינטראקציה אינטנסיבית עם צוות Zabbix או איתם איתך, כך שלא מדובר בתיקון, אלא בהתנהגות נורמלית של Zabbix?

מ"מ: - כן, אנחנו בהחלט נבצע חלק מהשינויים. משהו יקרה, משהו יישאר בתיקון.

וגם: - תודה רבה על הדיווח המעולה! אנא תגיד לי, לאחר החלת התיקון, התמיכה של Zabbix תישאר ואיך להמשיך לעדכן לגרסאות גבוהות יותר? האם ניתן יהיה לעדכן את Zabbix לאחר התיקון שלך ל-4.2, 5.0?

מ"מ: - אני לא יכול להגיד שום דבר על תמיכה. אם הייתי תמיכה טכנית של Zabbix, כנראה שהייתי אומר לא, כי זה הקוד של מישהו אחר. לגבי בסיס הקוד 4.2, העמדה שלנו היא: "נתקדם עם הזמן, ונעדכן את עצמנו בגרסה הבאה." לכן, במשך זמן מה נפרסם תיקון לגרסאות מעודכנות. כבר אמרתי בדוח: מספר השינויים עם גרסאות עדיין די קטן. אני חושב שהמעבר מ-3.4 ל-4 לקח לנו בערך 15 דקות. משהו השתנה שם, אבל לא מאוד חשוב.

וגם: - אז אתה מתכנן לתמוך בתיקון שלך ותוכל להתקין אותו בבטחה בייצור ולקבל עדכונים בדרך כלשהי בעתיד?

מ"מ: - אנו ממליצים בחום. זה פותר לנו הרבה בעיות.

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

מ"מ: - אם אתה מעוניין בפרטים, אז "Clickhouse" משתמש במה שנקרא ספריית היסטוריה. זה לא קשור - זה עותק של תמיכת Elastics, כלומר, זה ניתן להגדרה. סקרים רק משנה את הסוקרים. אנחנו מאמינים שזה יעבוד לאורך זמן.

וגם: - תודה רבה. תגיד לי, האם יש תיעוד של השינויים שבוצעו?

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

לגבי החלפת fping ב-nmap

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

מ"מ: - מגניב. שאלה נכונה מאוד! הנקודה היא זו. שינינו את הספרייה (ICMP ping, חלק מ- Zabbix) עבור בדיקות ICMP, שמציינות את מספר החבילות - אחת (1), והקוד מנסה להשתמש ב-nmap. כלומר, זוהי עבודתו הפנימית של זביקס, שהפכה לעבודתו הפנימית של הפינגר. בהתאם לכך, אין צורך בסנכרון או שימוש בלכד. זה נעשה בכוונה על מנת להשאיר את המערכת שלמה ולא להתעסק בסנכרון של שתי מערכות מסד נתונים: מה לבדוק, להעלות דרך הפולר, וההעלאה שלנו מקולקלת?.. זה הרבה יותר פשוט.

וגם: - האם זה עובד גם עבור פרוקסי?

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

MCH: - התשובה הנכונה לשאלה היא: "למה אתה צריך פרוקסי עם מערכת כזו?" רק בגלל NAT או ניטור דרך איזשהו ערוץ איטי...

וגם: – ואתה משתמש ב-Zabix בתור אלרטור, אם אני מבין נכון. או שהגרפיקה שלך (היכן נמצאת שכבת הארכיון) הועברה למערכת אחרת, כגון Grafana? או שאתה לא משתמש בפונקציונליות הזו?

מ"מ: – אדגיש שוב: השגנו אינטגרציה מלאה. אנחנו יוצקים היסטוריה לתוך Clickhouse, אבל במקביל שינינו את חזית ה-php. ה-frontend של Php עובר ל-Clickhouse ועושה את כל הגרפיקה משם. יחד עם זאת, למען האמת, יש לנו חלק שבונה נתונים במערכות תצוגה גרפיות אחרות מאותו קליקהאוס, מאותם נתוני Zabbix.

MCH: – גם ב"גרפן".

כיצד התקבלו החלטות לגבי הקצאת משאבים?

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

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

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

וגם: – ומה גודל הצוות?

MCH: - היא מולך.

וגם: - אז, כמו תמיד, אתה צריך נלהב?

מ"מ: - אני לא יודע מה זה נלהב.

וגם: - במקרה הזה, כנראה, אתה. תודה רבה, את מדהימה.

מ"מ: - תודה.

לגבי תיקונים לזאביקס

וגם: – עבור מערכת המשתמשת בפרוקסי (למשל, בחלק מהמערכות המבוזרות), האם ניתן להתאים ולתקן, נניח, פולרים, פרוקסי ובחלקו הפרה-מעבד של Zabbix עצמו; והאינטראקציה ביניהם? האם ניתן לבצע אופטימיזציה של פיתוחים קיימים עבור מערכת עם מספר פרוקסי?

מ"מ: – אני יודע ששרת Zabbix מורכב באמצעות פרוקסי (הקוד מקומפל ומתקבל). לא בדקנו את זה בייצור. אני לא בטוח לגבי זה, אבל אני חושב שמנהל הפרה-processor אינו בשימוש בפרוקסי. המשימה של ה-proxy היא לקחת קבוצה של מדדים מ- Zabbix, למזג אותם (הוא גם מתעד את התצורה, את מסד הנתונים המקומי) ולהחזיר אותו לשרת Zabbix. השרת עצמו יבצע את העיבוד המקדים כשהוא יקבל אותו.

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

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

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

וגם: - סביר להניח שלא תצטרך לתקן את שידור ה-proxy לשרת בנוסף?

MCH: - לא, זה סטנדרטי.

מ"מ: – למעשה, אחד הרעיונות לא נשמע. תמיד שמרנו על איזון בין התפוצצות הרעיונות לכמות השינויים וקלות התמיכה.

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com