Solución de problemas

En esta página, se describen métodos de solución de problemas comunes que puedes encontrar mientras usas Cloud Storage.

Consulta el Panel de Google Cloud Service Health para obtener información sobre los incidentes que afectan a los servicios de Google Cloud, como Cloud Storage.

Registra solicitudes sin procesar

Cuando se usan herramientas como gcloud o las bibliotecas cliente de Cloud Storage, la herramienta controla gran parte de la información de solicitud y respuesta. Sin embargo, a veces es útil ver los detalles para ayudar a solucionar problemas o cuando se publican preguntas en foros como Stack Overflow. Usa las siguientes instrucciones para mostrar los encabezados de solicitud y respuesta de tu herramienta:

Console

La visualización de la información de solicitudes y respuestas depende del navegador que usas para acceder a la consola de Google Cloud. Para el navegador Google Chrome:

  1. Haz clic en el botón Menú principal de Chrome ().

  2. Elige Más herramientas.

  3. Haz clic en Herramientas para desarrolladores.

  4. En el panel que aparece, haz clic en la pestaña Red.

Línea de comandos

Usa marcas de depuración globales en tu solicitud. Por ejemplo:

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

Bibliotecas cliente

C++

  • Configura la variable de entorno CLOUD_STORAGE_ENABLE_TRACING=http para obtener el tráfico HTTP completo.

  • Configura la variable de entorno CLOUD_STORAGE_ENABLE_CLOG=yes para obtener el registro de cada RPC.

C#

Agrega un registrador a través de ApplicationContext.RegisterLogger y configura las opciones de registro en el controlador de mensajes HttpClient. Para obtener más información, consulta la entrada Preguntas frecuentes.

Go

Configura la variable de entorno GODEBUG=http2debug=1. Para obtener más información, consulta el paquete de Go net/http.

Si además quieres registrar el cuerpo de la solicitud, usa un cliente HTTP personalizado.

Java

  1. Crea un archivo llamado “logging.properties” con el siguiente contenido:

    # 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. Usa logging.properties con Maven

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

Para obtener más información, consulta Transporte HTTP conectable.

Node.js

Configura la variable de entorno NODE_DEBUG=https antes de llamar a la secuencia de comandos de Node.

PHP

Proporciona tu propio controlador HTTP al cliente mediante httpHandler y configura el middleware para que registre la solicitud y la respuesta.

Python

Usa el módulo de registro. Por ejemplo:

import logging
import http.client

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

Ruby

En la parte superior de tu .rb file después de require "google/cloud/storage", agrega lo siguiente:

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

Agrega encabezados personalizados

Agregar encabezados personalizados a las solicitudes es una herramienta común para fines de depuración, como habilitar encabezados de depuración o realizar un seguimiento de una solicitud. En el siguiente ejemplo, se muestra cómo configurar encabezados de la solicitud para diferentes herramientas de Cloud Storage:

Línea de comandos

Usa la marca --additional-headers, que está disponible para la mayoría de los comandos. Por ejemplo:

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

En este ejemplo, HEADER_NAME y HEADER_VALUE definen el encabezado que agregas a la solicitud.

Bibliotecas cliente

C++

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

C#

En el siguiente ejemplo, se agrega un encabezado personalizado a cada solicitud que realiza la biblioteca cliente.

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

Agregar encabezados personalizados a las solicitudes realizadas por la biblioteca cliente de Go requiere unir el transporte que se usa para el cliente con un RoundTripper personalizado. En el siguiente ejemplo, se envían encabezados de depuración y se registran los encabezados de respuesta correspondientes:

package main

import (
  "context"
  "io/ioutil"
  "log"
  "net/http"

  "cloud.google.com/go/storage"
  "google.golang.org/api/option"
  raw "google.golang.org/api/storage/v1"
  htransport "google.golang.org/api/transport/http"
)

func main() {

  ctx := context.Background()

  // Standard way to initialize client:
  // client, err := storage.NewClient(ctx)
  // if err != nil {
  //      // handle error
  // }

  // Instead, create a custom http.Client.
  base := http.DefaultTransport
  trans, err := htransport.NewTransport(ctx, base, option.WithScopes(raw.DevstorageFullControlScope),
            option.WithUserAgent("custom-user-agent"))
  if err != nil {
            // Handle error.
  }
  c := http.Client{Transport:trans}

  // Add RoundTripper to the created HTTP client.
  c.Transport = withDebugHeader{c.Transport}

  // Supply this client to storage.NewClient
  client, err := storage.NewClient(ctx, option.WithHTTPClient(&c))
  if err != nil {
              // Handle error.
  }

  // Use client to make a request
 }

