Cuotas y límites de Cloud Monitoring

En este documento se indican las cuotas y los límites del sistema que se aplican a Cloud Monitoring.

  • Las cuotas tienen valores predeterminados, pero normalmente puedes solicitar ajustes.
  • Los límites del sistema son valores fijos que no se pueden cambiar.

Google Cloud usa cuotas para garantizar la equidad y reducir los picos en el uso y la disponibilidad de los recursos. Una cuota restringe la cantidad de unGoogle Cloud recurso que puede usar tu Google Cloud proyecto. Las cuotas se aplican a una serie de tipos de recursos, incluidos los componentes de hardware, software y red. Por ejemplo, las cuotas pueden restringir el número de llamadas a una API enviadas a un servicio, el número de balanceadores de carga que usa tu proyecto de forma simultánea o el número de proyectos que puedes crear. Las cuotas protegen a la comunidad de usuarios deGoogle Cloud al evitar que se sobrecarguen los servicios. Las cuotas también te ayudan a gestionar tus propios recursos. Google Cloud

El sistema de cuotas de Cloud hace lo siguiente:

En la mayoría de los casos, cuando intentas consumir más recursos de los que permite la cuota, el sistema bloquea el acceso al recurso y la tarea que intentas realizar falla.

Las cuotas se aplican generalmente a nivel de Google Cloud proyecto. El uso que hagas de un recurso en un proyecto no afectará a la cuota disponible en otro proyecto. En un Google Cloud proyecto, las cuotas se comparten entre todas las aplicaciones y direcciones IP.

Para obtener más información, consulta la descripción general de las cuotas de Cloud.

Para ajustar la mayoría de las cuotas, usa la Google Cloud consola. Para obtener más información, consulta Solicitar un ajuste de cuota.

También hay límites del sistema en los recursos de Monitoring. Los límites del sistema no se pueden cambiar.

Métricas definidas por el usuario

La página Gestión de métricas de Cloud Monitoring proporciona información que puede ayudarte a controlar el importe que gastas en métricas facturables sin que esto afecte a la observabilidad. En la página Gestión de métricas se muestra la siguiente información:

  • Volúmenes de ingesta para la facturación basada en bytes y en muestras, en todos los dominios de métricas y para métricas concretas.
  • Datos sobre las etiquetas y la cardinalidad de las métricas.
  • Número de lecturas de cada métrica.
  • Uso de métricas en políticas de alertas y paneles de control personalizados.
  • Tasa de errores de escritura de métricas.

También puede usar la página Gestión de métricas para excluir las métricas que no necesite y, de esta forma, no incurrir en los costes de ingesta. Para obtener más información sobre la página Gestión de métricas, consulta el artículo Ver y gestionar el uso de métricas.

Categoría Valor máximo
Descriptores de métricas personalizadas por proyecto1 10.000
Etiquetas por descriptor de métrica personalizada, externa y de carga de trabajo 30
Etiquetas por descriptor de métrica de Prometheus 200
Longitud de las cadenas para la clave de las etiquetas 100
Longitud de las cadenas para el valor de las etiquetas 1024
Series temporales incluidas en una solicitud de escritura2 200
Frecuencia con la que se pueden escribir datos en una serie temporal3 Un dato cada 5 segundos
Segmentos de histogramas por métrica de distribución personalizada 200
Descriptores de métricas de cargas de trabajo, de Prometheus y externos4 por proyecto 25.000
Series temporales activas de métricas personalizadas por recurso monitorizado5 200.000
Series temporales activas de métricas de carga de trabajo por recurso monitorizado5 200.000
Series temporales activas de Prometheus por recurso monitorizado5 1.000.000
Series temporales activas de métricas externas por recurso monitorizado5 200.000
Frecuencia con la que se pueden crear descriptores de métricas 6000 por minuto y proyecto

