פתרון בעיות

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

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

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

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

המסוף

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

  1. לוחצים על לחצן התפריט הראשי של Chrome‏ ().

  2. בוחרים באפשרות More Tools.

  3. לוחצים על Developer Tools (כלים למפתחים).

  4. בחלונית שמופיעה, לוחצים על הכרטיסייה 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#‎

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

המשך

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

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

Java

  1. יוצרים קובץ בשם 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
  2. משתמשים ב-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);
}

המשך

אפשר להוסיף כותרות בהתאמה אישית לכל קריאה ל-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' }

Rust

use google_cloud_gax::options::RequestOptionsBuilder;
use google_cloud_storage::client::Storage;
use google_cloud_storage::client::StorageControl;
use http::header::{HeaderName, HeaderValue};

pub async fn sample(bucket_id: &str) -> anyhow::Result<()> {
    const NAME: &str = "hello-world.txt";

    // Set a client-level custom header on the Storage data plane client.
    let client = Storage::builder()
        .with_custom_header(
            HeaderName::from_static("x-custom-header"),
            HeaderValue::from_static("custom-value"),
        )
        .build()
        .await?;

    let reader = client
        .read_object(format!("projects/_/buckets/{bucket_id}"), NAME)
        .send()
        .await?;
    println!("Object highlights: {:?}", reader.object());

    // Set a request-level custom header on a StorageControl RPC request.
    let control = StorageControl::builder().build().await?;
    let bucket = control
        .get_bucket()
        .set_name(format!("projects/_/buckets/{bucket_id}"))
        .with_custom_header(
            HeaderName::from_static("x-custom-header"),
            HeaderValue::from_static("custom-value"),
        )
        .send()
        .await?;
    println!("Bucket {bucket_id} metadata is {bucket:?}");

    Ok(())
}

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

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

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

  2. כשאתם בודקים שליחה של בקשת CORS, ודאו שאתם לא שולחים בקשה לנקודת הקצה (endpoint) של storage.cloud.google.com, שלא מאפשרת בקשות CORS. למידע נוסף על נקודות הקצה שיש להן תמיכה ב-CORS, ראו תמיכה ב-CORS ב-Cloud Storage.

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

    1. לוחצים על תפריט Chrome ‏() בסרגל הכלים של הדפדפן.
    2. בוחרים באפשרות כלים נוספים > כלים למפתחים.
    3. לוחצים על הכרטיסייה Network.
    4. שולחים את הבקשה מהאפליקציה או משורת הפקודה.
    5. מאתרים את הבקשה בחלונית שמציגה את הפעילות ברשת.
    6. בעמודה Name, לוחצים על השם שתואם לבקשה.
    7. לוחצים על הכרטיסייה Headers כדי לראות את כותרות התגובות. לחלופין, לוחצים על הכרטיסייה Response כדי לראות את תוכן התגובה.

    אם אתם לא רואים בקשה ותגובה, יכול להיות שהדפדפן שלכם שמר במטמון ניסיון קודם שנכשל של בקשת קדם-הפעלה. ניקוי המטמון של הדפדפן אמור גם לנקות את המטמון של קדם-ההפעלה. אם לא, אפשר להגדיר את הערך של MaxAgeSec בהגדרות ה-CORS שלכם לערך נמוך יותר מ ברירת המחדל 3600 (60 דקות). אתם צריכים להמתין עד שיחלוף משך הזמן הקודם שנקבע ב-MaxAgeSec, ואז לנסות לשלוח את הבקשה שוב. הפעולה הזו מבצעת בקשת קדם-הפעלה חדשה, שמאחזרת את הגדרות CORS החדשות ומוחקת באופן סופי את רשומות המטמון. אחרי שסיימתם לנפות את הבאגים, אתם צריכים להגדיל את הערך של MaxAgeSec בחזרה לערך גבוה יותר כדי לצמצם את תעבורת נתוני קדם-ההפעלה לקטגוריה שלכם.

  4. לוודא שבבקשה יש כותרת 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.

  5. בבקשות פשוטות, מוודאים ש-method ה-HTTP של הבקשה תואמת לפחות לאחד מהערכים של Methods בהגדרות ה-CORS של הקטגוריה. בבקשות קדם-הפעלה, צריך לוודא שה-method שצוינה ב-Access-Control-Request-Method תואמת לפחות לאחד מהערכים של Methods.

  6. בבקשות קדם-הפעלה, בודקים אם הבקשה כוללת כותרת 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/, כנראה שבקטגוריה יש אובייקט ריק בשם הזה. כדי לבדוק אם זאת הבעיה ולפתור אותה:

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

    כניסה לדף Buckets

  2. לוחצים על הלחצן Activate Cloud Shell בחלק העליון של מסוף Google Cloud .
  3. מריצים את gcloud storage ls --recursive gs://www.example.com/dir/. אם בפלט יש http://www.example.com/dir/, במיקום הזה יש אובייקט ריק.
  4. מסירים את האובייקט הריק באמצעות הפקודה: 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 מוסבר איך פותרים שגיאות נפוצות שנתקלים בהן כשמגדירים או מנהלים את Storage Intelligence,‏ Storage Insights ופעולות רבות על פריטי אחסון.