type withDebugHeader struct {
  rt http.RoundTripper
}

func (wdh withDebugHeader) RoundTrip(r *http.Request) (*http.Response, error) {
  headerName := "X-Custom-Header"
  r.Header.Add(headerName, "value")
  resp, err := wdh.rt.RoundTrip(r)
  if err == nil {
    log.Printf("Resp Header: %+v, ", resp.Header.Get(headerName))
  } else {
    log.Printf("Error: %+v", err)
  }
  return resp, err
}

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

Todas las llamadas de método que activan solicitudes HTTP aceptan un argumento $restOptions opcional como el último argumento. Puedes proporcionar encabezados personalizados por solicitud o por cliente.

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' }

Accede a buckets con una configuración de CORS

Si estableciste una configuración de CORS en tu bucket y notas que las solicitudes entrantes de los navegadores cliente fallan, prueba los siguientes pasos para solucionar problemas:

  1. Revisa la configuración de CORS en el bucket de destino. Si tienes varias entradas de configuración de CORS, asegúrate de que los valores de solicitud que usas para solucionar problemas se asignen a valores en una sola entrada de configuración de CORS.

  2. Cuando realices pruebas para emitir una solicitud de CORS, verifica que no estés realizando una solicitud al extremo storage.cloud.google.com, que no permite solicitudes de CORS. Para obtener más información de los extremos compatibles con CORS, consulta Compatibilidad con CORS de Cloud Storage.

  3. Revisa una solicitud y una respuesta con la herramienta que prefieras. En un navegador Chrome, puedes usar las herramientas para desarrolladores estándar para ver esta información:

    1. Haz clic en el menú de Chrome () en la barra de herramientas del navegador.
    2. Selecciona Más herramientas > Herramientas para desarrolladores.
    3. Haz clic en la pestaña Red.
    4. Desde tu aplicación o la línea de comandos, envía la solicitud.
    5. En el panel que muestra la actividad de la red, busca la solicitud.
    6. En la columna Nombre, haz clic en el nombre correspondiente a la solicitud.
    7. Haz clic en la pestaña Encabezados para ver los encabezados de respuesta, o en la pestaña Respuesta si deseas ver el contenido de la respuesta.

    Si no ves una solicitud y una respuesta, es posible que tu navegador tenga almacenado en caché un intento anterior de solicitud preliminar con errores. Si se borra la caché de tu navegador, también se debería borrar la caché de la comprobación previa. Si esto no sucede, configura el valor MaxAgeSec en tu configuración de CORS en un valor inferior al valor predeterminado de 1800 (30 minutos). Espera el tiempo establecido en el MaxAgeSec anterior y vuelve a intentar la solicitud. Esto realiza una nueva solicitud de comprobación previa, que recupera la configuración de CORS nueva y borra de forma definitiva las entradas de caché. Una vez que hayas depurado tu problema, vuelve a aumentar MaxAgeSec a un valor más alto, para reducir el tráfico de solicitud preliminar de tu bucket.

  4. Asegúrate de que la solicitud tenga un encabezado Origin y que el valor del encabezado coincida con al menos uno de los valores Origins en la configuración de CORS del depósito. Ten en cuenta que el esquema, el host y el puerto de los valores deben coincidir de forma exacta. Los siguientes son algunos ejemplos de coincidencias aceptables:

    • http://origin.example.com coincide con http://origin.example.com:80 (ya que 80 es el puerto HTTP predeterminado), pero no coincide con https://origin.example.com, http://origin.example.com:8080, http://origin.example.com:5151 ni http://sub.origin.example.com.

    • https://example.com:443 coincide con https://example.com pero no con http://example.com ni http://example.com:443.

    • http://localhost:8080 solo coincide de forma exacta con http://localhost:8080 y no coincide con http://localhost:5555 ni http://localhost.example.com:8080.

  5. En el caso de solicitudes simples, asegúrate de que el método HTTP de la solicitud coincida con al menos uno de los valores Methods en la configuración de CORS del bucket. Para las solicitudes preliminares, asegúrate de que el método especificado en Access-Control-Request-Method coincida con al menos uno de los valores Methods.

  6. Para las solicitudes preliminares, verifica si incluye uno o más encabezados Access-Control-Request-Header. Si es así, asegúrate de que cada valor Access-Control-Request-Header coincida con un valor ResponseHeader en la configuración de CORS del bucket. Todos los encabezados nombrados en Access-Control-Request-Header deben estar en la configuración de CORS para que la solicitud de comprobación previa tenga éxito y se incluyan los encabezados de CORS en la respuesta.

