יומנים ב-Kubernetes (ולא רק) היום: ציפיות ומציאות

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

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

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

להלן הקטע שלהלן לגבי האופן שבו יישמנו "רשימות משאלות" שונות ובאילו קשיים נתקלנו.

תיאוריה: על כלי רישום

רקע על מרכיבי מערכת רישום

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

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

עם הגידול בנפח היומנים וההחדרה הנרחבת של טכנולוגיות אינטרנט, עלתה השאלה אילו יומנים צריכים להיות מוצגים בנוחות למשתמשים. כלי קונסולה פשוטים (awk/sed/grep) הוחלפו בכלים מתקדמים יותר צופים ביומן - רכיב שלישי.

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

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

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

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

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

Kubernetes ויומנים

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

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

• מישהו פורש את הערימה EFK (Elasticsearch, Fluentd, Kibana);
• מישהו מנסה את הגרסה שיצאה לאחרונה לוקי או שימושים מפעיל רישום;
• שלנו (ואולי לא רק אנחנו?..) אני מרוצה במידה רבה מההתפתחות שלי - בית עץ...

ככלל, אנו משתמשים בחבילות הבאות באשכולות K8s (לפתרונות אירוח עצמי):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + בית עץ.

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

תרגול עם יומנים ב-K8s

"יומנים יומיומיים", כמה מכם יש?..

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

בואו ננסה את ClickHouse

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

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

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

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

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

כדי להימנע מהתנהגות זו, צריך לכתוב ל- ClickHouse בחתיכות גדולות ככל האפשר ולא יותר מפעם אחת בכל 1 שניות. עם זאת, כתיבה בפרצים גדולים מציעה לנו לכתוב בתדירות נמוכה יותר ב-ClickHouse. זה, בתורו, יכול להוביל להצפת חיץ ואובדן יומנים. הפתרון הוא להגדיל את Buffer Fluentd, אבל אז גם צריכת הזיכרון תגדל.

שים לב: היבט בעייתי נוסף של הפתרון שלנו עם ClickHouse היה קשור לעובדה שהחלוקה במקרה שלנו (לוגhouse) מיושמת באמצעות טבלאות חיצוניות המחוברות מיזוג טבלה. זה מוביל לעובדה שכאשר דוגמים מרווחי זמן גדולים, נדרש זיכרון RAM מוגזם, מכיוון שה-metatable חוזר על כל המחיצות - גם אלה שכמובן אינן מכילות את הנתונים הדרושים. עם זאת, כעת ניתן להכריז בבטחה על גישה זו מיושנת עבור גרסאות נוכחיות של ClickHouse (ג 18.16).

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

מה לגבי Elasticsearch?

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

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

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

ואז עולה שאלה טבעית:

אילו יומנים באמת נחוצים?

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

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

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

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

איור מהחיים

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

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

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

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

קריטריונים ליומנים

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

• יומנים חייבים להיות בפורמט קריא במכונה (לדוגמה, JSON).
• יומנים צריכים להיות קומפקטיים ובעלי יכולת לשנות את מידת הרישום על מנת לנפות באגים אפשריים. יחד עם זאת, בסביבות ייצור כדאי להפעיל מערכות ברמת רישום כמו אזהרה או שְׁגִיאָה.
• יומנים חייבים להיות מנורמלים, כלומר באובייקט יומן, כל השורות חייבות להיות עם אותו סוג שדה.

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

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

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

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

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

"upstream_response_time": "0.001, 0.007"

מצב זה כל כך נפוץ עד שהוא ראוי אפילו להפרדה הפניות בתיעוד.

מה לגבי אמינות?

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

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

"helm.sh/hook-delete-policy": hook-succeeded

בשל כך, יומן ביצוע ההעברה לא נכלל באחסון. פוליטיקה יכולה לעזור במקרה הזה. before-hook-creation.

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

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

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

ממצאים

במאמר זה, אנחנו לא מסתכלים על פתרונות SaaS כמו Datadog. רבות מהבעיות המתוארות כאן כבר נפתרו בדרך זו או אחרת על ידי חברות מסחריות המתמחות באיסוף יומנים, אך לא כל אחד יכול להשתמש ב-SaaS מסיבות שונות (העיקריים שבהם הם עלות ועמידה ב-152-FZ).

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

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

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

נ.ב.

קרא גם בבלוג שלנו:

• «מציגים את loghouse - מערכת קוד פתוח לעבודה עם לוגים ב-Kubernetes";
• «מהדורות עבור המערכת האקולוגית של Kubernetes מ-KubeCon'19: JFrog Container Registry, Kui מ-IBM, Loki 1.0.0...";
• «ניטור ו-Kubernetes (סקירה ודוח וידאו)".

מקור: www.habr.com