פתרון בעיות

בדף הזה מתוארות שיטות לפתרון בעיות נפוצות שלפעמים נתקלים בהן במהלך השימוש ב-Cloud Storage.

בGoogle Cloud Service Health Dashboard אפשר למצוא מידע על אירועים שמשפיעים על שירותים כמו Cloud Storage. Google Cloud

רישום בקשות גולמיות ביומן

בעבודה עם כלים כמו gcloud או ספריות הלקוח של Cloud Storage, הכלי מטפל ברוב המידע על הבקשות והתשובות. אבל לפעמים צריך לדעת פרטים שיכולים לעזור לפתור בעיות, או כשרוצים לפרסם שאלות בפורומים כמו Stack Overflow. אפשר להיעזר בהוראות הבאות כדי לקבל את הכותרות של הבקשות והתשובות בכלי שלכם:

המסוף

ההצגה של פרטי הבקשות והתשובות משתנה בהתאם לדפדפן שדרכו אתם נכנסים למסוף Google Cloud . בדפדפן Google Chrome:

לוחצים על לחצן התפריט הראשי של Chrome‏ ().
בוחרים באפשרות More Tools.
לוחצים על Developer Tools.
בחלונית שמופיעה, לוחצים על הכרטיסייה Network.

שורת הפקודה

משתמשים בדגלים גלובליים לניפוי באגים בבקשה. לדוגמה:

gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug

ספריות לקוח

C++‎

מגדירים את משתנה הסביבה CLOUD_STORAGE_ENABLE_TRACING=http כדי לקבל את כל תעבורת ה-HTTP.
מגדירים את משתנה הסביבה CLOUD_STORAGE_ENABLE_CLOG=yes כדי לקבל רישומי יומן של כל RPC.

C#‎

מוסיפים יומן דרך ApplicationContext.RegisterLogger ומגדירים אפשרויות רישום ביומן ב-handler של הודעת HttpClient. מידע נוסף זמין במאמרי העזרה לספריית הלקוח של C# ‎.

Go

מגדירים את משתנה הסביבה GODEBUG=http2debug=1. מידע נוסף אפשר למצוא ב-Go package net/http.

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

Java

יוצרים קובץ בשם logging.properties עם התוכן הבא:

# Properties file which configures the operation of the JDK logging facility.
# The system will look for this config file to be specified as a system property:
# -Djava.util.logging.config.file=${project_loc:googleplus-simple-cmdline-sample}/logging.properties

# Set up the console handler (uncomment "level" to show more fine-grained messages)
handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = CONFIG

# Set up logging of HTTP requests and responses (uncomment "level" to show)
com.google.api.client.http.level = CONFIG

משתמשים ב-log.properties עם Maven

mvn -Djava.util.logging.config.file=path/to/logging.properties insert_command

מידע נוסף אפשר למצוא במאמר שעוסק ב-Pluggable HTTP Transport.

Node.js

צריך להגדיר את משתנה הסביבה NODE_DEBUG=https לפני קריאה לסקריפט של הצומת.

PHP

מציינים handler ‏HTTP משלכם ללקוח באמצעות httpHandler, ומגדירים תווכה לרישום הבקשה והתשובה ביומן.

Python

משתמשים במודול הרישום ביומן. לדוגמה:

import logging
import http.client

logging.basicConfig(level=logging.DEBUG)
http.client.HTTPConnection.debuglevel=5

Ruby

בחלק העליון של .rb file אחרי require "google/cloud/storage", מוסיפים:

ruby
Google::Apis.logger.level = Logger::DEBUG

הוספת כותרות מותאמות אישית

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

שורת הפקודה

משתמשים בדגל --additional-headers, שזמין לרוב הפקודות. לדוגמה:

gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE

כש-HEADER_NAME ו-HEADER_VALUE מגדירים את הכותרת שמוסיפים לבקשה.

ספריות לקוח

C++‎

namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));

C#‎

בדוגמה הבאה רואים הוספה של כותרת מותאמת אישית לכל בקשה של ספריית הלקוח.

using Google.Cloud.Storage.V1;

var client = StorageClient.Create();
client.Service.HttpClient.DefaultRequestHeaders.Add("custom-header", "custom-value");