Códigos de error

Los siguientes son códigos de estado HTTP comunes que puedes encontrar.

301: Movido de forma permanente

Problema: Estoy configurando un sitio web estático y el acceso a una ruta de directorio muestra un objeto vacío y un código de respuesta HTTP 301.

Solución: Si tu navegador descarga un objeto de cero bytes y obtienes un código de respuesta HTTP 301 cuando accedes a un directorio, como http://www.example.com/dir/, es probable que tu bucket contenga un objeto vacío con ese nombre. Sigue los pasos a continuación para comprobar que este es el caso y solucionar el problema:

  1. En la consola de Cloud, ve a la página Buckets de Cloud Storage.

    Ir a Buckets

  2. Haz clic en el botón Activar Cloud Shell en la parte superior de la consola de Google Cloud.
  3. Ejecuta gcloud storage ls --recursive gs://www.example.com/dir/. Si el resultado incluye http://www.example.com/dir/, tienes un objeto vacío en esa ubicación.
  4. Quita el objeto vacío con el comando: gcloud storage rm gs://www.example.com/dir/.

Ahora puedes acceder a http://www.example.com/dir/ y hacer que muestre el archivo index.html de ese directorio en lugar del objeto vacío.

400: Bad Request

Problema: Mientras se realizaba una carga reanudable, recibí este error y el mensaje Failed to parse Content-Range header.

Solución: El valor que usaste en el encabezado Content-Range no es válido. Por ejemplo, Content-Range: */* no es válido y, en su lugar, se debe especificar como Content-Range: bytes */*. Si recibes este error, tu carga reanudable actual ya no está activa y debes iniciar una nueva.

401: Sin autorización

Problema: Las solicitudes que se envían directamente a un bucket público o usando Cloud CDN fallan con un error HTTP 401: Unauthorized y una respuesta Authentication Required.

Solución: Verifica que tu cliente, o cualquier proxy intermedio, no agregue un encabezado Authorization a las solicitudes a Cloud Storage. Cualquier solicitud con un encabezado Authorization, incluso si está vacía, se valida como si fuera un intento de autenticación.

403: Cuenta inhabilitada

Problema: Intenté crear un bucket, pero obtuve un error 403 Account Disabled.

Solución: Este error indica que aún no has activado la facturación para el proyecto asociado. Si quieres conocer los pasos para habilitar la facturación, consulta la sección Habilita la facturación para un proyecto.

Si la facturación está activada y sigues recibiendo este mensaje de error, puedes comunicarte con el servicio de asistencia con el ID del proyecto y una descripción de tu problema.

403: Prohibido

Problema: Tengo permiso para acceder a un objeto o bucket determinado, pero cuando intento hacerlo, recibo un error 403 - Forbidden con un mensaje similar al siguiente: example@email.com does not have storage.objects.get access to the Google Cloud Storage object.

