יורי בוסמלב "מפת מגרפה בתחום איסוף ומסירת בולי עץ" - תמלול הדו"ח

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

• כיצד לכתוב יומנים מהאפליקציה;
• היכן לכתוב יומנים;
• כיצד לספק יומנים לאחסון ועיבוד;
• כיצד לעבד ולאחסן יומנים.

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

בדיוק על זה תמלול הדו"ח של יורי בוסמלב "מפת מגרפה בתחום איסוף ומסירת בולי עץ"

למי אכפת, בבקשה מתחת לחתול.

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

מאיפה אנחנו? מי אנחנו? Lazada היא הקמעונאית המקוונת מספר 1 בשש מדינות בדרום מזרח אסיה. כל המדינות הללו מפוזרות בין מרכזי נתונים. יש עכשיו 4 מרכזי נתונים בסך הכל. למה זה חשוב? כי חלק מההחלטות נבעו מהעובדה שיש קשר מאוד חלש בין המרכזים. יש לנו ארכיטקטורת מיקרו-שירותים. הופתעתי לגלות שיש לנו כבר 80 שירותי מיקרו. כשהתחלתי את המשימה עם יומנים, היו רק 20 מהם. בנוסף, יש חתיכה די גדולה של מורשת PHP, שגם אני צריך לחיות איתה ולסבול. כל זה מייצר עבורנו כרגע יותר מ-6 מיליון הודעות בדקה עבור המערכת כולה. בהמשך אראה כיצד אנו מנסים לחיות עם זה, ולמה זה כך.

אתה צריך לחיות עם 6 מיליון ההודעות האלה איכשהו. מה עלינו לעשות איתם? דרושים 6 מיליון הודעות:

• לשלוח מהאפליקציה
• לקבל למשלוח
• לספק לניתוח ואחסון.
• לְנַתֵחַ
• לאחסן איכשהו.

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

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

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

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

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

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

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

בואו נסתכל עוד קצת. איך סיפקנו את היומנים האלה. מישהו בחר ב-td-agent, שהוא למעשה שוטף אבל לא ממש שוטף. אני עדיין לא מבין את הקשר בין שני הפרויקטים האלה, אבל נראה שהם בערך אותו דבר. והדבר השוטף הזה, שנכתב ברובי, קרא קובצי יומן, ניתוח אותם ל-JSON באמצעות כמה ביטויים רגולריים. אחר כך נשלחו לקפקא. יתרה מכך, בקפקא היו לנו 4 נושאים נפרדים לכל API. למה 4? בגלל שיש חי, יש בימוי, ובגלל שיש stdout ו-stderr. מפתחים מייצרים אותם, ועובדי תשתית חייבים ליצור אותם בקפקא. יתרה מכך, קפקא נשלט על ידי מחלקה אחרת. לכן, היה צורך ליצור כרטיס כך שיצרו שם 4 נושאים לכל API. כולם שכחו מזה. באופן כללי, זה היה זבל ופסולת.

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

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

כאן (1,2,3) אנו כותבים קבצים, ובהתאם לכך, יש כאן שלוש גריפות בבת אחת.

הראשון (1) הוא שאנחנו צריכים לכתוב אותם איפשהו. לא תמיד רצוי לתת ל-API את היכולת לכתוב ישירות לקובץ. רצוי שה-API יהיה מבודד בקונטיינר, ואפילו טוב יותר, שיהיה לקריאה בלבד. אני מנהל מערכת, אז יש לי השקפה קצת חלופית על הדברים האלה.

הנקודה השנייה (2,3) היא שיש לנו הרבה בקשות שמגיעות ל-API. ה-API כותב הרבה נתונים לקובץ. הקבצים הולכים וגדלים. אנחנו צריכים לסובב אותם. כי אחרת לא תוכל לשמור שם שום דיסק. לסובב אותם זה רע כי הם מנותבים מחדש דרך המעטפת לספרייה. אין סיכוי שנוכל לסובב אותו. אתה לא יכול להגיד לאפליקציה לפתוח מחדש את הידיות. כי המפתחים יסתכלו עליך כמו טיפש: "איזה מתארים? בדרך כלל אנחנו כותבים ל-stdout. ה-frameworks הפכו את copytruncate ל-logrotate, שפשוט יוצר עותק של הקובץ ומעביר את המקור. בהתאם, בין תהליכי העתקה אלה, בדרך כלל אוזל שטח הדיסק.

