פתרון בעיות ב-Storage Intelligence

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

שגיאות בהגדרת Storage Intelligence

בקטעים הבאים מתוארות שגיאות שעלולות להתרחש כשמגדירים או מנהלים את Storage Intelligence למשאב.

‫400: שם קטגוריה לא חוקי

הבעיה: הבקשה מחזירה את השגיאה 400 Bad Request עם ההודעה The specified bucket is not valid.

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

  • שימוש ב-locations/global. ב-Storage Intelligence אין תמיכה במיקומים אחרים.
  • צריך לוודא ששמות הקטגוריות או הביטויים הרגולריים ב-bucket_id_regexes תקינים.

דוגמה לבקשה תקינה:

curl -X PATCH \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -d '{
      "edition_config": "STANDARD",
      "filter": {
        "included_cloud_storage_buckets": {
          "bucket_id_regexes": [
            "my-bucket-name",
            "prod-data-.*"
          ]
        }
      }
    }' \
    "https://storage.s3nsapis.fr/v2/projects/PROJECT_ID/locations/global/intelligenceConfig?updateMask=edition_config,filter"

‫400: ארגומנט לא תקין – מסכת עדכון ריקה

הבעיה: כשאתם שולחים בקשה להגדרה או לעדכון, הבקשה מחזירה את השגיאה 400 Bad Request עם ההודעה Empty UPDATE_MASK in the request.

הפתרון: צריך לציין ערך בשדה UPDATE_MASK בבקשה. ‫UPDATE_MASK מציין רשימה מופרדת בפסיקים של שדות FieldMask במשאב IntelligenceConfig שצריך לעדכן (כמו updateMask=edition_config או updateMask=edition_config,filter).

‫400: נתיב מסכת העדכון לא תקין

הבעיה: כשמעדכנים הגדרה, הבקשה מחזירה את השגיאה 400 Bad Request עם ההודעה Invalid UPDATE_MASK paths.

פתרון: מוודאים שכל שם שדה ב-UPDATE_MASK תואם לשדה תקין במשאב IntelligenceConfig.

‫400: אי אפשר לערוך את השדה

הבעיה: כשמעדכנים הגדרה, הבקשה מחזירה את השגיאה 400 Bad Request עם ההודעה Invalid UPDATE_MASK: UPDATE_TIME field is not editable.

פתרון: מסירים שדות מערכת שלא ניתנים לעריכה (כמו UPDATE_TIME) מ-UPDATE_MASK. צריך לציין רק שדות שניתנים לשינוי שמוגדרים ב-IntelligenceConfig.

‫400: ערך לא חוקי

הבעיה: הבקשה מחזירה את השגיאה 400 Bad Request עם ההודעה Invalid value at storage_intelligence.edition_config.

פתרון: מגדירים את edition_config לערך נתמך: INHERIT,‏ STANDARD או DISABLED.

‫400: מסנן לא ריק

הבעיה: הבקשה מחזירה את השגיאה 400 Bad Request עם ההודעה Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration.

הפתרון: מסירים את מסנני הקטגוריות מהבקשה. אין תמיכה במסנני קטגוריות כש-edition_config מוגדר ל-INHERIT או ל-DISABLED.

‫400: ערכי מיקום או קטגוריה ריקים במסנן

הבעיה: הבקשה מחזירה את השגיאה 400 Bad Request עם ההודעה Empty location or bucket values in filter.

הפתרון: מוודאים ש-location ו-bucket הם לא מחרוזת ריקה במסנן הקטגוריות.

בעיות נפוצות בתובנות לגבי האחסון

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

כמה דוחות מלאי שנוצרים מדי יום

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

פתרון: Cloud Storage מפצל דוחות מלאי של קטגוריות עם יותר מ-1,000,000 אובייקטים, ויוצר קובץ מפוצל אחד לכל 1,000,000 אובייקטים. לדוגמה, בקטגוריה עם 3,500,000 אובייקטים נוצרים ארבעה קטעי דוח וקובץ מניפסט שמפרט כל קטע.

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

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

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

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

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

    1. במסוף Cloud de Confiance , נכנסים לדף Buckets של Cloud Storage.

      כניסה לדף Buckets

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

    3. בדף Bucket details, לוחצים על הכרטיסייה Inventory reports.

    4. ברשימת ההגדרות של דוחות המלאי, לוחצים על ה-UUID של ההגדרה של דוח המלאי שממנה יצרתם את הדוחות שאתם רוצים לבדוק.

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

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

