פריסת משימה לייבוא יומנים מ-Cloud Storage ל-Cloud Logging

Last reviewed 2025-02-19 UTC

במאמר הזה מוסבר איך לפרוס את ארכיטקטורת העזר שמתוארת במאמר ייבוא יומנים מ-Cloud Storage ל-Cloud Logging.

ההוראות האלה מיועדות למהנדסים ולמפתחים, כולל DevOps, מהנדסי SRE וחוקרי אבטחה, שרוצים להגדיר ולהפעיל את משימת ייבוא היומנים. בנוסף, אנחנו מניחים שאתם יודעים איך להריץ משימות ייבוא של Cloud Run ואיך להשתמש ב-Cloud Storage וב-Cloud Logging.

ארכיטקטורה

בתרשים הבא מוצג אופן השימוש בשירותי Google Cloud בארכיטקטורת ההפניה הזו:

פרטים נוספים זמינים במאמר ייבוא יומנים מ-Cloud Storage אל Cloud Logging.

מטרות

• יצירה והגדרה של משימת ייבוא ב-Cloud Run
• יצירת חשבון שירות להרצת העבודה

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• Cloud Logging
• Cloud Run
• Cloud Storage

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

לפני שמתחילים

1. מוודאים שהיומנים שרוצים לייבא יוצאו בעבר ל-Cloud Storage, כלומר שהם כבר מאורגנים בפורמט הייצוא הצפוי.

2. מפעילים את Cloud Shell במסוף Google Cloud .

   הפעלת Cloud Shell

3. יוצרים או בוחרים Google Cloud פרויקט.

   התפקידים שנדרשים כדי לבחור או ליצור פרויקט

   • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
   • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

   • יוצרים פרויקט ב- Google Cloud :

     gcloud projects create PROJECT_ID

     מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.

   • בוחרים את הפרויקט שיצרתם: Google Cloud

     gcloud config set project PROJECT_ID

     מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

   מחליפים את PROJECT_ID במזהה פרויקט היעד.

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

4. מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

5. מפעילים את Cloud Run API ואת Identity and Access Management (IAM) API, אם הם עדיין לא מופעלים:

   תפקידים שנדרשים להפעלת ממשקי API

   כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

   gcloud services enable run.googleapis.com iam.googleapis.com

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לפריסת הפתרון הזה, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

• כדי להעניק את התפקיד Logs Writer (כתיבת יומנים) בקטגוריית יומנים: אדמין IAM של פרויקט (roles/resourcemanager.projectIamAdmin) בפרויקט היעד
• כדי להעניק את התפקיד 'צפייה באובייקט אחסון' בקטגוריית האחסון: Storage Admin ‏ (roles/storage.admin) בפרויקט שבו מתארחת קטגוריית האחסון.
• כדי ליצור חשבון שירות: יצירת חשבונות שירות (roles/iam.serviceAccountCreator) בפרויקט היעד
• כדי להפעיל שירותים בפרויקט: אדמין של שימוש בשירותים (roles/serviceusage.serviceUsageAdmin) בפרויקט היעד
• כדי לשדרג את מאגר היומנים ולמחוק יומנים מיובאים: אדמין של Logging (roles/logging.admin) בפרויקט היעד
• כדי ליצור, להריץ ולשנות את עבודת הייבוא: Cloud Run Developer (roles/run.developer) בפרויקט היעד

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

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

שדרוג של קטגוריית היומנים כדי להשתמש ב-Observability Analytics

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

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

הערה: אחרי שמשדרגים מאגר, אי אפשר לשנמך אותו. פרטים על ההגדרות וההגבלות מופיעים במאמר שדרוג של דלי לשימוש ב-Observability Analytics.

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

• משדרגים את קטגוריית ברירת המחדל של יומנים כדי להשתמש ב-Observability Analytics:

  gcloud logging buckets update BUCKET_ID --location=LOCATION --enable-analytics
  

  מחליפים את מה שכתוב בשדות הבאים:

  • ‫BUCKET_ID: השם של קטגוריית היומנים (לדוגמה, _Default)
  • ‫LOCATION: אזור נתמך (לדוגמה, global)

יצירת משימת הייבוא של Cloud Run

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

