בארכיטקטורת ההפניה הזו מתואר איך אפשר לייבא יומנים שיוצאו בעבר ל-Cloud Storage בחזרה ל-Cloud Logging.
ארכיטקטורת ההפניה הזו מיועדת למהנדסים ולמפתחים, כולל DevOps, מהנדסי SRE וחוקרי אבטחה, שרוצים להגדיר ולהפעיל את משימת ייבוא היומנים. במאמר הזה מניחים שאתם יודעים איך להריץ משימות של Cloud Run ואיך להשתמש ב-Cloud Storage וב-Cloud Logging.
ארכיטקטורה
בתרשים הבא מוצג אופן השימוש בשירותי Google Cloud בארכיטקטורת ההפניה הזו:
תהליך העבודה הזה כולל את הרכיבים הבאים:
- קטגוריה של Cloud Storage: מכילה את היומנים שיוצאו בעבר ורוצים לייבא אותם בחזרה ל-Cloud Logging. היומנים האלה יוצאו בעבר, ולכן הם מאורגנים בפורמט הייצוא הצפוי.
- משימה של Cloud Run: מריצה את תהליך ייבוא היומנים:
- קריאת האובייקטים שמאחסנים רשומות ביומן מ-Cloud Storage.
- הכלי מוצא יומנים מיוצאים לפי מזהה היומן שצוין, בטווח הזמן המבוקש, על סמך הארגון של היומנים המיוצאים בקטגוריה של Cloud Storage.
- הפונקציה ממירה את האובייקטים למבני
LogEntryשל Cloud Logging API. כדי לצמצם את השימוש במכסה של Cloud Logging API, כמה מבניLogEntryמצורפים יחד למנות. הארכיטקטורה מטפלת בשגיאות שקשורות למכסות כשצריך. - כתיבת הרשומות ביומן שהומרו ל-Cloud Logging. אם מריצים את אותה משימה כמה פעמים, יכול להיות שיווצרו רשומות כפולות. מידע נוסף זמין במאמר בנושא הפעלת עבודת הייבוא.
- Cloud Logging: קליטה ואחסון של רשומות היומן שהומרו.
רשומות היומן מעובדות כמו שמתואר במאמר סקירה כללית על ניתוב ואחסון.
- חלות המכסות והמגבלות של Logging, כולל המכסות והמגבלות של Cloud Logging API ותקופת השמירה של 30 יום. ארכיטקטורת ההפניה הזו מיועדת לפעול עם מכסות הכתיבה שמוגדרות כברירת מחדל, עם מנגנון בסיסי לניסיון חוזר. אם מכסת הכתיבה שלכם נמוכה ממכסת ברירת המחדל, יכול להיות שההטמעה תיכשל.
- היומנים המיובאים לא נכללים במדדים שמבוססים על יומנים, כי חותמות הזמן שלהם הן מהעבר. עם זאת, אם תבחרו להשתמש בתווית, חותמת הזמן תתעד את זמן הייבוא, והיומנים ייכללו בנתוני המדדים.
- BigQuery: משתמש ב-SQL כדי להריץ שאילתות אנליטיות על יומנים מיובאים (אופציונלי). כדי לייבא יומני ביקורת מ-Cloud Storage, הארכיטקטורה הזו משנה את מזהי היומנים. לכן, צריך לקחת בחשבון את שינוי השם הזה כששולחים שאילתות ליומנים המיובאים.
תרחיש שימוש
אפשר לבחור לפרוס את הארכיטקטורה הזו אם הארגון שלכם דורש ניתוח יומנים נוסף לחקירות של אירועים או לביקורות אחרות של אירועים קודמים. לדוגמה, יכול להיות שתרצו לנתח חיבורים למסדי הנתונים שלכם ברבעון הראשון של השנה שעברה, כחלק מביקורת על גישה למסד נתונים.
חלופות עיצוב
בקטע הזה מתוארות חלופות לעיצוב ברירת המחדל שמוצג במסמך הזה של ארכיטקטורת ההפניה.
תקופת השמירה ויומנים מיובאים
Cloud Logging דורש שרשומות ביומן הנכנסות יכללו חותמות זמן שלא חורגות מתקופת שמירה של 30 יום. רשומות ביומן שיובאו עם חותמות זמן מלפני יותר מ-30 יום ממועד הייבוא לא נשמרות.
הארכיטקטורה הזו מאמתת את טווח התאריכים שהוגדר בעבודת Cloud Run כדי למנוע ייבוא של יומנים בני יותר מ-29 ימים, ומשאירה מרווח ביטחון של יום אחד.
כדי לייבא יומנים בני יותר מ-29 ימים, צריך לבצע את השינויים הבאים בקוד ההטמעה, ואז ליצור קובץ אימג' של קונטיינר חדש לשימוש בהגדרת העבודה של Cloud Run.
- הסרת האימות של טווח התאריכים אחרי 30 יום
- הוספת חותמת הזמן המקורית כתווית משתמש לרשומה ביומן
- איפוס התווית של חותמת הזמן של רשומת היומן כדי לאפשר את ההוספה שלה עם חותמת הזמן הנוכחית
כשמשתמשים בשינוי הזה, צריך להשתמש בשדה labels במקום בשדה timestamp בשאילתות של Observability Analytics. מידע נוסף על שאילתות ודוגמאות של Observability Analytics זמין במאמר דוגמאות לשאילתות SQL.
שיקולים בתכנון
ההנחיות הבאות יעזרו לכם לפתח ארכיטקטורה שתענה על הדרישות של הארגון שלכם.
הוזלת עלויות
העלות של ייבוא יומנים באמצעות ארכיטקטורת ההפניה הזו מושפעת מכמה גורמים.
במדריך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:
- Cloud Logging (תקופת שמירת היומנים חלות עלויות)
- Cloud Run
- Cloud Storage API
כדאי להביא בחשבון את הגורמים הבאים שעלולים להגדיל את העלויות:
- כפילויות ביומן: כדי להימנע מעלויות נוספות של אחסון יומנים, אל תריצו את עבודת הייבוא עם אותה הגדרה כמה פעמים.
- אחסון ביעדים נוספים: כדי להימנע מעלויות נוספות של אחסון יומנים, צריך להשבית את מדיניות הניתוב בפרויקט היעד כדי למנוע אחסון יומנים במיקומים נוספים או העברה של יומנים ליעדים אחרים כמו Pub/Sub או BigQuery.
- מעבד וזיכרון נוספים: אם חלף הזמן הקצוב לייבוא, יכול להיות שתצטרכו להגדיל את המעבד והזיכרון של עבודת הייבוא בהגדרות של עבודת הייבוא. הגדלת הערכים האלה עשויה להגדיל את העלויות של Cloud Run.
- משימות נוספות: אם המספר הצפוי של יומנים לייבוא בכל יום בטווח הזמן גבוה, יכול להיות שתצטרכו להגדיל את מספר המשימות בהגדרות של עבודת הייבוא. העבודה תחלק את טווח הזמן באופן שווה בין המשימות, כך שכל משימה תעבד מספר דומה של ימים מהטווח במקביל. הגדלת מספר המשימות עשויה להגדיל את העלויות של Cloud Run.
- סוג האחסון: אם סוג האחסון של הקטגוריה ב-Cloud Storage הוא לא Standard, אלא Nearline, Durable Reduced Availability (DRA) או Coldline, יכול להיות שתחויבו בחיובים נוספים.
- תעבורת נתונים בין מיקומים שונים: מגדירים את משימת הייבוא כך שתפעל באותו מיקום של קטגוריית Cloud Storage שממנה מייבאים את היומנים. אחרת, יכול להיות שיוחלו עלויות על תעבורת נתונים יוצאת (egress) ברשת.
כדי ליצור הערכת עלויות על סמך השימוש החזוי, כולל משימות של Cloud Run, אתם יכולים להשתמש במחשבון התמחור.
יעילות תפעולית
בקטע הזה מתוארים שיקולים לניהול שאילתות ניתוח אחרי פריסת הפתרון.
שמות של יומנים ושאילתות
היומנים מאוחסנים בפרויקט שמוגדר בשדה logName של הרשומה ביומן. כדי לייבא את היומנים לפרויקט שנבחר, הארכיטקטורה הזו משנה את השדה logName של כל יומן מיובא. יומני הייבוא מאוחסנים בקטגוריית היומנים שמוגדרת כברירת מחדל בפרויקט שנבחר, עם מזהה היומן imported_logs (אלא אם בפרויקט מוגדרת מדיניות ניתוב יומנים שמשנה את יעד האחסון).
הערך המקורי של השדה logName נשמר בשדה labels עם המפתח original_logName.
כשמבצעים שאילתה ביומנים המיובאים, צריך להתייחס למיקום של הערך המקורי logName. מידע נוסף על שאילתות ודוגמאות של Observability Analytics זמין במאמר דוגמאות לשאילתות SQL.
אופטימיזציה של הביצועים
אם נפח היומנים שאתם מייבאים חורג ממגבלות הקיבולת של Cloud Run, יכול להיות שזמן הקצוב של המשימה יפוג לפני שהייבוא יושלם. כדי למנוע ייבוא לא מלא של נתונים, כדאי להגדיל את הערך של tasks במשימת הייבוא. הגדלת משאבי המעבד והזיכרון יכולה גם לעזור לשפר את ביצועי המשימות כשמגדילים את מספר המשימות.
פריסה
כדי לפרוס את הארכיטקטורה הזו, ראו פריסת משימה לייבוא יומנים מ-Cloud Storage אל Cloud Logging.
המאמרים הבאים
- בודקים את קוד ההטמעה במאגר GitHub.
- כאן מוסבר איך לנתח יומנים מיובאים באמצעות Observability Analytics ו-SQL.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: לאוניד ינקולין | מהנדס קשרי מפתחים
תורמי תוכן אחרים:
- Summit Tuladhar | Senior Staff Software Engineer
- Wilton Wong | Enterprise Architect
- Xiang Shen | Solutions Architect