עיכובים בדוחות המלאי

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

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

קבוצות הנתונים לא מתמלאות

הבעיה: הטבלאות של קבוצת הנתונים של Storage Insights נשארות ריקות.

פתרון: במערך הנתונים המקושר ב-BigQuery, בודקים אם יש קודי שגיאה ב-error_attributes_view. מידע נוסף זמין במאמר פתרון בעיות שקשורות לשגיאות במערך הנתונים.

ערכי Null בעמודה ref כששולחים שאילתות למערכי נתונים

הבעיה: כששולחים שאילתות למערכי נתונים של Storage Insights ב-BigQuery, העמודה ref מחזירה את הערך null.

הפתרון: באובייקטים שמסתיימים ב-/, העמודה ref במערכי הנתונים היא null.

אם העמודה ref מחזירה ערכי null כששולחים שאילתות למערכי הנתונים של Storage Insights ב-BigQuery, צריך לוודא שהענקתם את ההרשאות והתפקידים הנדרשים לחיבור, כולל גישה למשאבים של Cloud Storage, כמו שמתואר במאמר ניתוח נתונים ומטא-נתונים של אובייקטים באמצעות BigQuery.

שגיאות בהעשרת אובייקטים

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

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

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

הפתרון: בודקים את הדברים הבאים:

  • הרשאות של סוכן שירות: ודאו שאתם נותנים לסוכן השירות של העשרת האובייקטים את התפקיד roles/storage.annotationGeneratorService בקטגוריית היעד (או בפרויקט) ואת התפקיד roles/storage.bucketViewer בפרויקט. איך נותנים הרשאות לסוכן השירות?
  • הגדרת המסנן וההיקף: ודאו שהמשאב FeatureConfig כולל במפורש את שם קטגוריית היעד. ‫Cloud Storage לא כולל באופן אוטומטי קטגוריות שנוצרו אחרי שיצרתם את המשאב FeatureConfig. בנוסף, אם מוחקים קטגוריה ויוצרים אותה מחדש או מעבירים אותה, צריך לעדכן את המשאב FeatureConfig כדי לכלול אותה מחדש.
  • דרישות מוקדמות למודלים ומטא-נתונים של Content-Type: ודאו שהאובייקטים עומדים במגבלות של סוג התוכן והגודל של המודלים שהפעלתם. ‫Cloud Storage משתמש בשדה המטא-נתונים Content-Type של האובייקט כדי לקבוע את הזכאות (BMP, ‏ GIF, ‏ ICO, ‏ JPEG, ‏ PNG, ‏ TIFF או WEBP לתמונות, ו-application/pdf לסיווג קובצי PDF). אם המטא-נתונים של Content-Type חסרים או שגויים, Cloud Storage לא יעבד את האובייקט עד שתעדכנו את המטא-נתונים שלו. בנוסף, שירות העשרת האובייקטים מדלג על אובייקטים שגדולים מ-20MiB. מידע נוסף זמין במאמר מודלים וסכימות נתמכים.
  • זמן אחזור של העיבוד: צריך לתת מספיק זמן לעיבוד אסינכרוני. שירות העשרת האובייקטים מעבד אובייקטים באופן אסינכרוני. העשרות של אובייקטים שהועלו לאחרונה מופיעות בדרך כלל תוך כמה שעות. לעומת זאת, מילוי חוסרים באובייקטים קיימים בקטגוריות גדולות יכול להימשך שעות או ימים.

העשרת אובייקטים לא מופיעה ב-BigQuery

הבעיה: העשרת האובייקטים מופיעה ב-API אבל לא ב-BigQuery.

הפתרון: בודקים את הדברים הבאים:

  • הגדרת מערכי הנתונים של Storage Insights: ודאו שהגדרתם את מערכי הנתונים של Storage Insights לקטגוריה.
  • תזמון דוחות יומי: צריך להמתין לעדכון היומי של מערך הנתונים. מערכי הנתונים של Storage Insights מתעדכנים כל 24 שעות. לכן, יכול להיות שיעברו עד 24 שעות לפני שההעשרות החדשות יופיעו בתצוגה object_contexts_catalog_view ב-BigQuery.
  • הרשאות IAM: ודאו שיש לכם הרשאות להריץ משימות ולקרוא נתונים ב-BigQuery (כמו roles/bigquery.jobUser ו-roles/bigquery.dataViewer). להנחיות לגבי שאילתות, קראו את המאמר ניתוח העשרת אובייקטים ב-BigQuery.