Solución: Te falta un permiso de IAM para el objeto o bucket que es necesario para completar la solicitud. Si esperas poder realizar la solicitud, pero no puedes hacerlo, realiza las siguientes verificaciones:

  1. ¿El usuario al que hace referencia el mensaje de error es el que esperabas? Si el mensaje de error hace referencia a una dirección de correo electrónico inesperada o a un "emisor anónimo", significa que tu solicitud no usa las credenciales que debe. Esto puede deberse a que la herramienta que usas para realizar la solicitud se configuró con las credenciales de otro alias o entidad, o podría ser porque una cuenta de servicio realiza la solicitud en tu nombre.

  2. ¿El permiso al que hace referencia el mensaje de error es uno que pensaste que necesitabas? Si el permiso es inesperado, es probable que la herramienta que usas requiera acceso adicional para completar tu solicitud. Por ejemplo, para borrar objetos de forma masiva en un bucket, gcloud primero debe crear una lista de objetos en el bucket que se borrará. Esta parte de la acción de eliminación masiva requiere el permiso storage.objects.list, que puede ser inesperado, siempre que el objetivo sea la eliminación de objetos, que, por lo general, solo requiere el permiso storage.objects.delete. Si esta es la causa del mensaje de error, asegúrate de que se te otorguen roles de IAM que tengan los permisos adicionales necesarios.

  3. ¿Se te otorgó el rol de IAM en el recurso correcto o en uno superior? Por ejemplo, si se te otorga el rol Storage Object Viewer para un proyecto e intentas descargar un objeto, asegúrate de que el objeto esté en un bucket que pertenezca al proyecto; es posible que de forma involuntaria tengas el permiso Storage Object Viewer para un proyecto diferente.

  4. ¿Tu permiso para acceder a un objeto o bucket determinado se otorga a través de un valor de conveniencia? La eliminación del acceso otorgado a un valor de conveniencia puede hacer que las principales que se habilitaron con anterioridad pierdan el acceso a los recursos.

    Por ejemplo, supongamos que jane@example.com tiene el rol básico de propietario (roles/owner) para un proyecto llamado my-example-project y la política de IAM del proyecto otorga el rol de creador de objetos de almacenamiento (roles/storage.objectCreator) al valor de conveniencia projectOwner:my-example-project. Esto significa que jane@example.com tiene los permisos asociados con el rol de creador de objetos de almacenamiento para los buckets dentro de my-example-project. Si se quita este otorgamiento, jane@example.com pierde los permisos asociados con el rol de creador de objetos de almacenamiento.

    En esta situación, puedes recuperar el acceso al objeto o bucket si te otorgas los permisos necesarios a nivel de bucket o de objeto necesarios para realizar las acciones que necesitas.

  5. ¿Existe una política de denegación de IAM que te impida usar ciertos permisos? Puedes comunicarte con el administrador de tu organización para averiguar si se implementó una política de denegación de IAM.

403: Prohibido

Problema: Descargo mi contenido de storage.cloud.google.com y recibo un error 403: Forbidden cuando uso el navegador para ir al objeto mediante la URL:

https://storage.cloud.google.com/BUCKET_NAME/OBJECT_NAME

Solución: Si usas storage.cloud.google.com para descargar objetos, realizas lo que se llama una descarga del navegador autenticada, que usa una autenticación basada en cookies. Si configuraste los registros de auditoría de acceso a los datos en Cloud Audit Logging para realizar un seguimiento del acceso a los objetos, una de las restricciones de esa función es que las descargas autenticadas del navegador no se puede usar para descargar un objeto con seguimiento, a menos que se aplique una de las siguientes condiciones:

  • El objeto se puede leer de forma pública.
  • Se accede al objeto desde la consola de Google Cloud

Cualquier otro intento de usar una descarga autenticada del navegador da como resultado una respuesta 403. Esta restricción existe para evitar el phishing de los IDs de Google, que se usan en la autenticación basada en cookies.

Para evitar este problema, realiza una de las siguientes acciones:

  • Usa llamadas a la API directas, que admiten descargas no autenticadas, en lugar de usar descargas de navegadores autenticadas.
  • Inhabilita los registros de acceso a los datos de Cloud Storage que realizan un seguimiento del acceso a los objetos afectados. Ten en cuenta que los registros de auditoría de acceso a los datos se establecen en un nivel de proyecto o por encima de este y se pueden habilitar al mismo tiempo en varios niveles.
  • Configura exenciones para excluir a usuarios específicos del seguimiento del registro de auditoría de acceso a los datos, lo que permite que esos usuarios realicen descargas autenticadas del navegador.
  • Otorga permiso de lectura a allUsers o allAuthenticatedUsers para que los objetos afectados sean legibles de forma pública. Los registros de auditoría de acceso a los datos no registran el acceso a objetos públicos.

409: Conflicto

Problema: Intenté crear un bucket, pero recibí el siguiente error:

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