var buckets = client.ListBuckets("my-project-id");
foreach (var bucket in buckets)

{
  Console.WriteLine(bucket.Name);
}

Go

אפשר להוסיף כותרות מותאמות אישית לכל קריאה ל-API שמתבצעת על ידי חבילת האחסון באמצעות callctx.SetHeaders בהקשר שמועבר ל-method.

package main

import (
  "context"

  "cloud.google.com/go/storage"
  "github.com/googleapis/gax-go/v2/callctx"
)

func main() {
  ctx := context.Background()

  client, err := storage.NewClient(ctx)
  if err != nil {
    // Handle error.
  }
  ctx = callctx.SetHeaders(ctx, "X-Custom-Header", "value")

  // Use client as usual with the context and the additional headers will be sent.
  _, err = client.Bucket("my-bucket").Attrs(ctx)
  if err != nil {
    // Handle error.
  }
}

Java

import com.google.api.gax.rpc.FixedHeaderProvider;
import com.google.api.gax.rpc.HeaderProvider;
import com.google.cloud.WriteChannel;
import com.google.cloud.storage.BlobInfo;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;

import java.io.IOException;
import java.nio.ByteBuffer;
import static java.nio.charset.StandardCharsets.UTF_8;

public class Example {

  public void main(String args[]) throws IOException {
    HeaderProvider headerProvider =
            FixedHeaderProvider.create("custom-header", "custom-value");
    Storage storage = StorageOptions.getDefaultInstance()
            .toBuilder()
            .setHeaderProvider(headerProvider)
            .build().getService();
    String bucketName = "example-bucket";
    String blobName = "test-custom-header";

    // Use client with custom header
    BlobInfo blob = BlobInfo.newBuilder(bucketName, blobName).build();
    byte[] stringBytes;
    try (WriteChannel writer = storage.writer(blob)) {
      stringBytes = "hello world".getBytes(UTF_8);
      writer.write(ByteBuffer.wrap(stringBytes));
    }
  }
}

Node.js

const storage = new Storage();

storage.interceptors.push({
  request: requestConfig => {
    Object.assign(requestConfig.headers, {
      'X-Custom-Header': 'value',
      });
    return requestConfig;
  },
});

PHP

כל הפעלות ה-method שמפעילות בקשות http מקבלות גם ארגומנט $restOptions בתור הארגומנט האחרון. אפשר לתת כותרות מותאמות אישית לכל בקשה בנפרד או לכל לקוח בנפרד.

use Google\Cloud\Storage\StorageClient;

$client = new StorageClient([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bat'
       ]
   ]
]);

$bucket = $client->bucket('my-bucket');

$bucket->info([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bar'
       ]
   ]
]);

Python

from google.cloud import storage

client = storage.Client(
    extra_headers={
        "x-custom-header": "value"
    }
)

Ruby

require "google/cloud/storage"

storage = Google::Cloud::Storage.new

storage.add_custom_headers { 'X-Custom-Header'=> 'value' }

גישה לקטגוריות עם הגדרות CORS

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

