Precios de Cloud Monitoring
Los precios de Google Cloud Observability te permiten controlar el uso y gastos. Los productos de Google Cloud Observability se cobran por volumen de datos o de uso de la nube. Puedes usar las asignaciones gratuitas de uso de datos para comenzar sin de pago o compromisos por adelantado.
En las siguientes tablas, se resume la información de precios de Cloud Logging, Cloud Monitoring y Cloud Trace.
Resumen de precios de Cloud Logging
Función | Precio1 | Asignación gratuita por mes |
---|---|---|
Almacenamiento de Logging* | $0.50 por GiB; Se cobra un solo cargo por la transmisión de registros al almacenamiento de bucket de registros para indexación, consulta, y análisis; incluye hasta 30 días de almacenamiento en buckets de registros. No se aplican cargos adicionales por consultar y analizar datos de registros. |
Primeros 50 GiB por proyecto al mes |
Retención de Logging† | Se facturará mensualmente $0.01 por GiB para los registros retenidos durante más de 30 días según la retención. | Los registros retenidos durante el período de retención predeterminado no generan ningún costo de retención. |
Enrutador de registros‡ | Sin cargos adicionales | No aplicable |
Análisis de registros♣ | Sin cargos adicionales | No aplicable |
_Required
.† No se aplican cargos de retención para los registros almacenados en el bucket de registros
_Required
,
que tiene un período fijo de 400 días.‡ El enrutamiento de registros se define como el reenvío de registros recibidos a través de la API de Cloud Logging a un destino admitido. Es posible que se apliquen cargos de destino a los registros enrutados.
♣ No se aplican cargos por actualizar un bucket de registros para usar el Análisis de registros o emitir consultas en SQL en la página Análisis de registros.
Nota: El lenguaje de precios de Cloud Logging cambió el 19 de julio de 2023. Sin embargo, las asignaciones gratuitas y las tarifas no han cambiado. Tu factura podría referirse a la transacción idioma de los precios.
Resumen de precios de Cloud Monitoring
Función | Precio | Asignación gratuita por mes | Fecha de entrada en vigencia |
---|---|---|---|
Todos los datos de Monitoring excepto los datos transferidos a través de Managed Service para Prometheus |
$0.2580 por MiB1: En primer lugar, de 150 a 100,000 MiB $0.1510 por MiB: después de 100,000–250,000 MiB $0.0610 por MiB: > 250,000 MiB |
Todas las métricas de Google Cloud no cobrables Primeros 150 MiB por cuenta de facturación para métricas cobradas por bytes transferidos |
1 de julio de 2018 |
Métricas transferidas a través de Google Cloud Managed Service para Prometheus, lo que incluye Métricas del plano de control de GKE | $0.06 por millón de muestras†: primeros entre 0 y 50,000 millones de muestras transferidas† $0.048 por millón de muestras: los próximos 50 a 250,000 millones de muestras transferidas $0.036 por millón de muestras: los próximos 250 a 500,000 millones de muestras transferidas $0.024 por millón de muestras: más de 500,000 millones de muestras transferidas |
No aplicable | 8 de agosto de 2023 |
Llamadas a la API de Monitoring | $0.01 por cada 1,000 llamadas a la API de Read (las llamadas a la API de Write son gratuitas) |
Se incluye el primer millón de llamadas a la API de Read por cuenta de facturación | 1 de julio de 2018 |
La ejecución de Supervisa verificaciones de tiempo de actividad | $0.30 por cada 1,000 ejecuciones‡ | 1 millón de ejecuciones por proyecto de Google Cloud | 1 de octubre de 2022 |
Ejecución de Supervisa monitores sintéticos | $1.20 por cada 1,000 ejecuciones* | 100 ejecuciones por cuenta de facturación | 1 de noviembre de 2023 |
Políticas de alertas | $1.50 por mes para cada condición en una política de alertas $0.35 por 1,000,000 series temporales que se devuelven con la consulta de una condición de política de alertas de métricas♣ |
No aplicable | 7 de enero de 2025 |
# Las muestras se cuentan por cuenta de facturación.
‡ Las ejecuciones se cobran a la cuenta de facturación en la que se definieron. Para obtener más información, consulta Precios de la ejecución de verificaciones de tiempo de actividad.
* Las ejecuciones se cobran a la cuenta de facturación en la que se definieron. Por cada ejecución, podrías incurrir en cargos adicionales de otros servicios de Google Cloud, incluidos servicios como Cloud Functions, Cloud Storage y Cloud Logging. Para obtener información sobre estos cargos adicionales, consulta el documento de precios del servicio de Google Cloud correspondiente.
♣ Para obtener más información, consulta Precios por alertas.
Resumen de precios de Cloud Trace
Función | Precio | Asignación gratuita por mes | Fecha de entrada en vigor |
---|---|---|---|
Transferencia de Trace | $0.20 por cada millón de intervalos | Los primeros 2.5 millones de intervalos por cuenta de facturación | 1 de noviembre de 2018 |
Para obtener información detallada sobre los costos de los productos de Google Cloud Observability, consulta las siguientes secciones de esta página:
Para obtener información sobre los precios de GKE Enterprise, consulta GKE Enterprise.
Visualiza tu uso
Para ver tu uso actual, ve a la página Informes de Facturación de Cloud de la consola de Google Cloud
Puedes usar la calculadora de precios para calcular la facturación según tus datos de uso actuales.
Por ejemplo, considera una configuración en la que cada instancia de VM de Compute Engine genera 10 GiB de registros cobrables y 20 MiB de métricas cobrables por mes. Puedes determinar los costos previstos de Cloud Monitoring y Cloud Logging mediante la calculadora de precios.
1 VM | 10 VMs | 100 VM | 1,000 VM | |
---|---|---|---|---|
Costo de las métricas por mes | $0.00 | $12.90 | $477.30 | $5,121.30 |
Costo de Logging por mes | $0.00 | $25.00 | $475.00 | $4,975.00 |
Costo total | $0.00 | $37.90 | $952.30 | $10,096.30 |
Configura una alerta de facturación
Para recibir una notificación si tus cargos facturables o previstos superan un presupuesto, Crea una alerta con la página Presupuestos y alertas de la consola de Google Cloud:
-
En la consola de Google Cloud, ve a la página Facturación:
También puedes usar la barra de búsqueda para encontrar esta página.
Si tienes más de una cuenta de Facturación de Cloud, realiza una de las siguientes acciones: lo siguiente:
- Si quieres administrar la Facturación de Cloud para el proyecto actual, selecciona Ir a la cuenta de facturación vinculada.
- Si deseas ubicar otra cuenta de Facturación de Cloud, selecciona Administrar cuentas de facturación y elige la cuenta para la que deseas configurar un presupuesto.
- En el menú de navegación de Facturación, selecciona Presupuestos y alertas.
- Haz clic en Crear presupuesto .
- Completa el diálogo del presupuesto. En este cuadro de diálogo, seleccionarás proyectos y productos de Google Cloud y, luego, crearás un presupuesto para esa combinación. De forma predeterminada, se te notifica cuando alcanzas el 50%, el 90% y el 100% del presupuesto. Para ver la documentación completa, consulta Configura presupuestos y alertas de presupuesto.
Cloud Logging
Los buckets de registros son los contenedores de Logging que almacenan datos de registros.
Logging cobra por el volumen de datos de registro que se almacenan.
En el bucket de registros _Default
y en los buckets de registros definidos por el usuario,
cuando ese volumen supere el
asignación mensual gratuita.
Para el bucket de registros _Default
y los buckets de registros definidos por el usuario,
Logging también cobra cuando los registros
se retendrán por un período superior al período de retención predeterminado, que
30 días.
Logging no genera cargos adicionales
por enrutar los registros
para usar la API de Cloud Logging o para los registros almacenados en el bucket de registros _Required
,
que tiene un período fijo de 400 días.
En esta sección, se proporciona información sobre los siguientes temas:
- Modelo de almacenamiento de Cloud Logging
- Precios de almacenamiento
- Precios de retención
- Reduce el almacenamiento de tus registros
- Precios de las métricas basadas en registros
- Crear una política de alertas sobre los bytes de registros transferidos mensualmente
Para obtener un resumen de la información de precios, consulta Resumen de precios de Cloud Logging.
Para ver los límites que se aplican a tu uso de Logging, incluidos los períodos de retención de datos, consulta Cuotas y límites.
Para ver y comprender los datos de uso de Cloud Logging, consulta Estima tu facturación.
Modelo de almacenamiento de Cloud Logging
Para cada proyecto de Google Cloud, Logging
Crea dos buckets de registros: _Required
y _Default
.
Para estos dos buckets, Logging crea receptores de registros automáticamente
con el nombre _Required
y _Default
, que enrutan los registros al nombre correspondiente
buckets de registros. No puedes inhabilitar ni modificar el receptor _Required
. Puedes inhabilitar
o modificar el receptor _Default
para evitar que el bucket _Default
almacenar registros nuevos.
Puedes crear buckets de registros definidos por el usuario en cualquiera de tus proyectos de Google Cloud. También puedes configurar receptores para enrutar cualquier combinación de registros, incluso en proyectos de Google Cloud en tu organización de Google Cloud a estos buckets de registros.
Para los bucket de registros _Default
y los definidos por el usuario, puedes hacer lo siguiente:
configura un período de retención personalizado.
Puedes actualizar tus buckets de registros para usar Análisis de registros. No se aplican cargos por actualizar un bucket de registros para usar el Análisis de registros.
Para obtener más información sobre los buckets y receptores de Cloud Logging, consulta Descripción general del enrutamiento y el almacenamiento.
Precios de almacenamiento
Logging no cobra por los registros almacenados en el bucket _Required
.
No puedes borrar el bucket _Required
ni modificar el receptor _Required
.
El bucket _Required
almacena los siguientes registros:
- Registros de auditoría de actividad del administrador
- Registros de auditoría de eventos del sistema
- Registros de auditoría del administrador de Google Workspace
- Registros de auditoría de los grupos empresariales
- Registros de auditoría de acceso
- Registros de Transparencia de acceso. Para obtener información sobre cómo habilitar los registros de Transparencia de acceso, consulta el Documentación de los registros de Transparencia de acceso.
Logging cobra por el volumen preindexado de datos de registros que
almacenados en el bucket de registros _Default
y en buckets de registros definidos por el usuario
cuando el volumen total supere la asignación mensual gratuita.
Cada operación de escritura de una entrada de registro en el bucket de registros _Default
o en un
de bucket de registros definido por el usuario cuenta para tu asignación de almacenamiento.
Por ejemplo, si tienes receptores que enrutan una entrada de registro a
tres buckets de registro, entonces esa entrada de registro se almacena tres veces.
Precios de retención
En la siguiente tabla, se indican los períodos de retención de datos de los registros almacenados en buckets de registros:
Bucket | Período de retención predeterminado | Retención personalizada |
---|---|---|
_Required |
400 días | No configurable |
_Default |
30 days | Configurable |
Definido por el usuario | 30 days | Configurable |
Logging cobra los costos de retención cuando los registros se conservan por más tiempo
que el período de retención predeterminado. No puedes configurar el período de retención
para el bucket de registros _Required
.
No hay costos de retención cuando los registros se almacenan
el período de retención predeterminado
del bucket de registros.
Si acortas el período de retención de un bucket de registros, hay una ventana período de gracia en el que los registros vencidos no se borran. No puedes consultar ni ver registros vencidos. Sin embargo, en esos siete días, puedes restablecer el acceso completo extender el período de retención del bucket de registros. Los registros almacenados durante el período de gracia se tienen en cuenta para tus costos de retención.
Si enrutas una entrada de registro a varios buckets, se te cobrará
de almacenamiento y retención muchas veces. Por ejemplo, supongamos que enrutas
una entrada de registro al bucket de registros _Default
y a un bucket de registros definido por el usuario
Además, supongamos que configuras un período de retención personalizado para ambos buckets
que sea superior a 30 días. Para esta configuración,
recibes dos cargos de almacenamiento
y dos de retención.
Reduce el almacenamiento de tus registros
Logging te permite identificar y excluir manualmente entradas de registro de que se almacenan en buckets de registros mediante la configuración de filtros de exclusión en tus receptores. Con los filtros de exclusión, puedes reducir los costos de almacenamiento. Por otro lado, considera también si debes enrutar tus registros fuera de Cloud Logging.
Los filtros de exclusión pueden quitar todas las entradas de registro que coincidan con el filtro, o puede quitar solo un porcentaje de los registros que coinciden con el filtro. Cuando una entrada de registro coincide con un filtro de exclusión para un receptor, ese receptor no enruta la entrada de registro al destino. Como resultado, el el destino no transfiere la entrada de registro. Las entradas de registro excluidas no cuentan según tu asignación de almacenamiento. Para obtener instrucciones sobre la configuración filtros de exclusión, consulta Exclusiones de registros.
Para retener el acceso a los registros que no están almacenados en buckets de registros, también puedes usar receptores de registros para enrutar entradas de registro de Cloud Logging a una destino. Cloud Logging no cobra por enrutar los registros. Sin embargo, los servicios de Google Cloud que reciben tus registros te cobran para el uso. Para obtener más información, consulta los siguientes documentos:
Para obtener información sobre el enrutamiento de registros fuera de Cloud Logging, consulta Enruta registros a destinos compatibles.
Precios de las métricas basadas en registros
Las métricas basadas en registros definidas por el sistema se proporcionan para todos los proyectos de Google Cloud y no son cobrables.
Las métricas basadas en registros definidas por el usuario son una clase de métricas personalizadas de Cloud Monitoring y son cobrables. Para obtener más información sobre los precios, consulta las métricas cobrables.
Para obtener más información, consulta Descripción general de las métricas basadas en registros.
Crear una política de alertas sobre los bytes de registros transferidos mensualmente
Para crear una política de alertas que se active cuando la cantidad de bytes de registro escritos en tus buckets de registros exceden el límite definido por el usuario para Cloud Logging, usa la siguiente configuración.
Nueva condición Campo |
Valor |
---|---|
Recurso y métrica | En el menú Recursos, selecciona Global. En el menú Categorías de métricas, selecciona Métrica basada en registros. En el menú Métricas, selecciona Bytes de registros mensuales transferidos. |
Filtro | Ninguno |
Series temporales Agregación de series temporales |
sum |
Ventana progresiva | 60 m |
Función analítica progresiva | max |
Configura el activador de alertas Campo |
Valor |
---|---|
Tipo de condición | Threshold |
Activador de alertas | Any time series violates |
Posición del umbral | Above threshold |
Valor del umbral | Tú determinas el valor aceptable. |
Período para volver a probar | El valor mínimo aceptable es 30 minutos. |
Cloud Monitoring
Monitoring cobra lo siguiente:
Métricas medidas por bytes transferidos cuando los datos de métricas transferidos exceden la asignación mensual gratuita de métricas.
Las métricas no cobrables no cuentan para el límite de la asignación.
Métricas medidas por la cantidad de muestras transferidas.
Llamadas de lectura a la API de Cloud Monitoring que superan la asignación mensual gratuita de la API
Las llamadas de escritura a la API de Monitoring no cuentan para el límite de asignación.
La ejecución de verificaciones de tiempo de actividad
Ejecución de supervisores sintéticos.
Condiciones de la política de alertas medidas por la cantidad de condiciones activas por mes.
Series temporales que muestra la consulta de una condición de política de alertas.
En Monitoring, la transferencia se refiere al proceso de escritura de series temporales en Monitoring. Cada serie temporal incluye una cantidad de datos; esos datos son la base de los cargos por transferencia. Para obtener información sobre los precios, consulta Precios de Cloud Monitoring.
En esta sección, se proporciona la siguiente información:
- Definiciones de las métricas cobrables y no cobrables.
- Descripciones de las estrategias de transferencia basadas en bytes y de muestra
- Ejemplos de precios para métricas cobradas por bytes transferidos.
- Ejemplos de precios para métricas cobradas por muestras transferidos.
- Ejemplos de precios para la ejecución de verificaciones de tiempo de actividad (Fecha de entrada en vigencia: 1 de octubre de 2022).
- Ejemplos de precios para la ejecución de monitores sintéticos (Fecha de entrada en vigencia: 1 de noviembre de 2023).
- Descripciones y ejemplos de precios por alertas (Fecha de entrada en vigencia: 7 de enero de 2025).
Para obtener información de los precios actuales, consulta Precios de Cloud Monitoring.
Para ver los límites que se aplican en el uso de Monitoring, consulta Cuotas y límites.
Para consultar tu uso actual, realiza una de las siguientes acciones:
-
En la consola de Google Cloud, ve a la página Facturación:
También puedes usar la barra de búsqueda para encontrar esta página.
-
En la consola de Google Cloud, ve a la página settings Configuración de Monitoring:
Ir a Configuración de Monitoring
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitoring.
Puedes calcular tus facturas según tus datos de uso actuales.
Métricas no cobrables
Los datos de métricas de Google Cloud, GKE Enterprise y Knative no son cobrable. A continuación se detallan las métricas que no son cobrables (gratuitas):
- Métricas de Google Cloud. Para obtener información adicional, consulta la nota 2 al pie de página
- Métricas de GKE Enterprise. Para obtener información adicional, consulta la nota 2 al pie de página
- Métricas de Istio
- Métricas de Knative
- Métricas del sistema de Google Kubernetes Engine
- Métricas de
agent.googleapis.com/agent/
Métricas cobrables
Todos los datos de métricas, excepto las métricas que se enumeran en la sección titulada Métricas no cobrables, son cobrables. La mayor parte de la transferencia de métricas se cobra según la cantidad de bytes, pero algunas se cobran según la cantidad de muestras. Estos modelos de precios se describen en las secciones siguientes.
Los siguientes factores contribuyen a los costos de transferencia:
El tipo de datos (valores escalares o de distribución) que recopilan las métricas.
- Para obtener información sobre el tipo de datos asociado con un tipo de métrica específico, consulta la lista de métricas.
- Para obtener información sobre los tipos de datos escalares y de distribución, consulta Tipos de valores.
Es la cantidad de datos escritos en la serie temporal. Este valor depende de la frecuencia con la que se realizan las muestras de datos y la cardinalidad de tus datos. La cardinalidad determina cuántas series temporales se generan para una combinación de tipos de métricas y recursos supervisados. Para obtener más información, consulta Cardinalidad.
Los valores de la etiqueta de métrica y recursos que forman parte de las series temporales no contribuyen a los cargos.
Métricas que cobran los bytes transferidos
Las siguientes métricas son cobrables y se cobran según la cantidad de bytes transferidos:
Métricas del agente en
agent.googleapis.com
, excepto la Grupoagent.googleapis.com/agent/
A partir del 6 de agosto de 2021, las métricas
agent.googleapis.com/processes/
se cobrarán al 5% de la tarifa por volumen de otras métricas cobrables. Por ejemplo, transferir 100 MiB de métricas de procesos costará lo mismo que transferir 5 MiB de otras métricas cobrables.3Métricas de integraciones en terceros con el agente de operaciones. Estas métricas se transfieren a Cloud Monitoring con identificadores del formulario
workload.googleapis.com/APPLICATION.METRIC
; por ejemplo, el tipo de métricaworkload.googleapis.com/nginx.requests
cae dentro de esta categoría.las métricas del protocolo OpenTelemetry (OTLP) transferidas a Cloud Monitoring como Métricas de
workload.googleapis.com
por el Agente de operaciones. Esta es una configuración opción; Para obtener más información, consulta Formatos de transferencia para OTLP métricas.Métricas personalizadas, incluidas, sin limitaciones, las métricas enviadas mediante el la API de Cloud Monitoring o las bibliotecas cliente de lenguaje específico, OpenCensus y OpenTelemetry
Para determinar los precios, el volumen de transferencia se calcula de la siguiente manera:
- Para un tipo de dato escalar: 8 bytes por cada dato escrito en una serie temporal. Las métricas de contadores definidas por el usuario y basadas en registros entran en esta categoría.
- Para un tipo de datos de distribución: 80 bytes por cada dato escrito en una serie temporal.
Para obtener información sobre los datos en series temporales, consulta Series temporales: datos de un recurso supervisado.
Métricas que cobran las muestras transferidas
Las siguientes métricas son cobrables y se cobran según la cantidad de muestras transferidas:
- Métricas de Google Cloud Managed Service para Prometheus
prometheus.googleapis.com
Para determinar los precios, el conteo de muestra se calcula de la siguiente manera:
- Para un tipo de dato escalar: 1 por cada punto escrito en una serie temporal.
- En el caso de un tipo de datos de distribución, se consideran 2 por cada punto escrito en una serie temporal, más 1 por cada bucket de histograma que tiene un recuento distinto de cero.
Para obtener información sobre los datos en series temporales, consulta Series temporales: datos de un recurso supervisado.
Alerta de métricas transferidas
No se puede crear una alerta en función de las métricas mensuales transferidas. Sin embargo, puedes crear una para tus costos de Cloud Monitoring. Si quieres obtener más información, consulta Configura una alerta de facturación.
Ejemplos de precios basados en bytes transferidos
En los siguientes ejemplos, se muestra cómo obtener una estimación de los costos de recopilación de datos de métricas para las métricas que se cobran por bytes transferidos. Estos ejemplos tienen el propósito de ilustrar los cálculos. Usa la calculadora de precios para obtener estimaciones más completas. Si accedes a esta herramienta, utiliza producto Google Cloud Observability para ingresar tus datos de métricas, registros y seguimiento.
El escenario básico es el siguiente: tienes un número de recursos supervisados, como Compute Engine, Google Kubernetes Engine o App Engine, que escriben datos a partir de un número de métricas todos los meses.
Las variables entre los escenarios incluyen:
- La cantidad de recursos
- La cantidad de métricas
- Si las métricas son de Google Cloud o no
- La velocidad a la que se escriben estos datos
Los ejemplos de esta sección son para precios de Monitoring a partir de julio de 2020.
Trasfondo común
En los siguientes ejemplos de precios, se supone que cada dato de métrica transferido es del tipo doble, int64 o booleano. Estos tipos cuentan como 8 bytes para el cálculo de precios. Hay aproximadamente 730 horas (365 días/12 meses × 24 horas) en un mes, o 43,800 minutos.
Para cada dato de métrica que se escribe a una velocidad de 1 dato por minuto en un mes, el cálculo es el siguiente:
- Datos totales: 43,800
- Volumen transferido total:
- 350,400 bytes (43,800 datos × 8 bytes)
- 0.33416748 MiB (350,400 bytes/1,048,576 bytes/MiB)
Para cada dato de métrica que se escribe a una velocidad de 1 dato/hora en un mes, el cálculo es el siguiente:
- Datos totales: 730
- Volumen transferido total:
- 5,840 bytes (730 datos × 8 bytes)
- 0.005569458 MiB (5,840 bytes/1,048,576 bytes/MiB)
Ejemplos
Situación 1: Tienes 1,000 recursos y cada uno escribe 75 métricas. Estas métricas solo corresponden a Google Cloud y se escriben a una velocidad de 1 dato/minuto.
- Transferencia mensual: 25,063 MiB: 0.33416748 MiB para una métrica × 75,000 (es decir, 1,000 recursos, 75 métricas)
- Costo aproximado por mes: $0.00 (las métricas de Google Cloud se incluyen de forma gratuita)
MiB transferidos | Tarifa ($/MiB) | Costo ($) | |
---|---|---|---|
Sin límite | 0.00 | $0.00 | |
Total | 25,063 | $0.00 |
Situación 2: Tienes 1,000 recursos y cada uno escribe 75 métricas personalizadas. Estas son métricas cobrables que se escriben a una velocidad de 1 dato por minuto.
- Transferencia mensual: 25,063 MiB (igual que la anterior)
- Costo aproximado por mes: $6,427.55
MiB transferidos | Tarifa ($/MiB) | Costo ($) | |
---|---|---|---|
150 | 0.00 | $0.00 | |
24,913 | 0.258 | $6,427.55 | |
Total | 25,063 | $6,427.55 |
Situación 3: Tienes 1,000 recursos y cada uno escribe 75 métricas personalizadas. Estas son métricas cobrables que se escriben a una velocidad de 1 dato por hora.
- Transferencia mensual: 418 MiB = 0.005569458 MiB para una métrica × 75,000
- Costo aproximado por mes: $69.14
MiB transferidos | Tarifa ($/MiB) | Costo ($) | |
---|---|---|---|
150 | 0.00 | $0.00 | |
267 | 0.258 | $69.14 | |
Total | 417 | $69.14 |
Situación 4: Tienes 1 recurso que escribe 500,000 métricas. Estas son métricas cobrables que se escriben cada una a una velocidad de 1 dato por minuto.
- Transferencia mensual: 167,084 MiB: 0.33416748 MiB para una métrica × 500,000
- Costo aproximado por mes: $35,890.98
MiB transferidos | Tarifa ($/MiB) | Costo ($) | |
---|---|---|---|
150 | 0.00 | $0.00 | |
99,850 | 0.258 | $25,761.30 | |
67,084 | 0.151 | $10,129.68 | |
Total | 167,084 | $35,890.98 |
Precios para la capacidad de control y previsibilidad
El precio del servicio administrado para Prometheus se diseñó para controlables. Debido a que se te cobra por muestra, puedes usar los siguientes impulsores para controlar los costos:
Período de muestreo: cambiar el período de recopilación de métricas de 15 segundos a 60 segundos puede implicar un ahorro de costos del 75%, sin sacrificar la cardinalidad. Puedes configurar períodos de muestreo por trabajo, por objetivo o global.
Filtrado: puedes usar el filtrado para reducir el número de muestras enviadas a al almacén de datos lobal del servicio; para obtener más información, consulta Filtra las métricas exportadas. Usa la configuración de reetiquetado de métricas en tu Configuración de recopilación de Prometheus para descartar métricas en el momento de la transferencia, según en los comparadores de etiquetas.
Mantén los datos de baja cardinalidad y bajo valor locales. Puedes ejecutar pruebas estándar de Prometheus junto con el servicio administrado, con los mismos parámetros de configuración de scape de forma local y que no vale la pena enviarlo al almacén de datos global del servicio.
El precio del servicio administrado para Prometheus se diseñó para predecibles.
No se te penaliza por tener histogramas escasos. Las muestras se cuentan solo para el primer valor distinto de cero y, luego, cuando el valor de bucket n es mayor que el valor de bucket n-1. Por ejemplo, un histograma con valores
10 10 13 14 14 14
cuenta como tres muestras para el primer, tercer y cuarto bucket.Según la cantidad de histogramas que uses y para qué los uses, la exclusión de depósitos sin cambios de los precios, por lo general, podría hacer que se cuenta entre un 20% y un 40% menos de muestras para fines de facturación que el valor absoluto de la cantidad de histogramas que indicarían.
Cuando cobras por cada muestra, no te penalizan por los contenedores rápidos, sin escala, interrumpibles o efímeros, como los que crea el HPA o Autopilot de GKE.
Si Managed Service para Prometheus se cobra por métrica, pagarías por la cardinalidad de un mes completo, una vez, cada vez que se iniciaba un nuevo contenedor. Con los precios por muestra, pagas solo mientras se ejecuta el contenedor.
Búsquedas, incluidas las consultas de alertas
Todas las consultas emitidas por el usuario, incluidas las consultas emitidas cuando Prometheus las reglas de registro, se cobran mediante llamadas a la API de Cloud Monitoring. Para conocer la tasa actual, consulta la tabla de resumen de Precios del servicio administrado para Prometheus o Supervisa los precios.
Ejemplos de precios basados en muestras transferidas
Los siguientes ejemplos muestran cómo calcular los costos de la recopilación de métricas cobradas por muestras transferidas. Basada en muestras la carga se usa para Google Cloud Managed Service para Prometheus.
El objetivo de estos ejemplos es ilustrar técnicas de cálculo, no para proporcionar datos de facturación.
El escenario básico es el siguiente: hay varios contenedores o pods que escriben puntos en un número determinado de series temporales cada mes. Los datos pueden consistir en valores escalares o distribuciones.
Las variables entre los escenarios incluyen:
- La cantidad de contenedores o Pods.
- El número de series temporales.
- Indica si los datos consisten en valores escalares, distribuciones o ambos.
- La velocidad a la que se escriben estos datos.
Contar muestras
Antes de calcular los precios, debes saber cómo contar las muestras. La cantidad de muestras que se cuentan para un valor depende de los siguientes factores:
- Si el valor es un escalar o una distribución
- La velocidad a la que se escriben los valores
En esta sección, se describe cómo estimar el número de muestras escritas para una serie temporal durante el período de facturación mensual.
En un mes, hay aproximadamente 730 horas (365 días / 12 meses 24 horas), 43,800 minutos o 2,628,000 segundos.
Si una serie temporal escribe valores escalares, cada valor cuenta como una muestra. La cantidad de muestras escritas en un mes depende de la frecuencia se escriben los valores. Considera los siguientes ejemplos:
- Para los valores escritos cada 15 segundos:
- Tasa de escritura: 1 valor/15 s = 1 muestra/15 s
- Muestras por mes: 175,200 (1 muestra/15 s * 2,628,000 segundos/mes)
- Para los valores escritos cada 60 segundos:
- Tasa de escritura: 1 valor/60 s = 1 muestra/60 s
- Muestras por mes: 43,800 (1 muestra/60 s * 2,628,000 segundos/mes)
Si una serie temporal escribe valores de distribución, entonces cada valor puede contener Más de 2 + n muestras, en las que n es la cantidad de buckets en al histograma. La cantidad de muestras escritas en un mes depende del la cantidad de buckets de tus histogramas y la frecuencia con la que estén escritas.
Por ejemplo, cada instancia de un histograma de 50 bucket puede contener 52 muestras. Si los valores se escriben una vez cada 60 segundos, entonces, escribe, como máximo, 2,277,600 muestras por mes. Si el histograma tiene 100 buckets y se escribe una vez cada 60 segundos; luego, cada El histograma puede contener 102 muestras y escrituras como máximo. 4,467,600 muestras por mes
La mayoría de las series temporales de distribución contienen menos que el número máximo de de muestra. En la práctica, entre el 20% y el 40% de los buckets de histogramas están vacíos. Este porcentaje es aún mayor para los usuarios con histogramas dispersos, como las que genera Istio.
Cuando se cuentan muestras para el precio, solo se almacenan los buckets con valores no vacíos incluidos. La cantidad máxima de muestras por histograma es de 2 + n . Si el 25% de tus buckets están vacíos, la cantidad esperada de muestras es Más de 2 + 0.75n por histograma Si el 40% de tus buckets están vacíos, entonces la cantidad esperada de muestras es Más de 2 + 0.60n por histograma
Los siguientes cálculos y la tabla de resumen muestran el número máximo de y la cantidad esperada de muestras más realistas:
Para valores de histogramas de 50 bucket escritos cada 15 segundos:
- Tasa de escritura: 1 valor/15 s
- Cantidad máxima de muestras:
- Por histograma: 52
- Por mes: 9,110,400 (52 * 1 valor/15 s * 2,628,000 segundos/mes)
- Muestras esperadas, suponiendo un 25% vacío:
- Por histograma: 39.5 (2 + 0 .75(50) o 2 + (50 - 12.5))
- Por mes: 6,920,400 (39.5 * 1 valor/15 s * 2,628,000 segundos/mes)
- Muestras esperadas, suponiendo un 40% vacío:
- Por histograma: 32 (2 + 0 .6(50) o 2 + (50 - 20))
- Por mes: 5,606,400 (32 * 1 valor/15 s * 2,628,000 segundos al mes)
Para valores de histogramas de 50 depósitos escritos cada 60 segundos:
- Tasa de escritura: 1 valor/60 s
- Cantidad máxima de muestras:
- Por histograma: 52
- Por mes: 2,277,600 (52 * 1 valor/60 s * 2,628,000 segundos/mes)
- Muestras esperadas, suponiendo un 25% vacío:
- Por histograma: 39.5 (2 + 0 .75(50) o 2 + (50 - 12.5))
- Por mes: 1,730,100 (39.5 × 1 valor/60 s × 2,628,000 segundos por mes)
- Muestras esperadas, suponiendo un 40% vacío:
- Por histograma: 32 (2 + 0 .6(50) o 2 + (50 - 20))
- Por mes: 1,401,600 (32 * 1 valor/60 s * 2,628,000 segundos/mes)
Para valores de histogramas de 100 bucket escritos cada 15 segundos:
- Tasa de escritura: 1 valor/15 s
- Cantidad máxima de muestras:
- Por histograma: 102
- Por mes: 17,870,400 (102 * 1 valor/15 s * 2,628,000 segundos al mes)
- Muestras esperadas, suponiendo un 25% vacío:
- Por histograma: 77 (2 + 0 .75(100) o 2 + (100 - 25))
- Por mes: 13,490,400 (77 × 1 valor/15 s × 2,628,000 segundos al mes)
- Muestras esperadas, suponiendo un 40% vacío:
- Por histograma: 62 (2 + 0 .6(100) o 2 + (100 - 40))
- Por mes: 10,862,400 (62 * 1 valor/15 s * 2,628,000 segundos al mes)
Para valores de histogramas de 100 bucket escritos cada 60 segundos:
- Tasa de escritura: 1 valor/60 s
- Cantidad máxima de muestras:
- Por histograma: 102
- Por mes: 4,467,600 (102 * 1 valor/60 s * 2,628,000 segundos al mes)
- Muestras esperadas, suponiendo un 25% vacío:
- Por histograma: 77 (2 + 0 .75(100) o 2 + (100 - 25))
- Por mes: 3,372,600 (77 * 1 valor/60 s * 2,628,000 segundos/mes)
- Muestras esperadas, suponiendo un 40% vacío:
- Por histograma: 62 (2 + 0 .6(100) o 2 + (100 - 40))
- Por mes: 2,715,600 (62 * 1 valor/60 s * 2,628,000 segundos/mes)
En la siguiente tabla, se resume la información mencionada antes:
Recuento de buckets | Tasa de escritura | Muestras por mes (máx.) |
Muestras por mes (25% vacío) |
Muestras por mes (40% vacío) |
---|---|---|---|---|
50 | 1 muestra/15s | 9,110,400 | 6,920,400 | 5,606,400 |
50 | 1 muestra/60s | 2,277,600 | 1,730,100 | 1,401,600 |
100 | 1 muestra/15s | 17,870,400 | 13,490,400 | 10,862,400 |
100 | 1 muestra/60s | 4,467,600 | 3,372,600 | 2,715,600 |
Ejemplos
Para estimar los precios, cuenta la cantidad de muestras escritas en un mes y aplica los valores de precios. Las muestras se cobran por millón para rangos apilados de la siguiente manera:
Rango de transferencia | Servicio administrado para Prometheus | Máximo para el rango |
---|---|---|
Hasta 50,000 millones | $0.06 por millón | USD 3,000.00 |
De 50,000 millones a 250,000 millones | $0.048 por millón | USD 9,600.00 |
De 250,000 a 500,000 millones (500,000 millones) | $0.036 por millón | USD 9,000.00 |
Más de 500,000 millones (500,000 millones) | $0.024 por millón |
En el resto de esta sección, se describen posibles situaciones.
Situación 1: Tienes 100 contenedores y cada uno escribe 1,000 series escalares escalares.
Variante A: Si cada serie temporal se escribe cada 15 segundos (1 muestra/15), la cantidad de muestras escritas por mes es 17,520,000,000 (175,200 muestras por mes). * 1,000 series temporales * 100 contenedores) o 17,520 millones.
Variante B: Si cada serie temporal se escribe cada 60 segundos (1 muestra/60), la cantidad de muestras escritas por mes es 4,380,000,000 (43,800 muestras por mes) * 1,000 series temporales * 100 contenedores) o 4,380 millones.
En ambos casos, hay menos de 50,000 millones muestras, por lo que solo se aplica la primera tarifa. No se cobran muestras en el otras tarifas.
Variante | Muestras transferidas | Rango de transferencia | Servicio administrado para Prometheus ($0.06, $0.048, $0.036, $0.024) |
---|---|---|---|
A (1 muestra/15 s) Total |
17,520 millones 17,520 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 1,051.20 USD 1,051.20 |
B (1 muestra/60 s) Total |
4,380 millones 4,380 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 262.80 USD 262.80 |
Situación 2: Tienes 1,000 contenedores y cada uno escribe 1,000 series temporales de escalares.
Variante A: Si cada serie temporal se escribe cada 15 segundos (1 muestra/15), la cantidad de muestras escritas por mes es 175,200,000,000 o 175,200 millones:
- Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
- Los 125,200 millones restantes de muestras se cobran con la segunda tarifa.
- No se cobran muestras con las demás tarifas.
Variante B: Si cada serie temporal se escribe cada 60 segundos (1 muestra/60), la cantidad de muestras escritas por mes es 43,800,000,000, o 43,800 millones. Este valor mensual es inferior a 50,000 millones de muestras, por lo que solo se aplica la primera tarifa.
Variante | Muestras transferidas | Rango de transferencia | Servicio administrado para Prometheus ($0.06, $0.048, $0.036, $0.024) |
---|---|---|---|
A (1 muestra/15 s) Total |
50,000 millones 125,200 millones 175,200 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 3,000.00 USD 6,009.60 USD 9,009.60 |
B (1 muestra/60 s) Total |
43,800 millones 43,800 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 2,628.00 USD 2,628.00 |
Situación 3: Tienes 100 contenedores y cada uno escribe 1,000 series temporales de distribución de 100 buckets. Esperas que el 25% de los depósitos esté vacío.
Variante A: Si cada serie temporal se escribe cada 15 segundos (1 muestra/15), la cantidad de muestras escritas por mes es 1,349,040,000,000 (13,490,400 muestras por mes). * 1,000 series temporales * 100 contenedores) o 1,349,040 millones.
- Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
- Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
- Los siguientes 250,000 millones de muestras se cobran con la tercera tarifa.
- Los 749,040 millones de muestras restantes se cobran con la cuarta tarifa.
Variante B: Si cada serie temporal se escribe cada 60 segundos (1 muestra/60), la cantidad de muestras escritas por mes es 337,260,000,000 (3,372,600 muestras por mes) * 1,000 series temporales * 100 contenedores) o 337,260 millones.
- Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
- Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
- Los 87,260 millones restantes de muestras se cobran en función de la tercera tarifa.
Variante | Muestras transferidas | Rango de transferencia | Servicio administrado para Prometheus ($0.06, $0.048, $0.036, $0.024) |
---|---|---|---|
A (1 muestra/15 s) Total |
50,000 millones 200,000 millones 250,000 millones 749,040 millones 1,349,040 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 3,000.00 USD 9,600.00 USD 9,000.00 USD 17,976.96 USD 39,576.96 |
B (1 muestra/60 s) Total |
50,000 millones 200,000 millones 87,260 millones 337,260 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 3,000.00 USD 9,600.00 USD 3,141.36 USD 15,741.36 |
Situación 4: Tienes 1,000 contenedores y cada uno escribe 10,000 series temporales de distribución de 100 buckets. Esperas que el 40% de los depósitos esté vacío.
Variante A: Si cada serie temporal se escribe cada 15 segundos (1 muestra/15), la cantidad de muestras escritas por mes es 108,624,000,000,000 (10,862,400 muestras por mes). * 10,000 series temporales * 1,000 contenedores o 108,624,000 millones.
- Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
- Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
- Los siguientes 250,000 millones de muestras se cobran con la tercera tarifa.
- Los 108,124,000 millones de muestras restantes se cobran con la cuarta tarifa.
Variante B: Si cada serie temporal se escribe cada 60 segundos (1 muestra/60), la cantidad de muestras escritas por mes es 27,156,000,000,000 (2,715,600 muestras por mes). * 10,000 series temporales * 1,000 contenedores, o 27,156,000 millones.
- Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
- Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
- Los siguientes 250,000 millones de muestras se cobran con la tercera tarifa.
- Los 26,656,000 millones de muestras restantes se cobran con la cuarta tarifa.
Variante | Muestras transferidas | Rango de transferencia | Servicio administrado para Prometheus ($0.06, $0.048, $0.036, $0.024) |
---|---|---|---|
A (1 muestra/15 s) Total |
50,000 millones 200,000 millones 250,000 millones 108,124,000 millones 108,624,000 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 3,000.00 USD 9,600.00 USD 9,000.00 USD 2,594,976.00 USD 2,616,576.00 |
B (1 muestra/60 s) Total |
50,000 millones 200,000 millones 250,000 millones 26,656,000 millones 27,156,000 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 3,000.00 USD 9,600.00 USD 9,000.00 USD 639,744.00 USD 661,344.00 |
Situación 5: Tienes lo siguiente:
1,000 contenedores, cada uno escribe 1,000 series de veces escalares cada 15 segundos La cantidad de muestras escritas por mes es de 175,200,000,000. 175,200 millones. (Situación 2, variante A).
1,000 contenedores, cada uno con 10,000 series temporales de distribución de 100 bucket cada 15 segundos. Esperas que el 40% de los depósitos esté vacío. La cantidad de muestras escritas por mes es 108,624,000,000,000 o 108,624,000 millones. (Situación 4, variante A).
La cantidad total de muestras por mes es de 108,799,200 millones (175,200 millones + 108,624,000 millones).
- Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
- Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
- Los siguientes 250,000 millones de muestras se cobran con la tercera tarifa.
- Los 108,299,200 millones de muestras restantes se cobran con la cuarta tarifa.
Variante | Muestras transferidas | Rango de transferencia | Servicio administrado para Prometheus ($0.06, $0.048, $0.036, $0.024) |
---|---|---|---|
2A + 4A Total |
50,000 millones 200,000 millones 250,000 millones 108,299,200 millones 108,799,200 millones |
Hasta 50,000 millones Hasta 250,000 millones Hasta 500,000 millones Más de 500,000 millones |
USD 3,000.00 USD 9,600.00 USD 9,000.00 USD 2,599,180.80 USD 2,620,780.80 |
Precio de la ejecución de la verificación de tiempo de actividad (fecha de entrada en vigencia: 1 de octubre de 2022)
Cargos de supervisión para cada ejecución regional de un tiempo de actividad después de la asignación mensual gratuita de 1 millón de ejecuciones. Una verificación que se ejecuta en tres regiones cuenta como tres ejecuciones.
El costo de la ejecución de la verificación de tiempo de actividad es de $0.30 por cada 1,000 ejecuciones. El cargo aparece en tu factura como el SKU “CA14-D3DE-E67F”. para “Supervisión de verificaciones de tiempo de actividad”.
Los siguientes ejemplos muestran cómo calcular los costos de y ejecución de verificaciones de tiempo de actividad. Con estos ejemplos se pretende ilustrar con técnicas de cálculo, no para brindar datos de facturación.
Contar las ejecuciones de verificaciones de tiempo de actividad
Para estimar el costo de tus verificaciones de tiempo de actividad, debes saber cuántas las ejecuciones regionales tienen lugar en un mes. Cargos de Monitoring $0.30 por cada 1,000 ejecuciones, con una asignación mensual gratuita de 1 millón de ejecuciones.
Para estimar el costo de tus verificaciones de tiempo de actividad, puedes usar los siguientes comandos: cálculo:
(EXECUTIONS_PER_MONTH - 1,000,000) * .0003
Para cada verificación de tiempo de actividad, la cantidad de ejecuciones depende de lo siguiente opciones de configuración:
La frecuencia con la que se ejecuta la verificación de tiempo de actividad: cada minuto, 5 minutos, 10 minutos o 15 minutos.
La cantidad de regiones en las que se ejecuta la verificación de tiempo de actividad.
La cantidad de objetivos para los que está configurada la verificación de tiempo de actividad. Si el tiempo de actividad de destino está configurada para una sola VM, entonces el número de destinos es 1. Si la verificación de tiempo de actividad está configurada para un grupo de recursos, la cantidad de objetivos es la cantidad de recursos en el grupo.
Cuando configuras una verificación de tiempo de actividad, especificas una ubicación para el la verificación de tiempo de actividad, y cada ubicación se asigna a una o más regiones. El en la siguiente tabla, se muestran las ubicaciones válidas de las verificaciones de tiempo de actividad y las regiones a la que se asignan:
Ubicación para la configuración de la verificación de tiempo de actividad | Incluye regiones de Google Cloud |
---|---|
ASIA_PACIFIC |
asia-southeast1 |
EUROPE |
europe-west1 |
SOUTH_AMERICA |
southamerica-east1 |
USA |
us-central1 , us-east4 , us-west1
|
GLOBAL |
Todas las regiones incluidas por otras ubicaciones |
Debes configurar tus verificaciones de tiempo de actividad para que se ejecuten en al menos tres regiones.
Para estimar la cantidad de ejecuciones de una verificación de tiempo de actividad, debes saber ¿Cuántas regiones está cubiertas por la ubicación de la verificación de tiempo de actividad?
ASIA_PACIFIC
,EUROPE
ySOUTH_AMERICA
incluyen 1 región cada uno.USA
incluye 3 regiones.GLOBAL
incluye 6 regiones.
En un mes, hay aproximadamente 730 horas (365 días / 12 meses * 24 horas) o 43,800 minutos.
Se ejecuta una verificación de tiempo de actividad configurada para ejecutarse una vez por minuto en
USA
. en 3 regiones. Si esta verificación de tiempo de actividad está configurada para comprobar un único esta verificación de tiempo de actividad ejecuta 131,400 (3 × 43,800) veces en un mes. Si la verificación está configurada para verificar un grupo de recursos de 10 miembros, se ejecuta la verificación de tiempo de actividad 1,314,000 (10 * 131,400) de veces en un mesUna verificación de tiempo de actividad configurada para ejecutarse una vez por minuto en
ASIA_PACIFIC
.EUROPE
yUSA
se ejecutan en 5 regiones. Esta verificación de tiempo de actividad se ejecuta 219,000 veces en un mes si para un solo destino.
En la siguiente tabla, se muestran los recuentos de ejecución por hora y por mes de una sola una verificación de tiempo de actividad configurada para ejecutarse con distintas frecuencias en diferentes Cantidad de regiones:
Frecuencia de ejecución de la verificación, una vez cada: |
Cantidad de regiones |
Ejecuciones por hora por objetivo |
Ejecuciones mensuales por objetivo |
---|---|---|---|
1 minuto | 3 4 5 (6) |
180 240 300 360° |
131,400 175,200 219,000 262 800 |
5 minutos | 3 4 5 (6) |
36 48 60 (72) |
26,280 35,040 43,000 52 660 |
10 minutos | 3 4 5 (6) |
18 24 30 (36) |
13,140 17,520 21,900 26 280 |
15 minutos | 3 4 5 (6) |
12 16 20 (24) |
8,760 11,680 14,600 17 520 |
Ejemplos
Para estimar los precios, determina el total de ejecuciones mensuales y resta 1,000,000. Cualquier ejecución restante se cobra a $0.30 por cada 1,000 ejecuciones, por lo tanto, multiplicar las ejecuciones restantes por 0 .0003.
(EXECUTIONS_PER_MONTH - 1,000,000) * .0003
Situación 1: Tienes 1 verificación de tiempo de actividad en la ubicación USA
que verifica 1 VM una vez por minuto. Esta verificación se ejecuta en 3 regiones.
La verificación se ejecuta 131,400 veces al mes y no cuesta nada.
Total de ejecuciones mensuales |
Ejecuciones mensuales cobrables (más de 1,000,000) |
Costo ($0.30 por cada 1,000 ejecuciones) |
---|---|---|
131 400 | 0 | $0.00 |
Situación 2: Tienes 1 verificación de tiempo de actividad en la ubicación USA
que verifica un grupo de recursos de 10 miembros una vez por minuto. Esta verificación se ejecuta en 3
regiones. La verificación se ejecuta 10 × 131,400 veces al mes y
cuesta USD 94.20 por mes. La única diferencia entre esta situación y la situación 1
es la cantidad de objetivos.
Total de ejecuciones mensuales |
Ejecuciones mensuales cobrables (más de 1,000,000) |
Costo ($0.30 por cada 1,000 ejecuciones) |
---|---|---|
1,314,000 (10 objetivos) | 314 000 | USD 94.20 |
Situación 3: Tienes 10 verificaciones de tiempo de actividad GLOBAL
.
cada uno de los cuales verifica 1 VM una vez por minuto. Estas verificaciones se ejecutan en 6 regiones,
por lo que cada verificación
se ejecuta 262,800 veces al mes. El total mensual
ejecuciones es 2,628,000 (10 * 262,800). Esta situación cuesta
USD 488.40 por mes.
Total de ejecuciones mensuales |
Ejecuciones mensuales cobrables (más de 1,000,000) |
Costo ($0.30 por cada 1,000 ejecuciones) |
---|---|---|
2.628.000 | 1.628.000 | USD 488.40 |
Situación 4: Tienes 5 verificaciones de tiempo de actividad en la ubicación USA
que verifiquen 1 VM cada 5 minutos. Estas verificaciones se ejecutan en 3 regiones, por lo que cada
se ejecuta 26,280 veces al mes. El total de ejecuciones mensuales
para este conjunto de verificaciones es 105,120 (4 * 26,280).
También tienes 2 verificaciones de tiempo de actividad GLOBAL
que verifican 1 VM una vez cada 15
minutos. Estas verificaciones se ejecutan en 6 regiones, por lo que cada verificación se ejecuta
17,520 veces al mes. El total de ejecuciones mensuales de este
conjunto de verificaciones es 35,040 (2 * 17,520).
Tus ejecuciones mensuales totales es de 140,160 (105,120 + 35,040). Esta situación no tiene ningún costo.
Total de ejecuciones mensuales |
Ejecuciones mensuales cobrables (más de 1,000,000) |
Costo ($0.30 por cada 1,000 ejecuciones) |
---|---|---|
140 160 | 0 | $0.00 |
Precios de la ejecución de supervisión sintética (fecha de entrada en vigencia: 1 de noviembre de 2023)
Cloud Monitoring cobra por cada ejecución de un monitor sintético, más allá de la asignación gratuita por mes de 100 ejecuciones por cuenta de facturación. Por ejemplo, si creas 3 monitores sintéticos y configuras cada uno se ejecuten cada 5 minutos y, luego, la cantidad total de ejecuciones por mes es de 26,784:
Number of executions per month = 3 synthetic monitors * 1 execution per monitor per 5 minutes *
1440 minutes per day * 31 days per month
= 26,784
Para determinar la cantidad de ejecuciones cobrables, resta la asignación gratuita del número total de ejecuciones y multiplicar el resultado por Costo:
Total de ejecuciones mensuales |
Ejecuciones mensuales cobrables (más de 100 ejecuciones por cuenta de facturación) |
Costo (USD 1.20 por 1,000 ejecuciones) |
---|---|---|
26 784 | 26 684 | USD 32.02 |
Precios de las alertas
A partir del 7 de enero de 2025, Cloud Monitoring comenzarán a cobrarse las alertas El modelo de precios es el siguiente:
- $1.50 por mes para cada condición en una política de alertas.
- $0.35 por 1,000,000 series temporales mostradas por la consulta de una condición de política de alertas de métricas.
En esta sección, se proporciona la siguiente información:
- Definiciones de la terminología de alertas.
- Ejemplos de cargos por diversas alertas parámetros de configuración de políticas.
- Sugerencias para reducir costos en con el objetivo de consolidar o borrar políticas de alertas.
- Información sobre cómo inhabilitar la facturación para las políticas de alertas.
Definiciones
Condición: La condición de un Una política de alertas describe cuándo un recurso o un grupo de recursos está en un estado que requiere respuesta.
- Políticas de alertas que usan filtros para crear metric-threshold o Las consultas de ausencia de métricas se pueden combinar hasta seis condiciones.
- Las políticas de alertas con los siguientes tipos de consultas solo pueden tener un condición única:
El cargo corresponde a USD 1.50 por mes por cada condición. Para que no se te cobre por una condición, debes borrar la política de alertas. Posponer o inhabilitar la política no evitar que se te cobre.
Políticas de alertas de métricas y basadas en registros: Políticas de alertas que usan cualquier tipo de condición, excepto las condiciones de coincidencia de registro, son alertas de métrica políticas, las condiciones de las políticas de alertas de métricas devuelven series temporales. Durante cada período de ejecución, se ejecutan las condiciones en las políticas de alertas de métricas sus consultas en el almacén de datos de Cloud Monitoring. El valor devuelto de las series temporales luego se evalúan en función de un umbral para determinar se activa la política de alertas.
Las políticas de alertas basadas en registros usan condiciones de coincidencia de registro. Condiciones de coincidencia de registros No muestra series temporales.
Período de ejecución: Es la frecuencia con la que Cloud Monitoring ejecuta tu estado. Para la mayoría de los tipos de condiciones, estos son 30 segundos y no se pueden cambió. Las condiciones que usan una consulta de PromQL pueden establecer este período. Para obtener más información, consulta Cómo aumentar la duración del período de ejecución (solo PromQL).
Series temporales mostradas: Durante cada período de ejecución, se genera una alerta de métrica ejecuta la consulta de su condición en el servicio de Cloud Monitoring en un almacén de datos. Cloud Monitoring devuelve datos de series temporales como respuesta a cada consulta. Cada serie temporal en la respuesta cuenta como una serie temporal que se devuelven.
Tres factores determinan la cantidad de series temporales que se muestran en un mes:
- La forma y el alcance de los datos subyacentes.
- Los filtros y las agregaciones que usas en la consulta de tu condición.
- El período de ejecución.
Por ejemplo, considera una configuración en la que tienes lo siguiente:
- 100 máquinas virtuales (VMs), en las que cada VM pertenece a un servicio
- Cada VM emite una métrica,
metric_name
, que tiene una etiqueta con 10 valores. - Cinco servicios en total.
Dado que tienes 100 VMs, cada una puede generar 10 series temporales (una para cada valor de etiqueta), tienes un total de 1,000 series temporales subyacentes. Cada VM también contiene una etiqueta similar a metadatos que registra a cuál de los cinco servicios pertenece la VM.
Puedes configurar tus políticas de alertas de las siguientes maneras usando PromQL, en el que cada configuración da como resultado una cantidad diferente de series temporales que se muestran por período de ejecución:
Configuración Consulta de PromQL Series temporales que se muestran por período Sin agregación rate(
metric_name
[1m])1,000 Agregación a la VM sum by (vm) (rate(
metric_name
[1m]))100 Agregar al valor de la etiqueta sum by (label_key) (rate(
metric_name
[1m]))10 Agregación al servicio sum by (service) (rate(
metric_name
[1m]))5 Agregar al valor y servicio de la etiqueta sum by (service, label_key) (rate(
metric_name
[1m])50 Agregar a la flota sum (rate(
metric_name
[1m]))1 Filtra y agrega a una VM sum (rate(
metric_name
{vm="my_vm_name"}[1m]))1 Filtrar y agregar a un servicio sum (rate(
metric_name
{service="my_service_name"}[1m]))1
Ejemplos de precios
Los siguientes ejemplos ocurren en un mes de 30 días, lo que da como resultado lo siguiente: períodos de evaluación:
- 86,400 períodos de ejecución de 30 segundos por mes
- 172,800 períodos de ejecución de 15 segundos por mes (solo consultas de PromQL)
Ejemplo 1: Una política, agregación a la VM, 30 segundos
En este ejemplo, usa los siguientes parámetros de configuración:
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name
metric_name
tiene una etiqueta, que tiene 10 valores
- Una condición de alerta
- La condición se agrega al nivel de la VM
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición × $1.50 por mes = USD 1.50 por mes
- Costo de la serie temporal: 100 series temporales mostradas por período * 86,400 períodos por mes = 8.6 millones de series temporales mostradas por mes * $0.35 por millón de series temporales = $3.02 por mes
- Costo total: USD 4.52 por mes
Ejemplo 2: 100 políticas (una por VM), agregadas a la VM, 30 segundos
En este ejemplo, usa los siguientes parámetros de configuración:
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name
metric_name
tiene una etiqueta, que tiene 10 valores
- 100 condiciones
- Cada condición se filtra y se agrega a una VM
- Período de ejecución de 30 segundos
- Costo de la condición: 100 condiciones × $1.50 por mes = $150 por mes
- Costo de la serie temporal: 100 condiciones * 1 serie temporal mostrada por condición por período * 86,400 períodos por mes = 8.6 millones de series temporales mostradas por mes * $0.35 por millón de series temporales = $3.02 por mes
- Costo total: USD 153.02 por mes
Ejemplo 3: Una política, que se agrega a la VM, 15 segundos
En este ejemplo, usa los siguientes parámetros de configuración:
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name
metric_name
tiene una etiqueta, que tiene 10 valores
- Una condición de alerta de PromQL
- La condición se agrega al nivel de la VM
- Período de ejecución de 15 segundos
- Costo de la condición: 1 condición × $1.50 por mes = USD 1.50 por mes
- Costo de la serie temporal: 100 series temporales mostradas por período * 172,800 períodos por mes = 17.3 millones de series temporales mostradas por mes * $0.35 por millón de series temporales = USD 6.05 por mes
- Costo total: USD 7.55 por mes
Ejemplo 4: Agrega una política a cada servicio, 30 segundos
En este ejemplo, usa los siguientes parámetros de configuración:
Datos
- 100 VMs (cada VM pertenece a un servicio)
- Cinco servicios en total
- Cada VM emite una métrica,
metric_name
metric_name
tiene una etiqueta, que tiene 10 valores
- Una condición
- La condición se agrega al nivel de servicio
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición × $1.50 por mes = USD 1.50 por mes
- Costo de la serie temporal: 5 series temporales mostradas por período * 86,400 períodos por mes = 432,000 series temporales mostradas por mes * $0.35 por millón de series temporales = $0.14 por mes
- Costo total: USD 1.64 por mes
Ejemplo 5: Agrega una política a la VM cardinalidad subyacente más alta por VM, 30 segundos
En este ejemplo, usa los siguientes parámetros de configuración:
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name
metric_name
tiene 100 etiquetas con 1,000 valores cada una
- Una condición
- La condición se agrega al nivel de la VM
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición × $1.50 por mes = USD 1.50 por mes
- Costo de la serie temporal: 100 series temporales mostradas por período * 86,400 períodos por mes = 8.5 millones de series temporales mostradas por mes * $0.35 por millón de series temporales = $3.02 por mes
- Costo total: USD 4.52 por mes
Ejemplo 6: Agrega una política a la VM. unir dos métricas en una condición, 30 segundos
En este ejemplo, usa los siguientes parámetros de configuración:
Datos
- 100 VM
- Cada VM emite dos métricas,
metric_name_1
ymetric_name_2
. - Ambas métricas tienen una etiqueta con 10 valores cada una
- Una condición
- La condición se agrega al nivel de la VM
- La condición usa un operador
OR
para unir las métricas - Período de ejecución de 30 segundos
- Costo de la condición: 1 condición × $1.50 por mes = USD 1.50 por mes
- Costo de la serie temporal: 2 métricas × 100 series temporales mostradas por métrica por período* 86,400 períodos por mes = 17.3 millones de series temporales mostradas por mes * $0.35 por millón de series temporales = USD 6.05 por mes
- Costo total: USD 7.55 por mes
Ejemplo 7: 100 políticas de alertas basadas en registros
En este ejemplo, usa la siguiente configuración:
Políticas de alertas
- 100 condiciones (una por cada política de alertas basada en registros)
- Costo de la condición: 100 condición × $1.50 por mes = USD 150.00 por mes
- Costo de la serie temporal: USD 0 (Las políticas de alertas basadas en registros no muestran series temporales).
- Costo total: USD 150.00 por mes
Sugerencias para reducir la factura de alertas
Cuando configures tus políticas de alertas basadas en métricas, usa lo siguiente: para reducir el costo de las alertas.Consolidar políticas de alertas para operar sobre más recursos
Debido al costo de 1,50 USD por condición, es más rentable usar una política de alertas para supervisar varios recursos que usar una política de alertas para supervisar cada recurso. Por ejemplo: compara el Ejemplo 1 con el Ejemplo 2: En ambos ejemplos, se supervisa la misma cantidad de recursos. Sin embargo, ejemplo 2 usa 100 políticas de alertas, mientras que el ejemplo 1 usa solo una. Como resultado, el ejemplo 1 es casi USD 150 más económico por mes.
Agrega solo el nivel sobre el que necesitas generar alertas.
La agregación en niveles de detalle más altos da como resultado costos más altos que la agregación a niveles más bajos de detalle. Por ejemplo: Agregar al nivel de proyecto de Google Cloud es más económico que agregar a nivel de clúster, y la agregación a nivel de clúster es más económica que agregar al nivel de clúster y espacio de nombres.
Por ejemplo, compara el Ejemplo 1 con el Ejemplo 4: Ambos ejemplos operan sobre los mismos datos subyacentes y tienen una sola alerta . Sin embargo, debido a que la política de alertas del ejemplo 4 se agrega es menos costosa que la política de alertas del ejemplo 1, que se agrega de forma más detallada a la VM.
Además, compara el ejemplo 1 con el ejemplo 5: En este caso, la cardinalidad de la métrica en el ejemplo 5 es 10,000 veces mayor que la cardinalidad de las métricas en el ejemplo 1. Sin embargo, debido a que la política de alertas en del ejemplo 1 y el ejemplo 5 se agregan a la VM y, debido a que la cantidad de VMs es la misma en ambos ejemplos, estos son equivalentes en precio.
Cuando configures tus políticas de alertas, funcionen mejor para tu caso de uso. Por ejemplo, si quieres generar alertas en la CPU por lo que recomendamos agregar la VM y el nivel de CPU. Si le interesarán las alertas de latencia por extremo, al nivel del extremo.
No generar alertas sobre datos sin procesar ni agregados
Monitoring usa un sistema de métricas dimensional, en el que cualquier métrica tiene una cardinalidad total igual a la cantidad de recursos supervisados multiplicado por la cantidad de combinaciones de etiquetas en esa métrica. Para ejemplo, si tienes 100 VMs que emiten una métrica y esa métrica tiene 10 etiquetas con 10 valores cada una, entonces tu cardinalidad total es 100 * 10 * 10 = 10,000
Como resultado de cómo escala la cardinalidad, alertar sobre datos sin procesar puede ser costoso. En el ejemplo anterior, se muestran 10,000 series temporales para cada período de ejecución. Sin embargo, si agrega a la VM, Solo se muestran 100 series temporales por período de ejecución, independientemente de la etiqueta cardinalidad de los datos subyacentes.
Alertar sobre datos sin procesar también te pone en riesgo de mayores series temporales cuando tus métricas reciben etiquetas nuevas. En el ejemplo anterior, si un usuario agrega una nueva etiqueta a tu métrica, entonces aumenta tu cardinalidad total a 100 * 11 * 10 = 11,000 series temporales. En este caso, la cantidad de devoluciones series temporales aumenta en 1,000 cada período de ejecución, a pesar de que tus alertas la política no cambia. Si, en cambio, agregas a la VM, entonces, a pesar de una cardinalidad subyacente más alta, solo tienes que mostrar 100 series temporales.
Filtra las respuestas innecesarias
Configura tus condiciones para evaluar solo los datos necesarios para tu las necesidades de alerta. Si no tomarías medidas para corregir algo, excluye de tus políticas de alertas. Por ejemplo, es probable que no necesites alertar en la VM de desarrollo de un pasante.
Para reducir las alertas y los costos innecesarios, puedes filtrar las series temporales que no son importantes. Puedes usar etiquetas de metadatos de Google Cloud para etiquetar recursos con categorías y luego filtra las categorías de metadatos innecesarias.
Usa operadores de transmisión principal para reducir la cantidad de series temporales que se devuelven
Si tu condición usa una consulta de PromQL o MQL, puedes usar un operador de transmisiones top para seleccionar la cantidad de series temporales mostradas con los valores más altos:
Por ejemplo, una cláusula topk(metric, 5)
en una consulta de PromQL limita
la cantidad de series temporales que se muestran a cinco en cada período de ejecución.
Si se limita a un número superior de series temporales, es posible que falten datos alertas de fallas, como las siguientes:
- Si más de N series temporales incumplen tu umbral, no lo lograrás. fuera de la serie temporal N principal.
- Si una serie temporal con incumplimientos ocurre fuera de la serie temporal N principal, entonces es posible que tus incidentes se cierren automáticamente a pesar de que la serie temporal excluida que no sobrepasan el umbral.
- Es posible que tus consultas de condiciones no te muestren contexto importante, como el modelo de referencia. de series temporales que funcionan según lo previsto.
A fin de mitigar tales riesgos, elige valores grandes para N y usa los flujos superiores. solo en las políticas de alertas que evalúan muchas series temporales, como para contenedores individuales de Kubernetes.
Aumentar la duración del período de ejecución (solo PromQL)
Si tu condición usa una consulta de PromQL, puedes modificar la longitud.
de tu período de ejecución estableciendo los
campo evaluationInterval
en
condition.
Los intervalos de evaluación más largos dan como resultado menos series temporales mostradas por mes. Por ejemplo, una consulta de condición con un intervalo de 15 segundos se ejecuta con el doble de frecuencia como una consulta con un intervalo de 30 segundos y una consulta con un intervalo de 1 minuto se ejecuta con la mitad de frecuencia que una consulta en un intervalo de 30 segundos.
Rechazando
Si tienes un contrato existente de Google Cloud que no vence hasta El 7 de enero de 2025, puedes retrasar la facturación de las alertas hasta que se cumpla tu contrato debe renovarse mediante la solicitud de una exención del alertando al equipo de facturación. Las exenciones para los clientes con contratos activos serán se analiza según cada caso.
Puedes solicitar una exención hasta el 1 de noviembre de 2024. Para solicitar una exención de facturación hasta la renovación del contrato, completa la Formulario de solicitud de exención de facturación.
Error Reporting
Para obtener información de precios actuales, consulta Precios de Error Reporting.
Para ver los límites que se aplican al uso de Error Reporting, consulta Cuotas y límites.
Cloud Profiler
El uso de Cloud Profiler no tiene ningún costo asociado.
Para ver los límites que se aplican en el uso de Profiler, consulta Cuotas y límites.
Cloud Trace
Los cobros de Trace se calculan según la cantidad de intervalos de seguimiento transferidos y analizados. Cuando se envían a Trace los datos de latencia, se empaquetan como un seguimiento compuesto por intervalos, y estos se transfieren mediante el backend de Cloud Trace. Cuando visualizas datos de seguimiento, Cloud Trace analiza los intervalos almacenados. En esta sección, se proporciona la siguiente información:
- Se definen los intervalos de seguimiento cobrables y no cobrables.
- Se proporciona un ejemplo de precio.
- Se proporciona información sobre cómo reducir la transferencia de intervalos de seguimiento.
- Se proporciona una configuración para una política de alertas que puede notificarte si tu transferencia de intervalos de seguimiento alcanza un límite.
Para obtener información de los precios actuales, consulta Precios de Cloud Trace.
Para ver los límites que se aplican en el uso de Trace, consulta Cuotas y límites.
Para obtener información sobre cómo ver tu uso actual o anterior, consulta Estimación de tus facturas.
Intervalos de seguimiento no cobrables
Los precios de Cloud Trace no se aplican a los intervalos generados automáticamente por el entorno estándar de App Engine, Cloud Functions o Cloud Run. Es decir, no se cobra la transferencia de estos seguimientos.
Intervalos de seguimiento cobrables
Las transferencias de intervalos de seguimiento, excepto los intervalos que se enumeran en la sección titulada Intervalos de seguimiento no cobrables, son cobrables, y su precio se calcula según el volumen transferido. Esto incluye los intervalos creados por instrumentación que agregas a tu aplicación para el entorno estándar de App Engine.
Ejemplos de precios
Este es un ejemplo del precio de Trace a partir de julio de 2020.
- Si transfieres 2 millones de intervalos en un mes, el costo es $0. Los primeros 2.5 millones de intervalos que transfieres cada mes son gratuitos.
- Si transfieres 14 millones de intervalos en un mes, el costo es de $2.30. Los primeros 2.5 millones de intervalos de cada mes son gratuitos. El costo de los intervalos restantes se calcula como 11.5 millones de intervalos × $0.20 por millón de intervalos = $2.30.
- Si transfieres mil millones de intervalos en un mes, el costo es de $199. Los primeros 2.5 millones de intervalos de cada mes son gratuitos. El costo de los intervalos restantes se calcula como 997.5 millones de intervalos × $0.20 por millón de intervalos = $199.50.
Reduce el uso de seguimientos
Puedes administrar la tasa de muestreo de seguimiento para controlar el volumen de transferencia de intervalos de Trace y así equilibrar la cantidad de seguimientos que necesitas para el análisis de rendimiento con la tolerancia de costos.
Para los sistemas de tráfico alto, la mayoría de los clientes pueden muestrear 1 de cada 1,000 transacciones (o incluso 1 de cada 10,000) y, aún así, tener suficiente información para el análisis de rendimiento.
La tasa de muestreo se configura con las bibliotecas cliente de Cloud Trace.
Alerta de las transferencias de intervalos mensuales
Para crear una política de alertas que se active cuando Intervalos transferidos en Cloud Trace excede un límite definido por el usuario, utilice la siguiente configuración.
Nueva condición Campo |
Valor |
---|---|
Recurso y métrica | En el menú Recursos, selecciona Global. En el menú Categorías de métricas, selecciona Facturación. En el menú Métricas, selecciona Intervalos de seguimiento mensuales transferidos. |
Filtro | |
Series temporales Agregación de series temporales |
sum |
Ventana progresiva | 60 m |
Función analítica progresiva | max |
Configura el activador de alertas Campo |
Valor |
---|---|
Tipo de condición | Threshold |
Activador de alertas | Any time series violates |
Posición del umbral | Above threshold |
Threshold value |
Tú determinas el valor aceptable. |
Período para volver a probar | El valor mínimo aceptable es 30 minutos. |
GKE Enterprise
No se aplican cargos por los registros y las métricas del sistema de GKE Enterprise. Los registros del plano de control, las métricas del plano de control y una subconjunto seleccionado de métricas de estado de Kube habilitado de forma predeterminada para clústeres de GKE en Google Cloud que se registrados cuando se crea el clúster en un proyecto habilitado para GKE Enterprise. Los registros del plano de control generan cargos de Cloud Logging, mientras que las métricas activadas de forma predeterminada se incluyen sin cargo adicional.
Para ver la lista de registros y métricas de GKE incluidos, consulta Qué registros se recopilan y Métricas disponibles.
En un clúster de Google Distributed Cloud, los registros y las métricas del sistema de GKE Enterprise incluyen lo siguiente:
- Registros y métricas de todos los componentes en un clúster de administrador
- Registros y métricas de los componentes de estos espacios de nombres en un clúster de usuario:
kube-system
,gke-system
,gke-connect
,knative-serving
,istio-system
,monitoring-system
,config-management-system
,gatekeeper-system
,cnrm-system
Preguntas frecuentes
¿Qué funciones del producto se pueden usar de forma gratuita?
El uso de los productos de Google Cloud Observability se cobra por volumen de datos. Además del los costos por volumen de datos que se describen en esta página, el uso de todos los costos Las funciones del producto Google Cloud Observability son gratuitas.
¿Cuánto tendré que pagar?
Para calcular los costos de uso, consulta Calcula tus facturas.
Para obtener ayuda con las preguntas sobre facturación, consulta Preguntas sobre facturación.
¿Cómo entiendo los detalles del uso?
Con el Explorador de métricas, puedes conocer varias métricas que te permiten desglosar y entender el volumen de tus registros y recursos. Consulta Visualiza el uso detallado en el Explorador de métricas para obtener más información.
Si te interesa saber cómo administrar tus costos, consulta estos blogs publicaciones:
- Precios de Cloud Logging para administradores de Cloud: cómo abordarlo y ahorrar costos
- Cuatro pasos para administrar tus costos de Cloud Logging según un presupuesto
¿Cómo afectan los permisos de las métricas a la facturación?
En general, los permisos de métricas no afectan la facturación. Los registros y las métricas se cobran en el proyecto de Google Cloud que recibe los datos. El permiso de métricas de un proyecto define el conjunto de proyectos cuyas métricas puede ver y supervisar ese proyecto. Cuando defines un permiso de métrica, no afectas el proyecto que recibe los datos de la métrica ni haces que los datos se dupliquen.
Por ejemplo, supongamos que tu organización tiene 100 máquinas virtuales (VM): 60 VM están alojadas en el proyecto A y 40 VM están en el proyecto B. El Proyecto A recibe y almacena las métricas de sus VM, y se le cobra cuando las métricas son cobrables. De manera similar, Project-B recibe y almacena las métricas de sus VM, y se le cobra cuando las métricas son cobrables. Si creas un permiso de métricas que incluye el Proyecto A y el Proyecto B, puedes ver las métricas combinadas de tus 100 VM. Ahora puedes ver solo las métricas del Proyecto A, solo las del Proyecto B o las métricas combinadas de ambos. Aunque tienes dos formas de ver las métricas del Proyecto A, no hay cambios en la facturación.
Para supervisar cuentas de AWS, debes conectar un de AWS a Google Cloud a través de la creación de una Proyecto del conector de AWS. El proyecto de conector contiene los registros y los datos de supervisión para la cuenta de AWS.
¿Qué pasa si utilizo más asignaciones que las establecidas de forma gratuita?
Se te factura automáticamente por cualquier uso que supere las asignaciones gratuitas; no pierdes ningún registro o métrica. Para comprender mejor los costos potenciales, consulta Calcula tus facturas.
Puedes crear una política de alertas que supervise el uso y te avise cuando te acerques al límite de facturación.
Tengo una gran cantidad de registros de Google Cloud que no uso en mis proyectos. Me preocupan los costos de esos registros. ¿Cómo evito pagar por ellos?
Puedes excluir registros para controlar cuáles se transfieren a Logging. Consulta cómo reducir el uso de tus registros para obtener más información.
¿Los servicios que envían registros a mi proyecto recibirán un mensaje de error si se excluyen registros?
No. Los servicios que envían entradas de registro no pueden determinar si las entradas de registro se transfieren a Logging o no.
¿Me cobrarán dos veces por los registros de flujo de la nube privada virtual?
Si envías tus registros de flujo de VPC a Logging, se renuncia a los cargos de generación del registro de flujo de VPC y solo se aplican los cargos de Logging. Sin embargo, si los envías y luego excluyes tus registros de flujo de VPC de Logging, se aplican los cargos de los registros de flujo de VPC. Para obtener más información, consulta Calculadora de precios de Google Cloud y, luego, selecciona la pestaña "Cloud Load Balancing and Network Services".
1 Para determinar los precios, todas las unidades se tratan como medidas binarias, por ejemplo, como mebibytes (MiB, o 220 bytes) gibibytes (GiB o 230 bytes).
2 No se aplican cargos métricas de Google Cloud o de GKE Enterprise que se medido en hasta 1 dato por minuto, la resolución más alta en este momento. En el futuro, es posible que se cobre por las métricas medidas en resoluciones más altas.
3 En la actualidad, las métricas de procesos se recopilan a una velocidad predeterminada predefinida de 1 por minuto, lo que no se puede cambiar. Por lo general, estos datos cambian con lentitud, por lo que se realiza un sobremuestreo de estas métricas actualmente. Por lo tanto, el cobro de las métricas de procesos al 5% de la tarifa estándar se alinea con la tasa estándar si las métricas se muestrearon en intervalos de 20 minutos. A los usuarios que recopilan 100 MiB de datos de estas métricas solo se les cobra por 5 MiB.
¿Qué sigue?
- Lee la documentación de Google Cloud Observability.
- Prueba la calculadora de precios.
- Obtén más información sobre las soluciones y casos de uso de observabilidad de Google Cloud.