(4) היו לנו פורמטים שונים בממשקי API שונים. הם היו מעט שונים, אבל הביטוי הרגולרי היה צריך להיכתב אחרת. מכיוון שהכל נוהל על ידי Puppet, היו חבורה גדולה של כיתות עם ג'וקים משלהם. בנוסף, td-agent רוב הזמן יכול היה לאכול זיכרון, להיות טיפש, הוא יכול פשוט להעמיד פנים שהוא עובד ולא לעשות כלום. כלפי חוץ, אי אפשר היה להבין שהוא לא עושה כלום. במקרה הטוב, הוא ייפול, ומישהו יאסוף אותו אחר כך. ליתר דיוק, התראה תעוף פנימה, ומישהו ילך וירים אותה בידיים.

(6) והכי זבל ופסולת - זה היה חיפוש אלסטי. כי זו הייתה גרסה ישנה. כי לא היו לנו אז אדונים מסורים. היו לנו בולי עץ הטרוגניים ששדותיהם יכולים לחפוף. ניתן לכתוב יומנים שונים של יישומים שונים עם אותם שמות שדות, אך באותו זמן יכולים להיות נתונים שונים בפנים. כלומר, יומן אחד מגיע עם מספר שלם בשדה, למשל, רמה. יומן נוסף מגיע עם String בשדה הרמה. בהיעדר מיפוי סטטי, מתברר דבר נפלא שכזה. אם לאחר סיבוב האינדקס, הודעה עם מחרוזת הגיעה ראשונה ב- elasticsearch, אז אנחנו חיים כרגיל. ואם הראשון הגיע עם Integer, אז כל ההודעות הבאות שהגיעו עם String פשוט נמחקות. כי סוג השדה אינו תואם.

התחלנו לשאול את השאלות האלה. החלטנו לא לחפש את האשמים.

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

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

ושם (בשקופית) בקושי מתחיל להופיע ה-"SLA למסירת יומן". זה עדיין לא שם, אבל אנחנו עובדים על זה. כי זה מאוד נוח כשאינפרא אומר שאם אתה כותב בפורמט כזה או אחר למקום כזה ואחר ולא יותר מ-N הודעות בשנייה, אז סביר להניח שנעביר את זה שם. זה מוריד הרבה כאבי ראש. אם יש SLA, אז זה פשוט מעולה!

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

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

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

הפתרון הברור ל-sysadmin הוא כל מיני סיסלוגים בכמות הזו (syslog-ng/rsyslog/nxlog).

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

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

וקצת על rsyslog. ראשית, זה מגניב כי יש לו הרבה מודולים. יש לו RainerScript (שפת תצורה מודרנית) הניתן לקריאה על ידי אדם. בונוס מדהים הוא שיכולנו לחקות את ההתנהגות של td-agent עם הכלים הסטנדרטיים שלו, ושום דבר לא השתנה עבור יישומים. כלומר, אנחנו משנים את td-agent ל-rsyslog, ועדיין לא נוגעים בכל השאר. ומיד אנחנו מקבלים משלוח עובד. בשלב הבא, mmnormalize הוא הדבר המגניב ב-rsyslog. זה מאפשר לך לנתח יומנים, אבל לא עם Grok ו-regexp. זה יוצר עץ תחביר מופשט. הוא מנתח יומנים בערך באותו אופן שבו מהדר מנתח קוד מקור. זה מאפשר לך לעבוד מהר מאוד, לאכול מעט מעבד, ובאופן כללי, זה פשוט דבר מאוד מגניב. יש עוד המון בונוסים. אני לא אתעכב עליהם.

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

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

למה לא קובץ? כי כולם קראו מאמר על Badushechka, שניסתה להעביר את הקובץ ל-docker, וגילתה שלאחר הפעלה מחדש של rsyslog, מתאר הקובץ משתנה, ו-docker מאבד את הקובץ הזה. הוא פותח משהו אחר, אבל לא אותו שקע שבו הם כותבים. החלטנו שנעקוף את הבעיה הזו, ובמקביל לעקוף את בעיית החסימה.

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