לבדוק את ההגדרות של CORS בקטגוריית היעד. אם יש כמה רשומות של הגדרות CORS, צריך לוודא שערכי הבקשות שבהם אתם משתמשים לפתרון בעיות ממופים לערכים ברשומה יחידה של הגדרות CORS.
כשבודקים שליחה של בקשת CORS, צריך לוודא שלא שולחים בקשה לנקודת הקצה (endpoint) של storage.cloud.google.com, שלא מאפשרת בקשות CORS. למידע נוסף על נקודות הקצה שיש להן תמיכה ב-CORS, ראו תמיכה ב-CORS ב-Cloud Storage.
לבדוק בקשה ותגובה באמצעות הכלי הרצוי. בדפדפן Chrome, אפשר להשתמש בכלים הרגילים למפתחים כדי לראות את המידע הזה:
1. לוחצים על תפריט Chrome ‏() בסרגל הכלים של הדפדפן.
2. בוחרים באפשרות כלים נוספים > כלים למפתחים.
3. לוחצים על הכרטיסייה Network.
4. שולחים את הבקשה מהאפליקציה או משורת הפקודה.
5. מאתרים את הבקשה בחלונית שמציגה את הפעילות ברשת.
6. בעמודה Name, לוחצים על השם שתואם לבקשה.
7. לוחצים על הכרטיסייה Headers כדי לראות את כותרות התגובות. לחלופין, לוחצים על הכרטיסייה Response כדי לראות את תוכן התגובה.
אם אתם לא רואים בקשה ותגובה, יכול להיות שהדפדפן שלכם שמר במטמון ניסיון קודם שנכשל של בקשת קדם-הפעלה. ניקוי המטמון של הדפדפן אמור גם לנקות את המטמון של קדם-ההפעלה. אם לא, אפשר להגדיר את הערך של MaxAgeSec בהגדרות CORS שלכם לערך נמוך יותר מברירת המחדל של 3600 (60 דקות). אתם צריכים להמתין עד שיחלוף משך הזמן הקודם שנקבע ב-MaxAgeSec, ואז לנסות לשלוח את הבקשה שוב. הפעולה הזו מבצעת בקשת קדם-הפעלה חדשה, שמאחזרת את ההגדרות החדשות של CORS ומוחקת באופן סופי את רשומות המטמון. אחרי שסיימתם לנפות את הבאגים, אתם צריכים להגדיל את הערך של MaxAgeSec בחזרה לערך גבוה יותר כדי לצמצם את תעבורת נתוני קדם-ההפעלה לקטגוריה שלכם.
לוודא שבבקשה יש כותרת Origin, ושערך הכותרת תואם לפחות לאחד מערכי Origins בהגדרות ה-CORS של הקטגוריה. שימו לב שחייבת להיות התאמה מדויקת בין הסכימה, המארח והיציאה של הערכים. הנה כמה דוגמאות של התאמות קבילות:
- ‫http://origin.example.com תואם ל-http://origin.example.com:80 (כי 80 היא יציאת ה-HTTP שמוגדרת כברירת מחדל), אבל לא תואם ל-https://origin.example.com, http://origin.example.com:8080, http://origin.example.com:5151 או ל-http://sub.origin.example.com.
- ‫https://example.com:443 תואם ל-https://example.com אבל לא ל-http://example.com או ל-http://example.com:443.
- ‫http://localhost:8080 תואם במדויק רק ל-http://localhost:8080 ולא ל-http://localhost:5555 או ל-http://localhost.example.com:8080.
בבקשות פשוטות, מוודאים ש-method ה-HTTP של הבקשה תואמת לפחות לאחד מהערכים של Methods בהגדרות ה-CORS של הקטגוריה. בבקשות קדם-הפעלה, מוודאים שה-method שצוינה ב-Access-Control-Request-Method תואמת לפחות לאחד מהערכים של Methods.
אם זו בקשת קדם-הפעלה, צריך לבדוק אם היא כוללת כותרת Access-Control-Request-Header אחת או יותר. במקרה כזה, אתם צריכים לוודא שכל ערך של Access-Control-Request-Header תואם לערך של ResponseHeader בהגדרות ה-CORS של הקטגוריה. כדי שבקשת קדם-ההפעלה תתבצע ללא שגיאות, כל הכותרות עם השמות ב-Access-Control-Request-Header חייבות להיות בהגדרות CORS, וצריכות לכלול כותרות CORS בתגובה.

קודי שגיאה

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

‏‎301: Moved Permanently

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

הפתרון: אם הדפדפן מוריד אובייקט של אפס בייט, ומקבלים קוד תגובת HTTP 301 בניסיון גישה לספרייה, כמו http://www.example.com/dir/, כנראה שבקטגוריה יש אובייקט ריק בשם הזה. כדי לבדוק אם זאת הבעיה ולפתור אותה:

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

כניסה לדף Buckets
לוחצים על הלחצן Activate Cloud Shell (הפעלת Cloud Shell) בחלק העליון של Google Cloud המסוף.
מריצים את gcloud storage ls --recursive gs://www.example.com/dir/. אם בפלט יש http://www.example.com/dir/, במיקום הזה יש אובייקט ריק.
מסירים את האובייקט הריק באמצעות הפקודה: gcloud storage rm gs://www.example.com/dir/

עכשיו יש לכם גישה אל http://www.example.com/dir/ כדי שיחזיר את הקובץ index.html של הספרייה הזו במקום את האובייקט הריק.