1 Este límite lo establece Cloud Monitoring. Es posible que otros servicios impongan valores máximos más bajos. Las métricas personalizadas son las que se escriben en custom.googleapis.com.
2 Solo puedes escribir un dato por cada serie temporal de una solicitud; por lo tanto, este límite también funciona como la cantidad máxima de datos que pueden escribirse por solicitud.
3 La API de Cloud Monitoring requiere que las horas de finalización de los datos escritos en cada serie temporal estén separadas por un intervalo de al menos 5 segundos. Puedes escribir datos por lotes en series temporales siempre que los datos se añadan en orden.
4 Las métricas externas son las que se escriben en external.googleapis.com.
5 Se considera que una serie temporal está activa si se le han añadido datos en las últimas 24 horas. El límite especificado en la fila es el número total de series temporales activas de un solo recurso monitorizado (por ejemplo, una sola máquina virtual gce_instance o un solo contenedor k8s_container) en todas las métricas definidas por el usuario de esa fila (personalizadas, de carga de trabajo, de Prometheus o externas). El recurso monitorizado global es una excepción, ya que, en su caso, el límite se aplica a cada métrica definida por el usuario por separado. Este límite de seguridad se utiliza en todo el sistema y no se puede personalizar.

Cuotas y límites de la API de Monitoring

Categoría Valor máximo
Límites de uso de la API

Para consultar las cuotas y los límites de las APIs, haga una de las siguientes acciones:
Duración de los tokens de página de la API 24 horas

Información sobre las cuotas de la API de Monitoring

La API de Monitoring tiene límites de cuota para las frecuencias de solicitudes de ingestión y consultas en series temporales. Las solicitudes de ingestión son llamadas que escriben datos de series temporales, y las consultas son llamadas que obtienen este tipo de datos. También hay límites internos en otros puntos de conexión de la API de Monitoring, pero no están destinados a gestionar altas frecuencias de solicitudes.

Para reducir el número de solicitudes a la API que emiten tus servicios al escribir datos de series temporales, usa una solicitud a la API para escribir datos de varias series temporales. Te recomendamos que escribas al menos 10 objetos por solicitud. Para obtener más información sobre cómo agrupar solicitudes de la API, consulta timeSeries.create.

Si, después de agrupar tus solicitudes a la API, sigues necesitando límites de cuota superiores de la API de Monitoring, ponte en contacto con el Google Cloud equipo de Asistencia.

El resto de los límites son fijos y se ajustan a la información que se describe en esta página.

Para obtener más información, consulta la documentación de cuotas de Cloud.

Conservación de datos

Los datos de las métricas anteriores al periodo de conservación se eliminan de las series temporales.

Categoría Valor
Conservación de los datos de los tipos de métricas personalizadas, externas y de agente, incluidos los siguientes:
  • Métricas personalizadas, prefijo custom.googleapis.com
  • Métricas de Google Cloud Managed Service para Prometheus, prefijo prometheus.googleapis.com2
  • Métricas de agentes, prefijo agent.googleapis.com, incluidos
    processes/count_by_state y processes/fork_state.
    El resto de las métricas processes tienen un periodo de conservación diferente. Consulta la siguiente entrada.
  • Métricas externas, prefijo external.googleapis.com
  • OpenTelemetry y otras métricas de cargas de trabajo, prefijo workload.googleapis.com
 24 meses1
Conservación de los datos de los tipos de métricas de estado del proceso: agent.googleapis.com/processes y
,agent.googleapis.com/processes excepto count_by_state y fork_state, como se indica en la entrada anterior.		 24 horas
Conservación de los datos de algunos Google Cloud servicios, incluidas la mayoría de las métricas de las siguientes categorías:
  • Métricas de Compute Engine, prefijo compute.googleapis.com
  • Métricas de GKE y GKE Enterprise, prefijo kubernetes.io
  • Métricas de Cloud Storage, prefijo storage.googleapis.com
  • Métricas de BigQuery, prefijo bigquery.googleapis.com
  • Métricas de Cloud SQL, prefijo cloudsql.googleapis.com
  • Métricas de balanceadores de carga internos, HTTPS y L7, prefijo loadbalancing.googleapis.com
 24 meses1