• ב-Cloud Shell, יוצרים את הג'וב עם ההגדרות ומשתני הסביבה:

  gcloud run jobs create JOB_NAME \
  --image=IMAGE_URL \
  --region=REGION \
  --tasks=TASKS \
  --max-retries=0 \
  --task-timeout=60m \
  --cpu=CPU \
  --memory=MEMORY \
  --set-env-vars=END_DATE=END_DATE,LOG_ID=LOG_ID,\
  START_DATE=START_DATE,STORAGE_BUCKET_NAME=STORAGE_BUCKET_NAME,\
  PROJECT_ID=PROJECT_ID
  

  מחליפים את מה שכתוב בשדות הבאים:

  • ‫JOB_NAME: השם של המשימה.
  • ‫IMAGE_URL: ההפניה לתמונת הקונטיינר. אפשר להשתמש ב-us-docker.pkg.dev/cloud-devrel-public-resources/samples/import-logs-solution או בכתובת ה-URL של התמונה המותאמת אישית, אם יצרתם אותה באמצעות ההוראות ב-GitHub.
  • ‫REGION: האזור שבו רוצים שהמשימה תהיה ממוקמת. כדי להימנע מעלויות נוספות, מומלץ להשאיר את אזור המשימה באותו אזור או באותו מספר אזורים כמו אזור הקטגוריה של Cloud Storage. לדוגמה, אם הקטגוריה שלכם היא באזור רב-אזורי בארה"ב, אתם יכולים להשתמש ב-us-central1. פרטים נוספים זמינים במאמר בנושא אופטימיזציה של עלויות.
  • ‫TASKS: מספר המשימות שהג'וב צריך להריץ. ערך ברירת המחדל הוא 1. אם מתרחשים פסקי זמן, אפשר להגדיל את מספר המשימות.
  • ‫CPU: מגבלת המעבד, שיכולה להיות 1, 2, 4, 6 או 8 מעבדים. ערך ברירת המחדל הוא 2. אפשר להגדיל את המספר אם מתרחשים פסק זמן. פרטים נוספים זמינים במאמר הגדרת מגבלות על השימוש במעבד.
  • ‫MEMORY: מגבלת הזיכרון. ערך ברירת המחדל הוא 2Gi. אפשר להגדיל את המספר אם מתרחשים פסק זמן. פרטים נוספים זמינים במאמר בנושא הגדרת מגבלות זיכרון.
  • ‫END_DATE: סוף טווח התאריכים בפורמט MM/DD/YYYY. יומנים עם חותמות זמן מוקדמות יותר או שוות לתאריך הזה מיובאים.
  • ‫LOG_ID: מזהה היומן של היומנים שרוצים לייבא. מזהה היומן הוא חלק מהשדה logName ברשומה ביומן. לדוגמה, cloudaudit.googleapis.com.
  • ‫START_DATE: תחילת טווח התאריכים בפורמט MM/DD/YYYY. יומנים עם חותמות זמן שמאוחרות לתאריך הזה או שוות לו מיובאים.
  • ‫STORAGE_BUCKET_NAME: השם של קטגוריית Cloud Storage שבה נשמרים היומנים (בלי הקידומת gs://).

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

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

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

יצירת חשבון שירות להפעלת משימת Cloud Run

1. ב-Cloud Shell, יוצרים את חשבון השירות שמנוהל על ידי המשתמש:

   gcloud iam service-accounts create SA_NAME
   

   מחליפים את SA_NAME בשם של חשבון השירות.

2. מקצים את התפקיד צפייה באובייקט אחסון בקטגוריית האחסון:

   gcloud storage buckets add-iam-policy-binding gs://STORAGE_BUCKET_NAME \
   --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/storage.objectViewer
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫STORAGE_BUCKET_NAME: השם של קטגוריית האחסון שבה השתמשתם בהגדרות של עבודת הייבוא. לדוגמה, my-bucket.
   • ‫PROJECT_ID: מזהה הפרויקט של היעד.

3. מקצים את התפקיד Logs Writer בקטגוריית היומנים:

   gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/logging.logWriter
   

4. מגדירים את חשבון השירות בשביל Cloud Run Job:

   gcloud run jobs update JOB_NAME \
   --region=REGION \
   --service-account SA_NAME@PROJECT_ID.iam.gserviceaccount.com
   

   מחליפים את REGION באותו אזור שבו פרסתם את משימת הייבוא של Cloud Run.

הפעלת משימת הייבוא

• ב-Cloud Shell, מריצים את המשימה שנוצרה:

  gcloud run jobs execute JOB_NAME \
  --region=REGION
  

מידע נוסף מופיע במאמרים בנושא הפעלת משימות וניהול של הפעלות משימות.

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

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

אימות התוצאות

כדי לוודא שהייבוא הסתיים בהצלחה, אפשר להריץ שאילתה ב-Cloud Shell כדי לראות את תוצאות הייבוא:

  gcloud logging read 'log_id("imported_logs") AND timestamp<=END_DATE'

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

אפשרויות נוספות ופרטים על שליחת שאילתות לגבי רשומות ביומן מופיעים במאמר בנושא gcloud logging read.

מחיקת יומנים מיובאים

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

• כדי למחוק את היומנים שיובאו, מריצים את הפקודה למחיקת יומנים ב-Cloud Shell:

  gcloud logging logs delete imported_logs
  

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

המאמרים הבאים

• בודקים את קוד ההטמעה במאגר ב-GitHub.
• איך מנתחים יומנים מיובאים באמצעות Observability Analytics ו-SQL
• לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.

שותפים ביצירת התוכן

מחבר: לאוניד ינקולין | מהנדס קשרי מפתחים

תורמי תוכן אחרים:

• סאמיט טולאדהר | מהנדס תוכנה בכיר
• וילטון וונג | אדריכל ארגוני
• Xiang Shen | Solutions Architect