‏‎400: Bad Request

הבעיה: כשביצעתם העלאה שניתן להמשיך, קיבלתם את השגיאה הזו ואת ההודעה Failed to parse Content-Range header.

הפתרון: הערך שבו השתמשתם בכותרת Content-Range לא תקין. לדוגמה, הערך Content-Range: */* לא תקין ובעצם הוא צריך להיות Content-Range: bytes */*. אם השגיאה הזו מופיעה, ההעלאה הנוכחית שניתן להמשיך כבר לא פעילה וצריך להתחיל העלאה חדשה שניתן להמשיך.

‫400: שגיאות ספציפיות של Storage Intelligence

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

‫400: שם הדלי לא תקין

הבעיה: כשמגדירים או מנהלים את Storage Intelligence עבור משאב, יכול להיות שתופיע השגיאה הזו וההודעה The specific bucket is not valid.

הפתרון: כתובת ה-URL שבה השתמשתם בבקשה לא תקינה. כתובת ה-URL צריכה לעמוד בדרישות הבאות:

‫locations/global הוא המיקום היחיד שנתמך ב-Storage Intelligence. אין תמיכה בשימוש במיקום אחר.
Storage Intelligence מופיע ביחיד בכתובת ה-URL, לא ברבים.

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

curl -X PATCH -H "Content-Type: application/json" -d
    '{"edition_config": "STANDARD" }'
    -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage.googleapis.com/v2/projects/my-project/locations/global/storageIntelligence?updateMask=edition_config"

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

הבעיה: כשמגדירים או מנהלים את Storage Intelligence עבור משאב, יכול להיות שתופיע השגיאה הזו וההודעה Empty UPDATE_MASK in the request.

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

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

הבעיה: כשמגדירים או מנהלים את Storage Intelligence עבור משאב, יכול להיות שתופיע השגיאה הזו וההודעה Invalid UPDATE_MASK paths.

הפתרון: אם משתמשים בשם שדה לא תקין בכותרת UPDATE_MASK, מוצגת הודעת שגיאה. ‫UPDATE_MASK היא רשימה מופרדת בפסיקים של שמות השדות שהבקשה מעדכנת. שמות השדות הם בפורמט FieldMask והם חלק מהמשאב IntelligenceConfig. כדי לעדכן את הגדרת Storage Intelligence של משאב, צריך לוודא שכל שם שדה שמופיע ב-UPDATE_MASK הוא שדה תקין במשאב IntelligenceConfig.

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

הבעיה: כשמגדירים או מנהלים את Storage Intelligence עבור משאב, יכול להיות שתופיע השגיאה הזו וההודעה Invalid UPDATE_MASK: UPDATE_TIME field is not editable.

פתרון: UPDATE_MASK היא רשימה מופרדת בפסיקים של שמות השדות שהבקשה מעדכנת. שמות השדות הם בפורמט FieldMask והם חלק מהמשאב IntelligenceConfig. אם תנסו לעדכן שדה שלא ניתן לעריכה, תוצג הודעת שגיאה. מסירים את השדה שאי אפשר לערוך מ-Update_Mask ומנסים שוב.

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

הבעיה: כשמגדירים או מנהלים את Storage Intelligence עבור משאב, יכול להיות שתופיע השגיאה הזו וההודעה Invalid value at storage_intelligence.edition_config.

הפתרון: אם מנסים להשתמש בערך לא תקין בשדה edition_config, מוצגת הודעת שגיאה. הערכים המותרים הם INHERIT,‏ STANDARD ו-DISABLED. צריך לבדוק את הערך ולנסות שוב.

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

הבעיה: כשמעדכנים את ההגדרה של Storage Intelligence למשאב, יכול להיות שתופיע השגיאה הזו וההודעה Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration.

הפתרון: כשמעדכנים את Storage Intelligence‏ edition_config ל-INHERIT או ל-DISABLED, אי אפשר להשתמש במסנני קטגוריות בבקשה. צריך להסיר את המסננים מהבקשה ולנסות שוב.

‫400: ערכים ריקים של מיקום או של דלי במסנן

הבעיה: כשמעדכנים את ההגדרה של Storage Intelligence למשאב, יכול להיות שתופיע השגיאה הזו וההודעה Empty location or bucket values in filter.

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