ההרשאה נדחתה במהלך אחזור נתונים מורחבים של העשרת אובייקטים

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

הפתרון: כדי לאחזר נתונים מורחבים, כמו קואורדינטות של תיבה תוחמת או ציוני מהימנות של קטגוריות, צריכה להיות לכם הרשאת storage.objects.viewFullContext לאובייקט או לקטגוריה. תפקידים כמו Storage Object User‏ (roles/storage.objectUser) ו-Storage Admin‏ (roles/storage.admin) כוללים את ההרשאה הזו. מידע נוסף זמין במאמר ניהול העשרת אובייקטים.

ההרשאה נדחתה במהלך ניהול הגדרות התכונות

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

הפתרון: מוודאים שבחשבון שלכם יש את התפקיד "אדמין באחסון" (roles/storage.admin) או תפקיד בהתאמה אישית עם ההרשאות הנדרשות בפרויקט היעד. ההרשאות הנדרשות האלה כוללות את storage.featureConfigs.create, storage.featureConfigs.update או storage.featureConfigs.delete. כדי לראות את ההרשאות הספציפיות לכל שיטה, קראו את המאמר הגדרת העשרת אובייקטים ואת המידע על משאב ה-API של featureConfigs.

שגיאות באימות של משימות לביצוע פעולות רבות על פריטי אחסון

בקטע הזה מתוארות שגיאות אימות שמתרחשות כששולחים בקשה למשימת פעולות באצווה אל storagebatchoperations.googleapis.com.

‫400: מזהה משימה או שם משאב לא תקינים

הבעיה: הבקשה ליצירת משימה מחזירה תשובה מסוג 400 Bad Request (INVALID_ARGUMENT) עם הסיבה JOB_ID_INVALID או RESOURCE_NAME_TOO_LONG.

פתרון: ודאו שמזהה המשימה מורכב מ-1 עד 63 תווים אלפאנומריים באותיות קטנות או מקפים ([a-z0-9]([-a-z0-9]*[a-z0-9])?), ושנתיב המשאב המלא של המשימה (projects/PROJECT_ID/locations/LOCATION/jobs/JOB_ID) לא חורג מ-200 בייטים. אם הנתיב ארוך מ-200 בייטים, צריך לקצר את מזהה המשימה. מידע נוסף זמין בקטע שם המשימה.

‫400: תיאור המשרה חורג מהמגבלה

הבעיה: הבקשה ליצירת משימה מחזירה תשובה מסוג 400 Bad Request (INVALID_ARGUMENT) עם הסיבה DESCRIPTION_TOO_LONG.

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

‫400: הגדרות מקור המשימה חסרות או לא תקינות

הבעיה: הבקשה ליצירת משימה מחזירה תשובה מסוג 400 Bad Request (INVALID_ARGUMENT) עם אחת מהסיבות הבאות:

  • SOURCE_NOT_SPECIFIED
  • BUCKET_LIST_EMPTY
  • TOO_MANY_BUCKETS
  • MULTI_BUCKET_NOT_SUPPORTED
  • BUCKET_NAME_REQUIRED
  • OBJECT_CONFIGURATION_REQUIRED

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

‫400: שם לא תקין של קטגוריה או אובייקט

הבעיה: הבקשה ליצירת משימה מחזירה תשובה מסוג 400 Bad Request (INVALID_ARGUMENT) עם הסיבה BUCKET_NAME_INVALID או OBJECT_NAME_INVALID.

הפתרון: ודאו שכל השמות של הקטגוריות והאובייקטים עומדים בדרישות של Cloud Storage למתן שמות. מידע נוסף זמין בקטעים Bucket naming guidelines ו-Object naming guidelines.

‫400: שגיאות בהגדרת מקור הפרויקט