אבל יש ניואנסים איך למלא אותם מאוחר יותר בחלק הזה (Logstash/Graylog/ES). חלק זה (rsyslog-rsyslog) משמש בין מרכזי נתונים. לפניכם קישור tcp דחוס, המאפשר לכם לחסוך ברוחב פס ובהתאם להגדיל איכשהו את הסבירות שנקבל כמה לוגים ממרכז נתונים אחר כשהערוץ יהיה מלא. כי יש לנו אינדונזיה, שבה הכל רע. שם טמונה הבעיה הקבועה.

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

מה הבעיות? הבעיה נוצרה עם העובדה שגילינו (פתאום!) שה-API Live שלנו כותב 50 הודעות בשנייה. זה רק Live API ללא בימוי. וגריילוג מראה לנו רק 12 אלף הודעות בשנייה. ועלתה שאלה סבירה היכן השרידים? שממנו הסקנו ש-Graylog פשוט לא יכול להתמודד. בדקנו, ואכן, Graylog עם Elasticsearch לא שלט בזרימה הזו.

בשלב הבא, תגליות אחרות שגילינו לאורך הדרך.

כתיבה לשקע חסומה. איך זה קרה? כשהשתמשתי ב-rsyslog למסירה, בשלב מסוים שברנו את הערוץ בין מרכזי הנתונים. המשלוח עלה במקום אחד, המשלוח עלה במקום אחר. כל זה הסתכם במכונה עם ממשקי API שכותבים לשקע rsyslog. היה תור. ואז התמלא התור לכתיבה לשקע ה-Unix, שהוא כברירת מחדל של 128 מנות. וה-write() הבא בבלוקים של היישום. כאשר הסתכלנו על הספרייה שבה אנו משתמשים ביישומי Go, היה כתוב שם שהכתיבה לשקע מתרחשת במצב לא חוסם. היינו בטוחים ששום דבר לא חסום. כי קראנו מאמר על Badushechkaמי כתב על זה. אבל יש רגע. הייתה גם לולאה אינסופית סביב השיחה הזו, שבה היה ניסיון מתמיד לדחוף הודעה לשקע. לא שמנו לב אליו. הייתי צריך לשכתב את הספרייה. מאז, זה השתנה כמה פעמים, אבל עכשיו נפטרנו ממנעולים בכל תת-המערכות. לכן, אתה יכול להפסיק את rsyslog ושום דבר לא ייפול.

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

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

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

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

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

החלטנו להפיל את Logstash ואת Kibana. כי יש לנו מחלקת אבטחה. מה הקשר? הקשר הוא ש-Kibana ללא X-Pack וללא Shield לא מאפשרת להבדיל בין זכויות גישה ללוגים. לכן, הם לקחו את Graylog. יש בו הכל. אני לא אוהב את זה, אבל זה עובד. קנינו חומרה חדשה, התקנו שם Graylog טרי, והעברנו את כל היומנים עם פורמטים קפדניים ל- Graylog נפרד. פתרנו את הבעיה עם סוגים שונים של אותם תחומים מבחינה ארגונית.

מה בדיוק כלול ב-Graylog החדש. פשוט כתבנו הכל בדוקר. לקחנו חבורה של שרתים, פרסנו שלושה מופעים של Kafka, 7 שרתי Graylog גרסה 2.3 (כי רציתי את Elasticsearch גרסה 5). כל זה הועלה על פשיטות מה- HDD. ראינו קצב אינדקס של עד 100 אלף הודעות בשנייה. ראינו את הנתון של 140 טרה-בייט של נתונים בשבוע.

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

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

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

אסוף מדדים מ-Graylog.

תעשה הגבלת תעריף כדי שיהיה לנו API מטורף אחד שלא הורג לנו רוחב פס וכל השאר.

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

ולכתוב תיעוד.

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

שאלות.

שאלה: למה הם החליטו לא לקחת ... (filebeat?)

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

שאלה: למה שלא תכתוב יומנים ל-HDFS?

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

שאלה: פורמט עמודה יהיה מתאים יותר.

תשובה: אני מבין. אנחנו "בעד" בשתי ידיים.