‏‎401: Unauthorized

הבעיה: בקשות ישירות לקטגוריה ציבורית או דרך Cloud CDN נכשלות, ומתקבלות התשובות HTTP 401: Unauthorized ו-Authentication Required.

הפתרון: מוודאים שהלקוח, או כל שרת proxy מתווך, לא מוסיפים את הכותרת Authorization לבקשות ל-Cloud Storage. כל בקשה עם הכותרת Authorization, גם אם היא ריקה, מאומתת כאילו הייתה ניסיון לאימות.

‏‎403: Account Disabled

הבעיה: ניסיתם ליצור קטגוריה, אבל קיבלתם את הודעת השגיאה 403 Account Disabled.

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

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

‏‎403: Forbidden

הבעיה: אמורה להיות לכם הרשאת גישה לקטגוריה או לאובייקט מסוים, אבל כשאתם מנסים להשתמש בה, מופיעה הודעת השגיאה 403 - Forbidden עם הודעה שדומה לזו: example@email.com does not have storage.objects.get access to the Google Cloud Storage object.

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

האם בהודעת השגיאה מופיעים הפרטים הנכונים של מקבל ההרשאה? אם בהודעת השגיאה מצוינת כתובת אימייל לא צפויה או מצוין Anonymous caller, פרטי הכניסה בבקשה לא נכונים. זה יכול לקרות כשבהגדרת הכלי שבאמצעותו יצרתם את הבקשה יש פרטי כניסה של ישות או כתובת אימייל אחרת, או שהבקשה נוצרה מטעמכם על ידי חשבון שירות.
האם ההרשאה שמצוינת בהודעת השגיאה היא ההרשאה שאתם צריכים? אם לא ציפיתם להרשאה הזו, כנראה שלכלי שבו אתם משתמשים נדרשת הרשאת גישה נוספת כדי להשלים את הטיפול בבקשה. לדוגמה, כדי למחוק בבת אחת כמות גדולה של אובייקטים בקטגוריה, gcloud צריך קודם ליצור רשימה של אובייקטים למחיקה בקטגוריה. לחלק הזה של פעולת המחיקה בכמות גדולה נדרשת הרשאת storage.objects.list, וזה מפתיע כי למחיקת אובייקט בדרך כלל נדרשת רק הרשאת storage.objects.delete. אם זו הסיבה להודעת השגיאה, בדקו אם קיבלתם את תפקידי ה-IAM עם ההרשאות הנדרשות הנוספות.
האם קיבלתם את תפקיד ה-IAM במשאב המיועד או במשאב המקור? לדוגמה, אם קיבלתם תפקיד Storage Object Viewer בפרויקט ואתם מנסים להוריד אובייקט, ודאו שהאובייקט נמצא בקטגוריה שנמצאת בפרויקט. יכול להיות שבטעות יש לכם הרשאת Storage Object Viewer בפרויקט אחר.
האם ההרשאה שלכם לגשת לקטגוריה או לאובייקט מסוימים ניתנה באמצעות ערך נוחות? הסרת הגישה שניתנה לערך נוחות עלולה לגרום לכך שחשבונות משתמשים שהופעלו בעבר יאבדו את הגישה למשאבים.

לדוגמה, נניח של-jane@example.com יש את התפקיד הבסיסי 'בעלים' (roles/owner) בפרויקט בשם my-example-project, ומדיניות ה-IAM של הפרויקט מעניקה את התפקיד 'יוצר אובייקטים ב-Storage' (roles/storage.objectCreator) לערך הנוחות projectOwner:my-example-project. המשמעות היא של-jane@example.com יש את ההרשאות שמשויכות לתפקיד Storage Object Creator בקטגוריות בתוך my-example-project. אם ההרשאה הזו תוסר, jane@example.com תאבד את ההרשאות שמשויכות לתפקיד Storage Object Creator.

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

‫403: ההרשאה נדחתה

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

פתרון: אם מופיעה שגיאת הרשאה עם הודעה שדומה ל-permission storage.intelligenceConfigs.update כשמנסים להגדיר ולנהל את Storage Intelligence עבור משאב, צריך לעיין בקטע ההרשאות של הפעולה שרוצים לבצע. כדי לפתור את הבעיה, צריך להעניק את ההרשאות המתאימות. אפשר לתת הרשאות בכל אחת מהדרכים הבאות:

צריך להעניק הרשאות IAM באותו משאב בהיררכיית המשאבים שבו מפעילים את Storage Intelligence.Google Cloud
מוודאים שמשאב ברמה גבוהה יותר ב Google Cloud היררכיית המשאבים מעביר את ההרשאות למשאב הצאצא.

‏‎409: Conflict

הבעיה: ניסיתם ליצור קטגוריה, אבל קיבלתם את השגיאה:

409 Conflict. Sorry, that name is not available. Please try a different one.

הפתרון: שם הקטגוריה שבו ניסיתם להשתמש (למשל, gs://cats או gs://dogs) כבר תפוס. ל-Cloud Storage יש מרחב שמות גלובלי, כך שאי אפשר לתת לקטגוריה שם של קטגוריה שכבר קיימת. בחרו שם שלא נמצא בשימוש.

‫412: הופרו אילוצים מותאמים אישית

הבעיה: הבקשות שלכם נדחות עם שגיאת 412 orgpolicy.

הבעיה: הבקשות שלכם נדחות עם שגיאת 412 Multiple constraints were violated.

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

‏‎429: Too Many Requests

הבעיה: הבקשות שלכם נדחות עם שגיאת 429 Too Many Requests.

הפתרון: אתם מגיעים למגבלה של מספר הבקשות שאפשר לבצע ב-Cloud Storage במשאב נתון. מידע נוסף על המגבלות ב-Cloud Storage אפשר למצוא במאמר בנושא המכסות של Cloud Storage.

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

אבחון Google Cloud שגיאות במסוף

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

הפתרון: בהתראות במסוף Google Cloud אפשר לראות מידע מפורט על הפעולה שנכשלה:

לוחצים על הלחצן Notifications () בכותרת של מסוף Google Cloud .

הפעולות האחרונות שבוצעו במסוףGoogle Cloud יוצגו בתפריט נפתח.
לוחצים על הפריט שרוצים לקבל עליו מידע נוסף.

ייפתח דף שמציג מידע מפורט על הפעולה.
אפשר ללחוץ על כל שורה כדי להרחיב ולראות מידע מפורט על השגיאה.

הבעיה: כשמשתמשים במסוף Google Cloud , לא רואים עמודה מסוימת.

פתרון: כדי לראות עמודה מסוימת במסוף Google Cloud , לוחצים על סמל האפשרויות להצגת עמודות () ובוחרים את העמודה שרוצים להציג.

תיקיות מדומה ותיקיות מנוהלות

הבעיה: מחקתם כמה אובייקטים בקטגוריה, ועכשיו התיקייה שמכילה אותם לא מופיעה במסוף Google Cloud .

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

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

פתרון: כדי ליצור תיקיות מנוהלות, צריך לוודא שהדרישות הבאות מתקיימות:

יש לכם תפקיד IAM שכולל את ההרשאה storage.managedfolders.create, כמו התפקיד 'אדמין של אובייקטים באחסון' (roles/storage.objectAdmin). במאמר שימוש בהרשאות IAM מוסבר איך מקצים תפקידים.
הגישה האחידה ברמת הקטגוריה מופעלת בקטגוריה שבה רוצים ליצור תיקיות מנוהלות.
אין תנאים של IAM בקטגוריה או בפרויקט שמשתמשים בסוג המשאב של הקטגוריה (storage.googleapis.com/Bucket) או בסוג המשאב של האובייקט (storage.googleapis.com/Object). אם בקטגוריה כלשהי בפרויקט יש תנאי IAM שמשתמש באחד מסוגי המשאבים האלה, אי אפשר ליצור תיקיות מנוהלות באף אחת מהקטגוריות בפרויקט הזה, גם אם התנאי יוסר בהמשך.

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

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

שגיאות באתר הסטטי

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

מילוי בקשות HTTPS

הבעיה: אתם רוצים למלא בקשות תוכן ב-HTTPS בלי להשתמש במאזן עומסים.

הפתרון: אפשר למלא בקשות של תוכן סטטי דרך HTTPS באמצעות מזהי URI ישירים, כמו https://storage.googleapis.com/my-bucket/my-object. יש עוד אפשרויות למילוי בקשות תוכן באמצעות דומיין מותאם אישית ב-SSL:

משתמשים ברשת של צד שלישי להעברת תוכן עם Cloud Storage.
אפשר למלא בקשות לתוכן סטטי של האתר מאירוח ב-Firebase במקום מ-Cloud Storage.

הבעיה: מוצגת הודעת השגיאה Access denied לגבי מילוי בקשה לדף אינטרנט על ידי האתר שלכם.

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

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

הורדת תוכן

הבעיה: מוצגת בקשה להוריד את תוכן הדף, במקום להציג אותו בדפדפן.

הפתרון: אם קבעתם שסוג התוכן באובייקט MainPageSuffix לא יהיה תוכן מהאינטרנט, המבקרים באתר יתבקשו להוריד את התוכן במקום להציג את התוכן שמוצג בדף. כדי לפתור את הבעיה, צריך לעדכן את הערך Content-Type במטא-נתונים לערך מתאים, למשל text/html. הוראות מפורטות מופיעות במאמר עריכת מטא-נתונים של אובייקטים.

הגדרת הנתונים כציבוריים

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

פתרון: יכול להיות שאילוצים של מדיניות הארגון מונעים ממך להגדיר את הנתונים כציבוריים. לדוגמה, האילוץ Domain Restricted Sharing (הגבלת שיתוף לפי דומיין) (constraints/iam.allowedPolicyMemberDomains) מגביל את שיתוף המשאבים על סמך הדומיין של הארגון. אם יש כשלים במדיניות הארגון, צריך לפנות לאדמין כדי לקבל הרשאות ברמת הפרויקט או הקטגוריה שיאפשרו שיתוף משאבים. לשם כך, צריך לערוך את מדיניות הארגון של הארגון, התיקייה או משאב הפרויקט. אם השגיאה הזו ממשיכה להופיע גם אחרי שמשנים את מדיניות הארגון, יכול להיות שצריך לחכות כמה דקות עד שהשינוי ייכנס לתוקף.

הבעיה: כשמנסים לתת גישה ציבורית לנתונים מוצגת שגיאת הרשאה.

הפתרון: מוודאים שיש לכם הרשאת storage.buckets.setIamPolicy או הרשאת storage.objects.setIamPolicy. את ההרשאות האלה מקבלים גם בתפקיד אדמין של Storage (roles/storage.admin). אם יש לכם הרשאת storage.buckets.setIamPolicy או הרשאת storage.objects.setIamPolicy ובכל זאת מופיעה הודעת שגיאה, יכול להיות שהגדרת מניעה של גישה ציבורית חלה על הקטגוריה, ולכן לא מתאפשרת גישה ל-allUsers או ל-allAuthenticatedUsers. מניעת גישה ציבורית מוגדרת ישירות בקטגוריה או במדיניות הארגון שמוגדרת ברמה גבוהה יותר.

זמן אחזור

ריכזנו כאן כמה בעיות נפוצות שקשורות לזמן האחזור. בנוסף, בGoogle Cloud לוח הבקרה של Service Health אפשר למצוא מידע על אירועים שמשפיעים על Google Cloud שירותים כמו Cloud Storage.

זמן אחזור של העלאה או הורדה

הבעיה: זמן אחזור ארוך יותר בזמן ההעלאה או ההורדה.

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

מגבלות על המעבד (CPU) או על הזיכרון: במערכת ההפעלה של הסביבה המושפעת יש בדרך כלל כלים למדידת צריכת המשאבים המקומית, כמו שימוש במעבד (CPU) ושימוש בזיכרון.
מגבלות קלט/פלט בדיסק: יכול להיות שההשפעה על הביצועים נובעת מקלט/פלט בדיסק המקומי.
מרחק גיאוגרפי: הפרדה פיזית בין קטגוריה של Cloud Storage לסביבה המושפעת יכולה לפגוע בביצועים, במיוחד כשהן נמצאות ביבשות שונות. בדיקה באמצעות קטגוריה שנמצאת באותו אזור שבו נמצאת הסביבה המושפעת מאפשרת להעריך את מידת ההשפעה של ההפרדה הגיאוגרפית על זמן האחזור.
- במקרים המתאימים, מקודד ה-DNS של הסביבה המושפעת צריך להשתמש בפרוטוקול EDNS(0) כדי שבקשות מהסביבה ינותבו דרך ממשק קצה מתאים של Google ‏(GFE).

זמן אחזור של CLI או של ספריית לקוח

הבעיה: בגישה ל-Cloud Storage באמצעות Google Cloud CLI או אחת מספריות הלקוח, זמן האחזור ארוך יותר.

הפתרון: במקרים של בקשות שכדאי לנסות לבצע שוב, ה-CLI של gcloud וספריות הלקוח מנסים שוב באופן אוטומטי. הניסיונות האלה עלולים בסופו של דבר להאריך את זמן האחזור אצל משתמש הקצה. משתמשים במדד Cloud Monitoring storage.googleapis.com/api/request_count כדי לבדוק אם ב-Cloud Storage מוצג באופן עקבי קוד תגובה של ניסיון חוזר כמו 429 או 5xx.

שרתי Proxy

הבעיה: אתם מתחברים דרך שרת proxy. מה עושים?

הפתרון: כדי לגשת ל-Cloud Storage דרך שרת proxy, צריך לאפשר גישה לדומיינים הבאים:

‫accounts.google.com ליצירת אסימוני אימות OAuth2
‫oauth2.googleapis.com לביצוע החלפות אסימוני OAuth2
‫*.googleapis.com לבקשות אחסון

אם שרת ה-proxy או מדיניות האבטחה לא תומכים בהוספה לרשימת ההיתרים לפי דומיין, ובמקום זאת נדרשת הוספה לרשימת ההיתרים לפי חסימת רשת IP, מומלץ מאוד להגדיר את שרת ה-proxy לכל טווחי כתובות ה-IP של Google. תוכלו למצוא את טווחי הכתובות בעזרת שאילתות על נתוני WHOIS ב-ARIN. מומלץ לבדוק מדי פעם את הגדרות לשרת proxy כדי לוודא שהן תואמות לכתובות ה-IP של Google.

לא מומלץ להגדיר לשרת ה-proxy את כתובות ה-IP הספציפיות שמתקבלות מחיפושים חד-פעמיים של oauth2.googleapis.com ו-storage.googleapis.com. הגישה לשירותי Google היא באמצעות שמות DNS, שממופים למספר גדול של כתובות IP שיכולות להשתנות עם הזמן. לכן הגדרת שרת ה-proxy על סמך חיפוש חד-פעמי עלולה לגרום לכשלים בהתחברות ל-Cloud Storage.

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

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

תשובות לשאלות נוספות אפשר למצוא בשאלות הנפוצות של Cloud Storage.
מידע על אפשרויות התמיכה
איך Error Reporting יכול לעזור לכם לזהות ולהבין את השגיאות ב-Cloud Storage.

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

רישום בקשות גולמיות ביומן

המסוף

שורת הפקודה

ספריות לקוח

C++‎

C#‎

Go

Java

Node.js

PHP

Python

Ruby

הוספת כותרות מותאמות אישית

שורת הפקודה

ספריות לקוח

C++‎

C#‎

Go

Java

Node.js

PHP

Python

Ruby

גישה לקטגוריות עם הגדרות CORS

קודי שגיאה

‏‎301: Moved Permanently

‏‎400: Bad Request

‫400: שגיאות ספציפיות של Storage Intelligence

‫400: שם הדלי לא תקין

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

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

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

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

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

‫400: ערכים ריקים של מיקום או של דלי במסנן

‏‎401: Unauthorized

‏‎403: Account Disabled

‏‎403: Forbidden

‫403: ההרשאה נדחתה

‏‎409: Conflict

‫412: הופרו אילוצים מותאמים אישית

‏‎429: Too Many Requests

אבחון Google Cloud שגיאות במסוף

תיקיות מדומה ותיקיות מנוהלות

שגיאות באתר הסטטי

מילוי בקשות HTTPS

דף לא נגיש

הורדת תוכן

הגדרת הנתונים כציבוריים

זמן אחזור

זמן אחזור של העלאה או הורדה

זמן אחזור של CLI או של ספריית לקוח

שרתי Proxy

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

פתרון בעיות