‏‎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 doesn't have storage.objects.get access to the Google Cloud Storage object.

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

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

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

  3. האם קיבלתם את תפקיד ה-IAM במשאב המיועד או במשאב המקור? לדוגמה, אם קיבלתם תפקיד Storage Object Viewer בפרויקט ואתם מנסים להוריד אובייקט, ודאו שהאובייקט נמצא בקטגוריה שנמצאת בפרויקט. יכול להיות שבטעות יש לכם הרשאת Storage Object Viewer בפרויקט אחר.

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

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

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

  5. האם יש מדיניות דחייה ב-IAM שמונעת ממך להשתמש בהרשאות מסוימות? אתם יכולים לפנות ל-Organization Administrator בארגון כדי לברר אם הוגדרה מדיניות IAM לסירוב גישה.

‫403: אין לך הרשאה מתאימה

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

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

  • נותנים הרשאות IAM באותו משאב בGoogle Cloud היררכיית המשאבים שבו מפעילים את Storage Intelligence.
  • מוודאים שמשאב ברמה גבוהה יותר ב 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 או יותר של תעבורת נתונים יוצאת ברשת למיקומים ספציפיים, בדקו את השימוש ברוחב הפס כדי לוודא שאתם לא חורגים ממכסת רוחב הפס.

שגיאות בהקשר של אובייקט

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

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

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

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

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

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

פתרון: כל מפתח וערך של הקשר אובייקט צריכים להיות באורך של עד 256 בייטים (בקידוד UTF-8). צריך לקצר את המפתח או את הערך ולנסות שוב.

‫400: חריגה מהמגבלה של הגודל המצטבר של המפתח או הערך של הקשר האובייקט

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

פתרון: הגודל הכולל של כל המפתחות והערכים של ההקשר לאובייקט לא יכול להיות יותר מ-25KiB‏ (25,600 בייטים). צריך לצמצם את כמות נתוני ההקשר הכוללת ולנסות שוב.

‫400: המפתח או הערך של הקשר האובייקט מכילים תווים אסורים

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

הפתרון: המפתחות והערכים של הקשרי האובייקטים לא יכולים להכיל גרש ('), מירכאות (") או לוכסנים הפוכים (\`), or forward slashes (/`). צריך לבדוק את ההקשרים ולהסיר את התווים הלא חוקיים.

‫400: המפתח או הערך של הקשר האובייקט חייבים להתחיל בתו אלפאנומרי

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

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

‫400: מפתח ההקשר של האובייקט או הערך ריק

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

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

‫400: מפתח או ערך של הקשר אובייקט בפורמט UTF-8 לא תקין

הבעיה: השגיאה מציינת שמפתח או ערך של הקשר של אובייקט הם לא מחרוזת UTF-8 תקינה.

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

‫400: תחילית שמורה של מפתח הקשר של אובייקט

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

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

‫400: לאובייקט לא יכולות להיות יותר מ-50 קבוצות של הקשרים להורדה

הבעיה: השגיאה מציינת שלפרמטר drop_context_groups יכולים להיות עד 50 ערכים.

פתרון: צריך לצמצם את מספר הערכים בפרמטר drop_context_groups ולנסות שוב.

‫400: ערך לא תקין בשדה Drop Context Groups (קבוצות הקשר של ההעברה)

הבעיה: השגיאה מציינת שהפרמטר drop_context_groups מכיל ערך לא תקין.

פתרון: הערך היחיד שמתקבל לפרמטר drop_context_groups הוא custom.

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

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

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

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

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

  2. לוחצים על הפריט שרוצים לקבל עליו מידע נוסף.

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

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

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

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

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

הבעיה: מחקתם כמה אובייקטים בקטגוריה, ועכשיו התיקייה שמכילה אותם לא מופיעה במסוף 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:

דף לא נגיש

הבעיה: מוצגת הודעת השגיאה 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.

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