Conservación de los datos del resto de los tipos de métricas, incluidos los siguientes: 6 semanas
Duración de los tokens de página de la API 24 horas

1 Los datos de métricas se almacenan durante 6 semanas en su frecuencia de muestreo original. Después, el muestreo se reduce a intervalos de 10 minutos cuando se amplía el espacio de almacenamiento.
2 Los datos de métricas de Google Cloud Managed Service para Prometheus se almacenan durante 1 semana en su frecuencia de muestreo original. Después, el muestreo se reduce a intervalos de 1 minuto durante las 5 semanas siguientes y, a continuación, se reduce a intervalos de 10 minutos para ampliar el almacenamiento.

Grupos de recursos

Categoría Valor
Número de grupos de recursos por ámbito de métricas 500
Número máximo de grupos incluidos en un informe por correo electrónico1 10

1 Cuando configuras los informes por correo electrónico de Cloud Monitoring, puedes solicitar información sobre el uso de tus grupos de recursos. Debido a las limitaciones del generador de este tipo de informes, estos solo incluyen la información de 10 grupos.

Límites de proyectos monitorizados

Cloud Monitoring admite oficialmente hasta 375 Google Cloud proyectos por ámbito de métricas .

Puede añadir hasta 3500 Google Cloud proyectos por ámbito de métricas, pero puede que experimente problemas de rendimiento, sobre todo al consultar métricas personalizadas o datos históricos. Cloud Monitoring solo garantiza consultas y gráficos eficientes para 375 Google Cloud proyectos por permiso de métricas .

Para aumentar la cuota de Google Cloud proyectos por ámbito de las métricas, puedes solicitar un aumento de la cuota "Proyectos monitorizados/Ámbito de las métricas de monitorización". Para obtener más información, consulta la documentación sobre cómo gestionar tu cuota.

Límites para crear y actualizar descriptores de métricas

Cloud Monitoring aplica un límite de frecuencia por minuto a la creación de métricas, a la adición de nombres de etiquetas a métricas y a la eliminación de métricas. Este límite de frecuencia solo se suele alcanzar cuando se integra por primera vez con Cloud Monitoring, por ejemplo, cuando se migra una implementación de Prometheus antigua a Cloud Monitoring. No se trata de un límite de frecuencia para ingerir puntos de datos. Este límite de frecuencia solo se aplica cuando se crean métricas que no se han usado antes o cuando se añaden nombres de etiquetas nuevos a métricas que ya existen.

Esta cuota es fija, pero los problemas deberían resolverse automáticamente a medida que se creen nuevas métricas y etiquetas de métricas hasta alcanzar el límite por minuto.

Límites de alertas