הבעיה: הבקשה ליצירת משימה מחזירה תשובה מסוג 400 Bad Request (INVALID_ARGUMENT) עם אחת מהסיבות הבאות:

  • PROJECT_SOURCE_PROJECT_INVALID
  • PROJECT_SOURCE_DRY_RUN_FIELDS_EXCLUSIVE
  • PROJECT_SOURCE_DRY_RUN_ID_INVALID

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

‫400: פרמטרים של טרנספורמציה חסרים או סותרים

הבעיה: הבקשה ליצירת משימה מחזירה תגובה מסוג 400 Bad Request (INVALID_ARGUMENT) עם אחת מהסיבות הבאות:

  • TRANSFORMATION_NOT_SPECIFIED
  • REWRITE_OBJECT_MISSING_PARAMETERS
  • PUT_OBJECT_HOLD_MISSING_PARAMETERS
  • PUT_METADATA_MISSING_PARAMETERS

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

‫400: קידומות של אובייקטים חופפים או כפולים

הבעיה: הבקשה ליצירת משימה מחזירה תשובה מסוג 400 Bad Request (INVALID_ARGUMENT) עם הסיבה OBJECT_PREFIX_OVERLAP או DUPLICATE_OBJECT_PREFIX.

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

‫400: בעיות בפורמט של קובץ המניפסט ובגישה אליו

הבעיה: הבקשה ליצירת משימה מחזירה תגובה מסוג 400 Bad Request (INVALID_ARGUMENT) עם הסיבה MANIFEST_LOCATION_REQUIRED או MANIFEST_LOCATION_INVALID, או שהמשימה לא יכולה לקרוא את המניפסט.