שאלה: אתה כותב ל-rsyslog. גם TCP וגם UDP זמינים שם. אבל אם UDP, אז איך אתה מבטיח משלוח?

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

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

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

שאלה: חותמת הזמן עשויה להשתנות באלפיות שניות.

תשובה: חותמת הזמן נוצרת על ידי ה-API עצמו. זה, למעשה, כל העניין. יש לנו NTP. ה-API יוצר חותמת זמן כבר בהודעה עצמה. זה לא נוסף על ידי rsyslog.

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

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

שאלה: האם אתה מקבל משם יומנים במצבים חריגים?

תשובה: אתה יכול ללכת לשם (לאחסון הקבצים) ולהסתכל.

שאלה: איך אתה מפקח על כך שאתה לא מאבד יומנים?

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

שאלה: ב- elasticsearch, אתה מאחסן יומנים עם יתירות. כמה העתקים יש לך?

תשובה: העתק אחד.

שאלה: האם זה רק שורה אחת?

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

שאלה: האם שינית את הגודל של מאגר rsyslog איכשהו?

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

שְׁאֵלָה: האם אתה כותב JSON שבור?

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

שְׁאֵלָה: למה קפקא? ניסית את RabbitMQ? Graylog לא מסתדר תחת עומסים כאלה?

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

על קפקא. כך זה קרה היסטורית. כשהגעתי, זה כבר היה שם, וכבר נכתבו לו יומנים. פשוט הרמנו את האשכול שלנו והעברנו אליו בולי עץ. אנחנו מנהלים אותו, אנחנו יודעים איך הוא מרגיש. לגבי RabbitMQ... יש לנו בעיה עם RabbitMQ. ו-RabbitMQ מפתחת עבורנו. יש לנו את זה בייצור, והיו עם זה בעיות. עכשיו, לפני המכירה, הוא יקבל שמאניזציה, והוא יתחיל לעבוד כרגיל. אבל לפני כן, לא הייתי מוכן לשחרר אותו לייצור. יש עוד דבר אחד. Graylog יכול לקרוא את גרסת AMQP 0.9 ו-rsyslog יכול לכתוב את גרסת AMQP 1.0. ואין פתרון אחד שיכול לעשות את שניהם באמצע. יש או אחד או אחר. אז בינתיים רק קפקא. אבל יש גם ניואנסים. מכיוון ש-omkafka של הגרסה של rsyslog שבה אנו משתמשים יכולה לאבד את כל מאגר ההודעות שהיא גרפה מ-rsyslog. כל עוד אנחנו משלימים עם זה.

שְׁאֵלָה: האם אתה משתמש בקפקא כי היה לך את זה? לא משמש לשום מטרה אחרת?

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

שְׁאֵלָה: למה אנחנו צריכים את השמאניזם הזה עם שקעים? האם ניסית להשתמש במנהל ההתקן של יומן ה-syslog עבור קונטיינרים.

תשובה: בזמן ששאלנו את השאלה הזו, היו לנו יחסים מתוחים עם הדוקר. זה היה docker 1.0 או 0.9. דוקר עצמו היה מוזר. שנית, אם אתה גם דוחף לו יומנים... יש לי חשד לא מאומת שהוא מעביר את כל היומנים דרך עצמו, דרך דמון הדוקר. אם יש לנו API אחד שמשתגע, אז שאר ה-APIs יתקלו בעובדה שהם לא יכולים לשלוח stdout ו-stderr. אני לא יודע לאן זה יוביל. יש לי חשד ברמה של הרגשה שאין צורך להשתמש במנהל ההתקן של docker syslog במקום הזה. למחלקת הבדיקות הפונקציונליות שלנו יש אשכול Graylog משלה עם יומנים. הם משתמשים בדרייברים של docker log ונראה שהכל בסדר שם. אבל הם מיד כותבים GELF לגריילוג. ברגע שהתחלנו את כל זה, היינו צריכים שזה פשוט יעבוד. אולי אחר כך, כשיבוא מישהו ויגיד שזה עובד כרגיל כבר מאה שנים, ננסה.

שְׁאֵלָה: אתה מספק בין מרכזי נתונים באמצעות rsyslog. למה לא על קפקא?

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

מקור: www.habr.com