במאמר הזה מוסבר איך לפתור בעיות נפוצות ב-Storage Intelligence, בדוחות מלאי של Storage Insights, במערכי נתונים של Storage Insights ובפעולות אצווה של Storage.
שגיאות בהגדרת 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.googleapis.com/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.
פתרון: מסירים את המסננים של הדלי מהבקשה. אין תמיכה במסנני Bucket כשערך המאפיין edition_config הוא INHERIT או DISABLED.
400: ערכים ריקים של מיקום או של דלי במסנן
הבעיה: הבקשה מחזירה את השגיאה 400 Bad Request עם ההודעה Empty
location or bucket values in filter.
הפתרון: מוודאים שאף אחד מהערכים location ו-bucket הוא לא מחרוזת ריקה במסנן הקטגוריות.
בעיות נפוצות ב-Storage Insights
בקטע הזה מוסבר איך לפתור בעיות נפוצות שקשורות לדוחות מלאי שטחי הפרסום ולמערכי נתונים.
כמה דוחות מלאי שנוצרים מדי יום
בעיה: הגדרה של דוח מלאי יוצרת כמה קובצי דוחות בכל יום.
פתרון: מערכת Cloud Storage מפצלת דוחות מלאי של קטגוריות עם יותר ממיליון אובייקטים, ויוצרת פיצול אחד לכל מיליון אובייקטים. לדוגמה, בקטגוריה עם 3,500,000 אובייקטים נוצרים ארבעה רסיסי דוחות וקובץ מניפסט שמפרט כל רסיס.
דוחות המלאי לא מופיעים בקטגוריית היעד
בעיה: דוחות המלאי לא מופיעים בקטגוריית היעד.
הפתרון: אם הדוחות לא מועברים לקטגוריית היעד, צריך לוודא את הדברים הבאים:
מוודאים שתאריך ההתחלה שהוגדר חלף. מידע נוסף זמין במאמר בנושא יצירת הגדרות לדוח מלאי.
בודקים את ההיסטוריה של דוחות המלאי כדי לראות אם יש כשלים ואת הסיבות הבסיסיות שלהם. כדי לראות את ההיסטוריה של דוחות המלאי, פועלים לפי השלבים הבאים:
- במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
ברשימת הקטגוריות, לוחצים על השם של קטגוריית המקור שמכילה את ההגדרה של דוח המלאי.
בדף Bucket details, לוחצים על הכרטיסייה Inventory reports.
ברשימת ההגדרות של דוחות המלאי, לוחצים על ה-UUID של ההגדרה של דוח המלאי שממנה נוצרו הדוחות שרוצים לבדוק.
בודקים אם יש כשלים בקטע היסטוריה של דוח המלאי. אפשר להעביר את העכבר מעל עזרה () כדי לקבל פרטים על הסיבה לכישלון.
- במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
מוודאים שסוכן השירות ברמת הפרויקט קיבל את תפקידי ה-IAM שנדרשים לקריאה ולכתיבה של דוחות מלאי. מידע נוסף זמין במאמר הענקת התפקידים הנדרשים לסוכן השירות.
עיכובים בדוחות מלאי
בעיה: יש עיכוב בהפקת דוח המלאי.
פתרון: משך הזמן הדרוש ליצירת הדוח משתנה. עיכובים של עד 24 שעות הם תקינים.
מערכי הנתונים לא מתמלאים
הבעיה: הטבלאות של קבוצת נתוני Storage Insights נשארות ריקות.
פתרון: במערך הנתונים המקושר ב-BigQuery, בודקים את error_attributes_view כדי לראות את קודי השגיאה. מידע נוסף זמין במאמר פתרון בעיות במערכי נתונים.
ערכים ריקים בעמודה ref כשמריצים שאילתות על מערכי נתונים
בעיה: כשמריצים שאילתות על מערכי נתונים של Storage Insights ב-BigQuery, העמודה ref מחזירה את הערך null.
הפתרון: עבור אובייקטים שמסתיימים ב-/, העמודה ref במערכי הנתונים היא null.
אם השאילתה שלכם במערכי נתונים של Storage Insights ב-BigQuery מחזירה ערכי null בעמודה ref, צריך לוודא שהענקתם את ההרשאות והתפקידים הנדרשים לחיבור, כולל גישה למשאבי Cloud Storage, כמו שמתואר במאמר ניתוח נתוני אובייקטים ומטא-נתונים באמצעות BigQuery.
שגיאות באימות של עבודות שכוללות פעולות רבות על פריטי אחסון
בקטע הזה מתוארות שגיאות אימות שמתרחשות כששולחים בקשה למשימת פעולות באצווה אל 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_SPECIFIEDBUCKET_LIST_EMPTYTOO_MANY_BUCKETSMULTI_BUCKET_NOT_SUPPORTEDBUCKET_NAME_REQUIREDOBJECT_CONFIGURATION_REQUIRED
פתרון: מוודאים שהגדרתם בעבודת ה-ETL מקור נתונים תקין (bucket_list או project_source), ושלכל קטגוריה מוגדרת שיטה לבחירת אובייקטים. מידע נוסף מופיע במאמר בנושא יצירה וניהול של משימות של פעולות בכמות גדולה.
400: שם הקטגוריה או האובייקט לא תקין
הבעיה: הבקשה ליצירת משרה מחזירה תגובה מסוג 400 Bad Request
(INVALID_ARGUMENT) עם הסיבה BUCKET_NAME_INVALID או OBJECT_NAME_INVALID.
הפתרון: מוודאים שכל השמות של הקטגוריות והאובייקטים עומדים בדרישות למתן שמות ב-Cloud Storage. מידע נוסף זמין במאמרים הנחיות למתן שמות לקטגוריות והנחיות למתן שמות לאובייקטים.
400: שגיאות בהגדרת המקור של הפרויקט
הבעיה: הבקשה ליצירת משרה מחזירה תגובה מסוג 400 Bad Request
(INVALID_ARGUMENT) עם אחת מהסיבות הבאות:
PROJECT_SOURCE_PROJECT_INVALIDPROJECT_SOURCE_DRY_RUN_FIELDS_EXCLUSIVEPROJECT_SOURCE_DRY_RUN_ID_INVALID
פתרון: מוודאים שהגדרת המקור של הפרויקט עומדת בדרישות הפורמט והשדות הבלעדיים. אם מציינים מזהה של משימת הרצה יבשה, צריך להשמיט את כל הפרמטרים האחרים של project_source. מידע נוסף מופיע במאמר יצירת משימה באמצעות מסננים מתקדמים.
400: פרמטרים של טרנספורמציה חסרים או סותרים
הבעיה: הבקשה ליצירת משרה מחזירה תגובה מסוג 400 Bad Request
(INVALID_ARGUMENT) עם אחת מהסיבות הבאות:
TRANSFORMATION_NOT_SPECIFIEDREWRITE_OBJECT_MISSING_PARAMETERSPUT_OBJECT_HOLD_MISSING_PARAMETERSPUT_METADATA_MISSING_PARAMETERS
פתרון: צריך לציין בדיוק סוג אחד של טרנספורמציה עם כל הפרמטרים הנדרשים. אם מגדירים שמירת אובייקטים, צריך לוודא שנעילת אובייקטים מופעלת בקטגוריה ושהחותמות הזמן הן בפורמט 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_OLDTARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIMEBUCKET_DISCOVERY_TOO_MANY_BUCKETS
פתרון: מוודאים ש-snapshot_time הוא ב-48 השעות האחרונות, מציינים את target_locations עבור הקטגוריות ומוודאים ששאילתת הגילוי לא תואמת ליותר מ-1,000 קטגוריות. למידע נוסף, אפשר לעיין במאמר בנושא יצירת קובץ מניפסט באמצעות מערכי נתונים של Storage Insights.
400: המרת סוג האחסון נכשלת בקטגוריות שמופעל בהן סיווג אוטומטי
הבעיה: הבקשה ליצירת משימה מחזירה תגובה מסוג 400 Bad Request
(FAILED_PRECONDITION) עם הסיבה AUTOCLASS_STORAGE_CLASS_TRANSFORMATION_UNSUPPORTED.
פתרון: אי אפשר להריץ המרות של סוגי אחסון בקטגוריות שמופעל בהן סיווג אוטומטי. אפשר לטרגט קטגוריה בלי סיווג אוטומטי או להסיר את הטרנספורמציה של סוג האחסון. מידע נוסף זמין במאמר בנושא הגבלות על Autoclass.
400: עדכונים של ACL של אובייקטים נכשלים בקטגוריות עם גישה אחידה ברמת הקטגוריה
הבעיה: הבקשה ליצירת משימה מחזירה תגובה מסוג 400 Bad Request
(FAILED_PRECONDITION) עם הסיבה UBLA_OBJECT_ACL_UPDATE_UNSUPPORTED.
הפתרון: אי אפשר לעדכן רשימות ACL של אובייקטים בקטגוריות שמופעלת בהן גישה אחידה ברמת הקטגוריה. במקום זאת, אפשר לנהל את הגישה באמצעות תפקידי IAM ברמת הקטגוריה או הפרויקט. מידע נוסף זמין במאמר בנושא גישה אחידה ברמת הקטגוריה.
בעיות בזמן הריצה ובביצוע של פעולות רבות על פריטי אחסון
בקטע הזה מתוארות בעיות שמתרחשות במהלך ביצוע אסינכרוני של משימת פעולות אצווה.
403: שגיאות הרשאה במהלך הביצוע
הבעיה: משימת אצווה נכשלת במהלך הביצוע עם השגיאה 403 Forbidden
(PERMISSION_DENIED).
פתרון: צריך להקצות לסוכן השירות של פעולות באצווה ב-Storage (service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.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 את יומני השגיאות של כל אובייקט. מידע נוסף זמין במאמר קבלת פרטי משרה.
משימה של פעולות רבות על פריטי אחסון נכשלת בגלל תמונת מצב שנוצרה לפני יותר מיומיים
הבעיה: כשיוצרים משימת פעולות אצווה לאחסון שמבוססת על מסנן CEL, יצירת המשימה נכשלת. בהודעת השגיאה מצוין שחלפו יותר מיומיים מאז צילום התמונה.
פתרון: כדי למנוע פעולות על מצבי אובייקט לא עדכניים, פעולות אצווה של אחסון גורמות באופן אוטומטי ליצירת משימה שנכשלה. השגיאה הזו מתרחשת אם ה-snapshot שנבחר ישן יותר מיומיים. כדי לפתור את הבעיה, בוחרים אחת מהשיטות הבאות:
- שימוש בקובץ מניפסט: מריצים שאילתה במערך הנתונים באופן ידני ב-BigQuery. מייצאים את התוצאות לקובץ מניפסט CSV ומעלים את הקובץ לקטגוריה של Cloud Storage. אחר כך תוכלו ליצור את משימת הפעולות באצווה באמצעות שיטת המניפסט כדי לעקוף את המגבלה של יומיים.
- בודקים את ההגדרות של קבוצות הנתונים: מוודאים שההגדרות של קבוצות הנתונים פעילות ולא מושהות. מוודאים שצילומי מצב של מערך הנתונים פועלים בהצלחה. במאמר צפייה בהגדרות של מערך נתונים מוסבר איך מאמתים את ההגדרות.
- שימוש בביטולים של מיקום היעד ושל זמן הצילום: מציינים את הדגל
--target-snapshot-timeכדי לעקוף את הכשל של נתונים לא עדכניים בני יומיים, על ידי בחירה מפורשת של צילום מצב בפורמט RFC 3339. מציינים את הדגל--target-locationsכדי להגביל את הפעולה למיקומים שבהם קיים התצלום. אפשר להשתמש בהגדרות האלה כדי לפתור בעיות של עיכובים בסנכרון שמונעים את העדכון של התמונה הגלובלית האוטומטית. לכן, אתם יכולים לטרגט ידנית תמונת מצב אזורית עדכנית יותר. למידע על תחביר הפקודה, אפשר לעיין במאמר יצירת משימה באמצעות מסננים מתקדמים.
משימה של פעולות רבות על פריטי אחסון שמבוססת על מסנן CEL נכשלת בפרויקטים שנרשמו לאחרונה
בעיה: הפעלת משימת אחסון של פעולות אצווה שמבוססת על מסנן CEL בפרויקט חדש שנרשמתם אליו נכשלת כי המערכת לא מוצאת תמונת מצב תקינה.
פתרון: אחרי שמפעילים את המינוי ל-Storage Intelligence, צריך להמתין 24 שעות לפני שמריצים משימות של פעולות אצווה לאחסון שמבוססות על מסנני CEL. העיכוב הזה מאפשר למערכת לבצע את צילום המטא-נתונים הראשוני ולקבוע את זמן ההתחלה של צילום המצב.
משימת פעולות אצווה לאחסון שמבוססת על מסנן CEL נכשלת עם שגיאות הרשאות או עם שגיאות זמן ריצה
הבעיה: משימה של פעולות אצווה לאחסון שמבוססת על מסנן CEL נכשלת במהלך ההרצה או מחזירה שגיאות הרשאות בזמן ריצה.
פתרון: פעולות אצווה באחסון משתמשות בפרטי הכניסה של המשתמש כדי לעבד אובייקטים. העבודה תיכשל אם אין לכם את הרשאות הקריאה או הכתיבה הנדרשות ב-IAM בקטגוריות ובאובייקטים שמוגדרים כיעדים. הבעיה הזו מתרחשת כשמסנני CEL בוחרים משאבים שאין לכם גישה אליהם. מוודאים שלחשבון שלכם יש את התפקידים Storage Admin (roles/storage.admin), Storage Object Admin (roles/storage.objectAdmin) או תפקידים מקבילים לכל הקטגוריות והאובייקטים בהיקף העבודה. במאמר שימוש בהרשאות IAM מוסבר איך מקצים תפקידים.
מעקב וניתוח יומנים
מידע נוסף על בדיקת כשלים בהרצת פעולות על אובייקטים ספציפיים ומטעני שגיאות ב-Cloud Logging זמין במאמר הצגת יומנים של פעולות אצווה ב-Cloud Storage.
בעיות ביועץ Storage Intelligence
בקטע הזה מוסבר איך לפתור בעיות נפוצות שנתקלים בהן בשימוש בכלי הייעוץ של Storage Intelligence.
שגיאות מסוג 'נדחתה הרשאה' בכלי Storage Intelligence Advisor
הבעיה: כשניגשים ליועץ Storage Intelligence, מוצגת השגיאה Permission denied, והתרשימים והמדדים ריקים או שמוצגות שגיאות הרשאה.
הפתרון: הבעיה הזו מתרחשת אם אין לכם תפקיד IAM עם ההרשאות הנדרשות לצפייה בכלי Storage Intelligence Advisor. מבקשים מהאדמין להקצות לכם את התפקיד 'אדמין לניהול אחסון' (roles/storage.admin) בפרויקט, בתיקייה או בארגון שרוצים להציג. רשימת ההרשאות הנדרשות מופיעה במאמר תפקידים נדרשים.
אין הרשאות מספיקות כדי להציג פרויקט מושפע
בעיה: כשמציגים ממצאים ברמת הארגון או התיקייה, בחלונית Projects with findings detected מוצג אינדיקטור אזהרה עם ההודעה You've insufficient permission to access this project לצד פרויקט.
פתרון: הבעיה הזו מתרחשת אם יש לכם הרשאות לצפייה ביועץ Storage Intelligence ברמת הארגון או התיקייה, אבל חסרות לכם הרשאות ה-IAM הנדרשות בפרויקט הספציפי הזה. צריך לבקש מאדמין הפרויקט להקצות לכם את התפקיד Storage Admin (roles/storage.admin) בפרויקט הרלוונטי.
היועץ בנושא ניהול אחסון ריק או שחסרים בו נתונים
הבעיה: הדף של Storage Intelligence נטען, אבל התרשימים והמדדים בקטע 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 בפעם הראשונה. אם אתם מצפים לראות נתוני פעילות אחרונה, כדאי להמתין 48 שעות ואז לבדוק שוב.
- No storage resources: אם הפרויקט, התיקייה או הארגון שנבחרו לא מכילים קטגוריות או אובייקטים לתקופת הזמן שנבחרה, הכלי Storage Intelligence advisor יהיה ריק. בוחרים פרויקט, תיקייה או ארגון אחרים שמכילים משאבי אחסון.
- מסנן זמן שגוי: מסנן הזמן מוגדר לטווח שבו לא הייתה פעילות אחסון. משנים את מסנן הזמן לטווח שכולל את פעילות האחסון.
הממצאים לא מופיעים בכלי Storage Intelligence Advisor
בעיה: אתם מצפים לראות ממצאים בקטע הממצאים העיקריים על סמך פעילות אחרונה באחסון, אבל הקטע ריק.
פתרון: הבעיה הזו מתרחשת אם הכלי Storage Intelligence Advisor לא מפיק ממצאים לגבי התקופה שנבחרה. יכולות להיות כמה סיבות לכך שלא נמצאו ממצאים:
- לא נמצאו דפוסים תואמים: לא זוהה במחזור הניתוח האחרון התנהגות אחסון שתואמת לדפוס של ממצא.
- עיכובים בעיבוד הנתונים: הממצאים מבוססים על מדדי אחסון, שנדרשות 24 עד 48 שעות לעיבוד שלהם. ממצאים לגבי אירועים שהתרחשו ב-24 השעות האחרונות יופיעו אחרי סיום מחזור העיבוד הבא.
בעיות בשימוש ב-VPC Service Controls
הבעיה: כשמנסים לגשת ל-Storage Intelligence Advisor מפרויקט שנמצא בתוך גבולות גזרה לשירות של VPC Service Controls, מתקבלת הודעה על דחיית הגישה או על שגיאות הרשאה.
פתרון: הבעיה הזו מתרחשת אם VPC Service Controls לא מוגדר בצורה נכונה כדי לאפשר תקשורת בין הפרויקט, מסוף Google Cloud ומשאבי Storage Intelligence. כדי לפתור את הבעיה, צריך לעיין בדרישות הבאות:
- שירותים מוגבלים: בודקים אם גבולות גזרה לשירות מגבילים את Cloud Storage API (
storage.googleapis.com) ואת Storage Insights API (storageinsights.googleapis.com). פרטים נוספים מופיעים במאמר רשימה ותיאור של פרמטרים של שירות. - הגדרת גבולות גזרה: מוודאים שהפרויקט שבו אתם משתמשים כדי להציג את הכלי לייעוץ בנושא Storage Intelligence נמצא באותם גבולות גזרה לשירות כמו הפרויקטים שאתם מנטרים. אם הם נמצאים בהיקפים שונים, צריך להגדיר כללי כניסה ויציאה או להשתמש בגשרים בין היקפים.
- גישה מחוץ למתחם ההיקפי: אם אתם ניגשים למסוף Google Cloud מרשת שנמצאת מחוץ למתחם ההיקפי, אתם צריכים ליצור כלל תעבורת נתונים נכנסת (ingress) או רמת גישה שכוללים את חשבון המשתמש שלכם ואת טווח כתובות ה-IP הציבוריות שבהן אתם משתמשים.
- VPC משותף: אם אתם משתמשים ב-VPC משותף, ודאו שהפרויקט נמצא באותם גבולות גזרה לשירות כמו הפרויקטים של השירותים. מידע נוסף מופיע במאמר בנושא VPC משותף.
- יומני ביקורת: אפשר להשתמש בכלי לניתוח הפרות כדי לבדוק אם יש הפרות של VPC Service Controls ביומני הביקורת. כלי ניתוח ההפרות עוזר לאבחן את ההפרה ולזהות את הסיבות לה, כמו שגיאה מסוג
RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.
המאמרים הבאים
- סקירה כללית על Storage Intelligence
- הגדרה וניהול של Storage Intelligence
- יצירה וניהול של משימות להפעלת פעולות בכמות גדולה
- ניתוח נתוני אובייקטים ומטא-נתונים באמצעות BigQuery