פתרון: מוודאים שה-URI של המניפסט הוא נתיב CSV תקין (gs://<bucket_name>/<path>/<object_name>.csv) ושלסוכן השירות של פעולות רבות על פריטי אחסון יש את התפקיד roles/storage.objectViewer בקטגוריית המניפסט. מידע נוסף על דרישות העיצוב והסכימה של קובצי CSV זמין במאמר מניפסט.

‫400: שגיאות בגילוי של קבוצת נתוני Storage Insights

הבעיה: שימוש במערך נתונים של Storage Insights לגילוי אובייקטים מחזיר תגובה מסוג 400 Bad Request (INVALID_ARGUMENT או FAILED_PRECONDITION) עם אחת מהסיבות הבאות:

  • BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD
  • TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME
  • BUCKET_DISCOVERY_TOO_MANY_BUCKETS

הפתרון: מוודאים שהערך של snapshot_time הוא בטווח של 48 השעות האחרונות, מציינים את target_locations לקטגוריות ומוודאים ששאילתת הגילוי תואמת ל-1,000 קטגוריות לכל היותר. מידע נוסף זמין במאמר יצירת מניפסט באמצעות מערכי נתונים של Storage Insights.

‫400: שינוי סוג האחסון נכשל בקטגוריות שבהן מופעלת התכונה Autoclass

הבעיה: הבקשה ליצירת משימה מחזירה את התגובה 400 Bad Request (FAILED_PRECONDITION) עם הסיבה AUTOCLASS_STORAGE_CLASS_TRANSFORMATION_UNSUPPORTED.

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

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

הבעיה: הבקשה ליצירת משימה מחזירה את התגובה 400 Bad Request (FAILED_PRECONDITION) עם הסיבה UBLA_OBJECT_ACL_UPDATE_UNSUPPORTED.

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

בעיות בזמן הריצה ובביצוע של פעולות רבות על פריטי אחסון

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

‫403: שגיאות הרשאה במהלך ההפעלה

הבעיה: משימת אצווה נכשלת במהלך ההרצה עם השגיאה 403 Forbidden (PERMISSION_DENIED).

פתרון: מקצים לסוכן השירות של פעולות רבות על פריטי אחסון (service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.s3ns-system.iam.gserviceaccount.com) את תפקידי ה-IAM שנדרשים לסוג הטרנספורמציה. מידע נוסף זמין במאמר מתן הרשאות לסוכן השירות.

שגיאות בהצפנת CMEK במהלך כתיבה מחדש של אובייקטים

הבעיה: שכתובים של אובייקטים נכשלים עם שגיאות 400 Bad Request או 403 Forbidden בגלל סטטוס המפתח של Cloud KMS או שגיאות בהרשאות.

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

מספר גבוה של כשלים ב-error_summaries

הבעיה: משימת אצווה מסתיימת עם ערך שאינו אפס ב-counters.failed_object_count וקודי שגיאה ב-error_summaries (כמו 404 NOT_FOUND,‏ 412 FAILED_PRECONDITION או 403 PERMISSION_DENIED).

הפתרון: מריצים את gcloud storage batch-operations jobs describe עם הדגל --location (לדוגמה, gcloud storage batch-operations jobs describe JOB_ID --location=LOCATION) כדי לראות את פירוט השגיאות המצטברות, ובודקים ב-Cloud Logging את יומני השגיאות לכל אובייקט. מידע נוסף זמין במאמר קבלת פרטי משימה.

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

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

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

  • שימוש בקובץ מניפסט: שליחת שאילתה ידנית על מערך הנתונים ב-BigQuery. מייצאים את התוצאות לקובץ מניפסט בפורמט CSV ומעלים את הקובץ לקטגוריה של Cloud Storage. לאחר מכן, תוכלו ליצור את המשימה של פעולות באצווה באמצעות שיטת המניפסט כדי להימנע מהמגבלה של יומיים.
  • בודקים את ההגדרות של קבוצות הנתונים: מוודאים שההגדרות של קבוצות הנתונים פעילות ולא מושהות. מוודאים שהתמונות של מערך הנתונים פועלות כמו שצריך. במאמר הצגת ההגדרות של מערך נתונים מוסבר איך לאמת את ההגדרות.
  • שימוש במיקום יעד גיאוגרפי ובשינוי מברירת המחדל של זמן תמונת המצב: מציינים את הדגל --target-snapshot-time כדי לעקוף את כשל ההתיישנות של יומיים, על ידי בחירה מפורשת של תמונת מצב בפורמט RFC 3339. מציינים את הדגל --target-locations כדי להגביל את הפעולה למיקומים שבהם קיימת קבוצת הנתונים של המצב הנוכחי. אתם יכולים להשתמש בשינויים האלה כדי לפתור עיכובים בסנכרון שמונעים את העדכון של תמונת המצב הגלובלית האוטומטית. לכן, אתם יכולים לטרגט באופן ידני תמונת מצב אזורית עדכנית יותר. תחביר הפקודה מפורט במאמר יצירת משימה באמצעות מסננים מתקדמים.

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

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

פתרון: אחרי שמפעילים את המינוי ל-Storage Intelligence, צריך לחכות 24 שעות לפני שמריצים משימות של פעולות רבות על פריטי אחסון שמבוססות על מסנני CEL. ההשהיה הזו מאפשרת למערכת לבצע את תמונת המצב הראשונית של המטא-נתונים ולקבוע את זמן תמונת המצב הראשונית.

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

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

הפתרון: פעולות רבות על פריטי אחסון משתמשות בפרטי הכניסה של המשתמש כדי לעבד אובייקטים. המשימה תיכשל אם אין לכם את הרשאות הקריאה או הכתיבה הנדרשות ב-IAM בקטגוריות ובאובייקטים המטורגטים. הבעיה הזו מתרחשת כשמסנני ה-CEL בוחרים משאבים שאין לכם גישה אליהם. מוודאים שבחשבון שלכם יש את התפקידים "אדמין של Storage"‏ (roles/storage.admin), "אדמין של אובייקט אחסון" (roles/storage.objectAdmin) או תפקידים מקבילים לכל הקטגוריות והאובייקטים בהיקף של המשימה. במאמר שימוש בהרשאות IAM מוסבר איך מקצים תפקידים.

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

במאמר צפייה ביומנים של פעולות רבות על פריטי אחסון מוסבר איך בודקים ב-Cloud Logging את השגיאות והמטענים הייעודיים (payloads) של השגיאות בכל אובייקט.

בעיות ב-Storage Intelligence Advisor

בקטע הזה מוסבר איך לפתור בעיות נפוצות שבהן נתקלים כשמשתמשים ב-Storage Intelligence advisor.

שגיאות מסוג "אין הרשאה" ב-Storage Intelligence advisor

הבעיה: כשאתם ניגשים ל-Storage Intelligence advisor, אתם מקבלים את השגיאה Permission denied, והתרשימים והמדדים ריקים או שמופיעות בהם שגיאות שקשורות להרשאות.

הפתרון: הבעיה הזו מתרחשת אם אין לכם תפקיד IAM עם ההרשאות הנדרשות כדי לצפות ב-Storage Intelligence advisor. מבקשים מהאדמין להקצות לכם את התפקיד "אדמין של Storage" (roles/storage.admin) בפרויקט, בתיקייה או בארגון שאתם רוצים לראות. רשימת ההרשאות הנדרשות מופיעה בקטע התפקידים הנדרשים.

אין מספיק הרשאות כדי לראות פרויקט שהושפע

הבעיה: כשמציגים ממצאים ברמת הארגון או התיקייה, בחלונית Projects with findings detected מופיע סמל אזהרה עם ההודעה You've insufficient permission to access this project ליד הפרויקט.

הפתרון: הבעיה הזו מתרחשת אם יש לכם הרשאות לצפות ביועץ Storage Intelligence ברמת הארגון או התיקייה, אבל אין לכם את הרשאות ה-IAM הנדרשות בפרויקט הספציפי הזה. מבקשים מהאדמין של הפרויקט להקצות לכם את התפקיד "אדמין של Storage" (roles/storage.admin) בפרויקט הרלוונטי.

היועץ של Storage Intelligence ריק או שחסרים נתונים

הבעיה: טעינת הדף של Storage Intelligence advisor, והתרשימים, המדדים בקטע At a glance (עם התווית Project at a glance,‏ Folder at a glance או Organization at a glance בהתאם למשאב שנבחר) או הקטע Top findings ריקים או שהנתונים לא עדכניים.

פתרון: הבעיה הזו יכולה לקרות מהסיבות הבאות:

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

הממצאים לא מופיעים ב-Storage Intelligence Advisor

הבעיה: אתם מצפים לראות ממצאים בקטע Top findings על סמך פעילות האחסון האחרונה, אבל הקטע ריק.

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

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

בעיות בשימוש ב-VPC Service Controls

הבעיה: כשמנסים לגשת ל-Storage Intelligence advisor מפרויקט שנמצא בתוך גבולות גזרה לשירות של VPC Service Controls, מקבלים הודעות שגיאה לגבי דחיית גישה או הרשאות.

הפתרון: הבעיה הזו מתרחשת אם VPC Service Controls לא מוגדר כמו שצריך כדי לאפשר תקשורת בין הפרויקט, מסוף Cloud de Confiance והמשאבים של Storage Intelligence. כדי לפתור את הבעיה, צריך לעבור על הדרישות הבאות:

  • שירותים מוגבלים: בודקים אם גבולות הגזרה לשירות מגבילים את Cloud Storage API‏ (storage.googleapis.com) ואת Storage Insights API‏ (storageinsights.googleapis.com). פרטים נוספים זמינים במאמר רשימה ותיאור של פרמטרים של שירות.
  • הגדרת גבולות גזרה: ודאו שהפרויקט שבו אתם משתמשים כדי לצפות ב-Storage Intelligence Advisor נמצא באותם גבולות גזרה לשירות כמו הפרויקטים שאתם עוקבים אחריהם. אם הם נמצאים בהיקפי שירות שונים, צריך להגדיר כללי כניסה ויציאה או להשתמש בגשרים של היקפי שירות.
  • גישה מחוץ למתחם: אם אתם ניגשים למסוף Cloud de Confiance מרשת שנמצאת מחוץ למתחם, אתם צריכים ליצור כלל תעבורת נתונים נכנסת (ingress) או רמת גישה שכוללת את חשבון המשתמש שלכם ואת טווח כתובות ה-IP הציבוריות שבהן אתם משתמשים.
  • ‫VPC משותף: אם אתם משתמשים ב-VPC משותף, ודאו שהפרויקט נמצא באותם גבולות גזרה לשירות כמו פרויקטי השירות שלכם. פרטים נוספים זמינים במאמר VPC משותף.
  • יומני ביקורת: משתמשים בכלי לניתוח הפרות כדי לבדוק אם יש הפרות של VPC Service Controls ביומני הביקורת. הכלי לניתוח הפרות עוזר לאבחן את ההפרה ולזהות את הגורמים לה, כמו שגיאת RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

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