Storage Intelligence detecta cuatro anomalías: el diagnóstico exige permisos
Para usar Storage Intelligence Advisor, configura Storage Intelligence en el proyecto, la carpeta o la organización, concede acceso de consulta y abre Top findings. El asesor detecta cuatro anomalías y permite seguir un hallazgo desde el proyecto afectado hasta los buckets, prefijos y cuentas de servicio con los mayores incrementos.
El recorrido depende de IAM: ver el resumen de una organización o carpeta no garantiza que puedas abrir los detalles de todos sus proyectos. Si falta acceso en uno de ellos, el diagnóstico se detiene en ese límite; el vacío no demuestra que el proyecto carezca de actividad anómala.
Separar la configuración de la investigación
Activar el producto y consultar sus hallazgos son tareas distintas. La guía de configuración de Storage Intelligence indica que administrar la configuración requiere storage.intelligenceConfigs.update y storage.intelligenceConfigs.get. En la consola, abre Storage Intelligence Configuration, pulsa Enable Storage Intelligence, elige el ámbito y, si es necesario, incluye o excluye buckets por ubicación o mediante expresiones regulares aplicadas a sus nombres.
Google recomienda el rol predefinido Storage Admin, roles/storage.admin, porque contiene esos permisos. Una política de privilegio mínimo puede separar la identidad que modifica la configuración de la que investiga hallazgos; los roles personalizados también son posibles si incluyen todos los permisos exigidos para la tarea.
Para consultar el asesor se necesitan storage.intelligenceConfig.get para el resumen y storage.buckets.viewIntelligenceDetails para el asesor, los hallazgos, sus detalles y el desglose por bucket. También hacen falta los permisos de lectura que la documentación enumera para paneles, grupos, métricas, descriptores y metadatos de Cloud Monitoring; usar Gemini para solucionar problemas añade cloudaicompanion.instances.completeTask.
No amplíes permisos solo para eliminar un aviso. Primero define si la persona debe configurar Storage Intelligence, investigar un hallazgo o ejecutar su corrección: cambiar la ubicación de un bucket, su clase de almacenamiento o una regla de ciclo de vida es una operación distinta y puede requerir acceso adicional.
Recorrer el hallazgo hasta la carga responsable
En Google Cloud Console, abre Storage Intelligence Advisor y selecciona el proyecto, la carpeta o la organización. Comprueba el ámbito en At a glance, entra en Top findings y abre View details en la anomalía que quieras investigar.
En una organización o carpeta, la tarjeta resume los proyectos afectados. Si un proyecto muestra el indicador de permisos insuficientes, solicita acceso sobre ese proyecto: el asesor ha registrado allí un hallazgo, pero tu identidad no puede abrir sus gráficos ni sus detalles.
La ruta oficial de investigación muestra la categoría, la última actualización, los factores comunes y el incremento total del proyecto. Después permite bajar a la tabla de buckets con mayores incrementos y, al abrir uno, examinar su actividad, los prefijos con mayores aumentos y las cuentas de servicio o identidades que enviaron más solicitudes.
- Confirma la categoría del hallazgo, su última actualización y el incremento total del proyecto.
- Ordena los buckets por contribución al aumento y abre los que expliquen una parte relevante del cambio.
- Relaciona el prefijo destacado con la carga que lee, escribe o enumera esos objetos.
- Identifica la cuenta de servicio, su propietario y los despliegues o tareas programadas que coincidieron con el intervalo.
- Aplica la recomendación únicamente cuando el recurso, la identidad, la métrica y el periodo formen una explicación coherente.
El desglose acota la causa, pero no la prueba por sí solo. Una cuenta de servicio puede atender varias cargas y un prefijo con mucho tráfico no tiene por qué haber originado el incremento que activó el hallazgo.
Qué significa cada una de las cuatro anomalías
El catálogo de Storage Intelligence Advisor define cuatro hallazgos: un pico de operaciones de clase A o B sobre datos Coldline o Archive, un pico de errores 429, un aumento de salida entre regiones y un crecimiento del total almacenado por encima de la tendencia durante los últimos 30 días. Las recomendaciones cambian según la métrica.
- Operaciones de clase A o B: localiza el bucket, el prefijo y la identidad cuyo uso aumentó. Si datos de Coldline o Archive se consultan con frecuencia, considera una clase adecuada para accesos frecuentes; si el patrón procede de un trabajo repetitivo, ajusta la carga o utiliza datos en caché. No cambies todo el bucket si el incremento está concentrado en un prefijo.
- Errores 429: comprueba qué cuenta y patrón de objetos concentran las solicitudes limitadas. La corrección indicada es implementar retroceso exponencial o aumentar gradualmente el ritmo de peticiones; conceder más permisos no elimina la limitación de solicitudes.
- Salida entre regiones: contrasta la región del bucket con la del servicio de Google Cloud que consume los datos. La colocación conjunta mediante reubicación del bucket puede reducir costes de salida y mejorar el rendimiento, pero antes debes considerar las demás cargas que dependen de su ubicación.
- Crecimiento de almacenamiento: revisa el volumen y el porcentaje de crecimiento y distingue los datos nuevos esperados de versiones no vigentes conservadas indefinidamente. Object Lifecycle Management puede eliminar o trasladar esas versiones, mientras que Autoclass administra clases según los patrones de acceso; ninguna opción sustituye los requisitos de conservación.
Tratar los buckets eliminados como datos históricos
El asesor conserva durante 390 días metadatos agregados de buckets y datos de actividad, incluidos los correspondientes a buckets eliminados. Por eso un hallazgo puede mencionar un recurso que ya no aparece en el inventario activo; esa presencia histórica no demuestra que el bucket siga existiendo ni generando actividad.
Compara la marca temporal del hallazgo con el inventario actual y con los registros de cambios. Si el bucket se eliminó después del periodo anómalo, conserva el hallazgo como evidencia de lo ocurrido y busca la identidad o la carga que operaba entonces. Si continúa activo, sigue el desglose y evalúa la corrección asociada a la anomalía.
Cerrar el diagnóstico con evidencia coincidente
La causa queda suficientemente acotada cuando coinciden el intervalo temporal, la métrica afectada, el bucket, el prefijo o patrón de objetos y la identidad que ejecutó la actividad. Documenta también la intervención elegida: ajustar la carga, aplicar retroceso, acercar recursos, cambiar la clase de almacenamiento o establecer una regla de ciclo de vida.
Tras el cambio, conserva el valor previo y observa la misma métrica en el siguiente periodo disponible. Que una tarjeta desaparezca no basta para atribuir el resultado: la conclusión debe seguir vinculada al recurso, la identidad y el comportamiento que explicaban el incremento.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.