Solución: El nombre del bucket que intentaste usar (p. ej., gs://cats o gs://dogs) ya está en uso. Cloud Storage tiene un espacio de nombres global, por lo que no puedes nombrar un bucket con el mismo nombre que un bucket existente. Elige un nombre que no esté en uso.

412: Restricciones personalizadas vulneradas

Problema: Mis solicitudes se rechazan con un error 412 orgpolicy.

Problema: Mis solicitudes se rechazan con un error 412 Multiple constraints were violated.

Solución: Consulta con tu equipo de administración de seguridad para ver si el bucket al que envías las solicitudes está afectado por una política de la organización que usa una restricción personalizada. Tu bucket también puede verse afectado por diferentes políticas de la organización que entran en conflicto entre sí. Por ejemplo, cuando una política específica que los buckets deben tener la clase Standard Storage y otra política específica que los buckets deben tener la clase Coldline Storage.

429: Demasiadas solicitudes

Problema: Mis solicitudes se rechazan con un error 429 Too Many Requests.

Solución: Estás a punto de alcanzar un límite de solicitudes que Cloud Storage permite para un recurso determinado. Consulta las cuotas de Cloud Storage para obtener una discusión sobre los límites en Cloud Storage.

  • Si tu carga de trabajo consta de 1,000 solicitudes por segundo a un bucket, consulta Lineamientos de distribución de acceso y porcentaje de solicitudes para ver un análisis de las prácticas recomendadas, que incluyen aumentar la carga de trabajo de manera gradual y evitar los nombres de archivos secuenciales.

  • Si tu carga de trabajo posiblemente usa 50 Gbps o más de salida de red a ubicaciones específicas, verifica el uso del ancho de banda para asegurarte de no encontrar una cuota de ancho de banda.

Diagnostica errores de la consola de Google Cloud

Problema: Cuando uso la consola de Google Cloud para realizar una operación, recibo un mensaje de error genérico. Por ejemplo, veo un mensaje de error cuando intento borrar un bucket, pero no veo los detalles del motivo por el cual falló la operación.

Solución: Debes usar las notificaciones de la consola de Google Cloud para ver información detallada sobre la operación que produjo errores, mediante los siguientes pasos:

  1. Haz clic en el botón Notificaciones () en el encabezado de la consola de Google Cloud.

    En un menú desplegable, se muestran las operaciones más recientes que realizó la consola de Google Cloud.

  2. Haz clic en el elemento del que deseas obtener más información.

    Se abrirá una página que muestra información detallada sobre la operación.

  3. Haz clic en cada fila para expandir la información del error detallada.

Problema: Cuando uso la consola de Google Cloud, no se muestra una columna en particular.

Solución: Para ver una columna en particular en la consola de Google Cloud, haz clic en el ícono Opciones de visualización de columnas () y selecciona la columna. que quieres mostrar.

Carpetas simuladas y carpetas administradas

Problema: Configuré algunos objetos en mi bucket y ahora la carpeta que los contenía no aparece en la consola de Google Cloud.

Solución: Si bien la consola de Google Cloud muestra el contenido de tu bucket como si hubiera una estructura de directorio, no existen básicamente carpetas en Cloud Storage. Como resultado, cuando quitas todos los objetos con un prefijo común de un bucket, el ícono de la carpeta que representa ese grupo de objetos ya no aparece en la consola de Google Cloud.

Problema: No puedo crear carpetas administradas.

Solución: Para crear carpetas administradas, asegúrate de que se cumplan los siguientes requisitos:

  • Tienes un rol de IAM que contiene el permiso storage.managedfolders.create, como el rol de administrador de objetos de almacenamiento (roles/storage.objectAdmin). Si deseas obtener instrucciones para otorgar roles, consulta Usa permisos de IAM.

  • El acceso uniforme a nivel de bucket está habilitado en el bucket en el que deseas crear las carpetas administradas.

  • No hay condiciones de IAM en el bucket o en el proyecto que use el tipo de recurso del bucket (storage.googleapis.com/Bucket) o el tipo de recurso del objeto (storage.googleapis.com/Object). Si un bucket dentro de un proyecto tiene una condición de IAM que usa cualquiera de estos tipos de recursos, no se pueden crear carpetas administradas en ninguno de los buckets dentro de ese proyecto, incluso si la condición se quita más adelante.

Problema: No puedo inhabilitar el acceso uniforme a nivel de bucket porque hay carpetas administradas en mi bucket.

Solución: El acceso uniforme a nivel de bucket no se puede inhabilitar si hay carpetas administradas en el bucket. Para inhabilitar el acceso uniforme a nivel de bucket, primero deberás borrar todas las carpetas administradas del bucket.

Errores de sitios web estáticos

Los siguientes son problemas comunes que puedes encontrar en Aloja un sitio web estático.

Entrega en HTTPS

Problema: Quiero que mi contenido se entregue a través de HTTPS sin usar un balanceador de cargas.

Solución: Puedes entregar el contenido estático a través de HTTPS mediante URI directos como https://storage.googleapis.com/my-bucket/my-object. Si deseas más opciones para entregar el contenido a través de un dominio personalizado con SSL, puedes realizar lo siguiente:

Verificación del dominio

Problema: No puedo verificar mi dominio.

Solución: Normalmente, el proceso de verificación en Search Console te dirige a subir un archivo a tu dominio, pero es posible que no tengas una forma de hacerlo sin tener primero un bucket asociado, que solo puedes crear después de realizar la verificación del dominio.

En este caso, verifica la propiedad. Para ello usa el método de verificación del proveedor de nombres de dominio. Para lograr esto, consulta los pasos en Verificación de propiedad del dominio. Esta verificación se puede hacer antes de crear el bucket.

Página inaccesible

Problema: Recibo un mensaje de error Access denied de una página web que entrega mi sitio web.

Solución: Comprueba que el objeto se comparte de forma pública. Si no es así, consulta Haz públicos los datos para obtener instrucciones para hacerlo.

Si anteriormente subiste y compartiste un objeto, pero luego subiste una versión nueva del mismo, entonces debes compartir el objeto de forma pública. Esto se debe a que el permiso público se reemplaza por la carga nueva.

No se pudo actualizar el permiso

Problema: Recibo un error cuando intento hacer públicos mis datos.

Solución: Asegúrate de tener el permiso storage.buckets.setIamPolicy o storage.objects.setIamPolicy. Por ejemplo, estos permisos se otorgan en el rol de Administrador de almacenamiento (roles/storage.admin). Si tienes el permiso storage.buckets.setIamPolicy o el permiso storage.objects.setIamPolicy y de todos modos recibes un error, es posible que tu bucket esté sujeto a la prevención del acceso público, que no permite el acceso a allUsers o allAuthenticatedUsers. La prevención del acceso público puede establecerse en el bucket directamente o puede aplicarse mediante una política de la organización que se establezca en un nivel superior.

Descarga de contenido

Problema: Se me pide que descargue el contenido de mi página, en lugar de poder verlo en mi navegador.

Solución: Si especificas un MainPageSuffix como un objeto que no tiene un tipo de contenido web, se solicita a los visitantes del sitio que descarguen el contenido en lugar de poder verlo entregado. contenido de la página. Para resolver este problema, actualiza la entrada de metadatos Content-Type a un valor adecuado, como text/html. Para obtener instrucciones, consulta Edita los metadatos de objetos.

Latencia

Los siguientes son problemas de latencia comunes que puedes encontrar. Además, el panel de Google Cloud Service Health proporciona información sobre incidentes que afectan a los servicios de Google Cloud, como Cloud Storage.

Latencia de carga o descarga

Problema: Veo un aumento de la latencia cuando uso la carga o la descarga.

Solución: ten en cuenta las siguientes causas comunes de latencia de carga y descarga:

  • Restricciones de CPU o memoria: El sistema operativo del entorno afectado debe tener herramientas para medir el consumo de recursos locales, como el uso de CPU y memoria.

  • Restricciones de IO de disco: el impacto en el rendimiento puede deberse a la IO del disco local.

  • Distancia geográfica: El rendimiento puede verse afectado por la separación física de tu bucket de Cloud Storage y el entorno afectado, en especial en casos de continentes múltiples. Las pruebas con un bucket ubicado en la misma región que tu entorno afectado pueden identificar el grado en el que la separación geográfica contribuye a tu latencia.

    • Si corresponde, el agente de resolución de DNS del entorno afectado debe usar el protocolo EDNS(0) para que las solicitudes del entorno se enruten a través de un Google Front End adecuado.

Latencia de la biblioteca cliente o la CLI

Problema: veo un aumento de la latencia cuando accedo a Cloud Storage con Google Cloud CLI o una de las bibliotecas cliente.

Solución: gcloud CLI y las bibliotecas cliente reintentan de forma automática las solicitudes cuando es útil hacerlo, y este comportamiento puede aumentar de forma efectiva la latencia como se ve desde el usuario final. Usa la métrica storage.googleapis.com/api/request_count de Cloud Monitoring para ver si Cloud Storage entrega de manera coherente un código de respuesta que se puede reintentar, como 429 o 5xx.

Servidores proxy

Problema: Me conecté a través de un servidor proxy, ¿qué debo hacer?

Solución: Para acceder a Cloud Storage a través de un servidor proxy, debes permitir el acceso a estos dominios:

  • accounts.google.com para crear tokens de autenticación OAuth2
  • oauth2.googleapis.com para realizar intercambios de tokens OAuth2
  • *.googleapis.com para solicitudes de almacenamiento

Si tu servidor proxy o tu política de seguridad no admiten listas de entidades permitidas por dominio y, en su lugar, solo admiten listas de anunciantes permitidos por bloqueo de red IP, te recomendamos que configures tu servidor proxy para todos los rangos de direcciones IP de Google. Puedes encontrar los rangos de direcciones con una consulta a los datos de WHOIS en ARIN. Como práctica recomendada, debes revisar con frecuencia tu configuración de proxy para asegurarte de que coincida con las direcciones IP de Google.

No se recomienda configurar el proxy con las direcciones IP individuales que se obtienen de las búsquedas únicas de oauth2.googleapis.com y storage.googleapis.com. Debido a que los servicios de Google están expuestos a través de nombres de DNS que se asignan a una gran cantidad de direcciones IP que pueden cambiar con el tiempo, la configuración de tu proxy en una única búsqueda puede llevar a fallas en la conexión a Cloud Storage.

Si tus solicitudes se enrutan a través de un servidor proxy, es posible que debas consultar a tu administrador de red para asegurarte de que el proxy no borre el encabezado Authorization que contiene tus credenciales. Sin el encabezado Authorization, tus solicitudes se rechazan y recibes un error MissingSecurityHeader.

Errores de Storage Insights

Problema: La configuración de mis informes de inventario genera varios informes de inventario a diario.

Solución: Si tienes más de 1,000,000 de objetos en tu bucket, se pueden generar varios informes de inventario como fragmentos. Una configuración de informes de inventario genera un informe de inventario por cada 1,000,000 de objetos en el bucket. Por ejemplo, si tienes un bucket con 3,500,000 objetos, la configuración de informes de inventario en el bucket generará cuatro fragmentos de informes de inventario según la frecuencia que especifiques, junto con un archivo de manifiesto que contiene la cantidad de fragmentos de informes de inventario generados y sus nombres de archivo.

Problema: Los informes de inventario no aparecen en el bucket de destino.

Solución: Si creaste una configuración de informes de inventario y no ves los informes de inventario que se generan en el bucket de destino, verifica lo siguiente:

  • Asegúrate de que la fecha de inicio especificada en la configuración del informe de inventario coincida con tus expectativas en cuanto a la generación de informes de inventario. Para obtener instrucciones sobre cómo especificar una fecha de inicio, consulta Crea una configuración de informes de inventario.

  • Consulta el historial de informes de inventario para verificar las fallas y sus causas raíz. Para ver su historial de informes de inventario, siga estos pasos:

    1. En la consola de Google Cloud, ve a la página Buckets de Cloud Storage.

      Ir a Buckets

    2. En la lista de buckets, haz clic en el nombre del bucket de origen que contiene la configuración del informe de inventario.

    3. En la página Detalles del bucket, haz clic en la pestaña Inventory reports.

    4. En la lista de opciones de configuración de informes de inventario, haz clic en el UUID de la configuración de informes de inventario que generó los informes que deseas verificar.

    5. Verifica si hay fallas en la sección Historial de informes de inventario. Puedes mantener el puntero sobre Ayuda () para obtener detalles sobre el motivo por el que se produjo un error.

  • Asegúrate de que se otorguen al agente de servicio a nivel de proyecto los roles de IAM necesarias para leer y escribir informes de inventario. Para obtener instrucciones, consulta Otorga roles necesarios al agente de servicio.

Problema: Veo demoras aleatorias en la generación de informes de inventario.

Solución: El intervalo de tiempo entre los informes de inventario que se generan puede variar. Es posible que veas un retraso de hasta un día.

¿Qué sigue?