Categoría Valor Tipo de política1
Políticas de alertas (suma de métricas y registros) por ámbito de métricas 2 2000 Métrica, registro
Condiciones por política de alertas basada en métricas 6 Métrica
Condiciones por política de alertas basada en SQL (vista previa pública) 1 SQL
Tiempo máximo de ejecución de consultas de una política de alertas basada en SQL (versión preliminar pública) 5 minutos SQL
Periodo máximo durante el que se evalúa una condición de ausencia de métrica.
3		 1 día Métrica
Periodo máximo durante el que se evalúa una condición de umbral de métrica.
3		 23 horas y 30 minutos Métrica
Longitud máxima del filtro usado
en una condición de umbral de métrica		 2048 caracteres Unicode Métrica
Número máximo de series temporales
monitorizadas por una condición de previsión		 64 Métrica
Ventana de previsión mínima 1 hora (3600 segundos) Métrica
Ventana de previsión máxima 2,5 días (216.000 segundos) Métrica
Canales de notificaciones por política de alertas 16 Todo
Frecuencia máxima de incidentes4
de alertas basadas en registros		 1 incidente cada 5 minutos Registro
Número máximo de incidentes
de alertas basadas en registros		 20 incidentes al día por cada política de alertas basada en registros Registro
Número máximo de notificaciones por incidente: 5
para alertas basadas en registros		 20 notificaciones al día por incidente Registro
Número máximo de políticas de alertas que se pueden activar simultáneamente
por proyecto		 80.000 Todo
Número máximo de incidentes abiertos simultáneamente
por política de alertas		 1000 Todo
Periodo tras el cual se
cierra automáticamente una incidencia sin datos nuevos		 7 días Métrica, SQL
Duración máxima de un incidente si no se cierra manualmente 7 días Registro
Conservación de incidentes cerrados 13 meses No aplicable
Conservación de incidentes abiertos Indefinida No aplicable
Canales de notificación por ámbito de métricas 4000 No aplicable
Número máximo de políticas de alertas por suspensión 16 Todo
Retención de una posposición 13 meses No aplicable
1Métrica: una política de alertas basada en datos de métricas. Registro: una política de alertas basada en mensajes de registro (alertas basadas en registros).
2Puedes solicitar que se aumente este límite,que es de 2000 políticas por ámbito de métricas,hasta 10.000 políticas por ámbito de métricas.
3El periodo máximo durante el que se evalúa una condición es la suma de los valores del periodo de alineación y de la ventana de duración. Por ejemplo, si el periodo de alineación es de 15 horas y el periodo de duración es de 15 horas, se necesitan 30 horas de datos para evaluar la condición.
4Si la consulta de tu política de alertas basada en registros extrae valores de etiquetas, cada combinación de valores extraídos representa su propia cronología de incidentes. Por ejemplo, supongamos que una política de alertas basada en registros extrae los valores de una etiqueta y que la etiqueta puede tener dos valores. Con esta configuración, se pueden crear dos incidencias, una por cada valor de etiqueta, en el mismo periodo de 5 minutos.
5En el caso de las alertas basadas en registros, Monitoring envía una nueva notificación de un incidente abierto cuando se recibe una entrada de registro que coincide con el filtro y han transcurrido al menos 5 minutos desde la notificación más reciente. Se envían como máximo 20 notificaciones al día por incidencia. Cada notificación se envía a todos los canales de notificaciones configurados para la política de alertas.

Límites de los mensajes SMS

Los límites de mensajes SMS se aplican en un periodo de 24 horas.

Categoría Valor
Número de códigos de verificación por SMS 40
Número de códigos de verificación por SMS por número de teléfono 5
Número de mensajes de alerta por SMS 2500
Número de mensajes de alerta por SMS por número de teléfono 200

Límites de los monitores sintéticos

Categoría Valor
Comprobaciones de disponibilidad por ámbito de métricas * 100
Número máximo de pings ICMP por comprobación de disponibilidad del servicio pública 3
Monitores sintéticos por ámbito de métricas 100†
*Este límite se aplica al número de configuraciones de comprobación de disponibilidad del servicio. Cada configuración de comprobación de disponibilidad incluye el intervalo de tiempo que transcurre cuando se prueba el estado del recurso especificado.
†Para obtener información sobre cómo aumentar este límite, consulta el artículo Solicitar un ajuste de cuota.

Límites de gráficos

Categoría Valor
Paneles de control por ámbito de métricas 1000
Gráficos en un panel de control 100
Conservación del historial de versiones del panel de control 90 días
Líneas en un gráfico 50*
Filas de una tabla 300
*Este límite se aplica por motivos de rendimiento. Si hay más de 50 series temporales para representar en un gráfico, se añade un icono con un punto rojo a la barra de herramientas. La descripción emergente del icono muestra el mensaje To improve performance, we've limited the time series displayed in this chart. Para mostrar todas las series temporales, despliega la descripción emergente y selecciona el botón Mostrar todas las series temporales.

Objetivos de nivel de servicio

Categoría Valor
Número de objetivos de nivel de servicio por servicio 500