En esta página se describe cómo puedes optimizar y monitorizar tus costes de Google Cloud Observability. Para obtener información sobre los precios, consulta los precios de Google Cloud Observability.
También te pueden interesar los siguientes documentos:
- Calcula tus facturas.
- Ejemplos de precios
- Optimiza los costes con Explorador de costes. Cost Explorer ofrece visualizaciones actuales e históricas de los datos de costes y las métricas de utilización. Por lo tanto, los datos le ayudan a identificar oportunidades de optimización.
Optimizar
En esta sección se explica cómo reducir u optimizar los costes asociados a Cloud Logging, Cloud Trace y Google Cloud Managed Service para Prometheus.
Reducir los costes de Cloud Logging
Si quieres reducir los costes de almacenamiento de Cloud Logging, configura filtros de exclusión en los sumideros de registros para evitar que se transmitan entradas de registro de poco valor a los segmentos de registros. Puedes configurar un sumidero de registros para que excluya todas las entradas de registro que coincidan con un filtro de exclusión o para que excluya solo un porcentaje de las entradas de registro coincidentes. Las entradas de registro excluidas no se envían a tus cubos de registro y no se tienen en cuenta en tu asignación de almacenamiento. Para obtener más información, consulta Filtros de receptor de registro.
Los costes de almacenamiento de Cloud Logging solo se aplican a los datos de registro que se almacenan en segmentos de registros. Puedes configurar tus receptores de registros para que los datos de registro no se almacenen en segmentos de registros, sino que se dirijan a uno de los siguientes destinos:
Cloud Logging no cobra por enrutar entradas de registro a los destinos indicados. Sin embargo, es posible que se te cobre cuando un destino reciba entradas de registro.
Para obtener información sobre cómo enrutar datos de registro, consulta Enrutar registros a destinos admitidos.
Optimizar los costes de Managed Service para Prometheus
Los precios de Managed Service para Prometheus están diseñados para poder controlarse. Como se aplica una tarifa por muestra, puedes usar los siguientes métodos para controlar los costes:
Periodo de muestreo: cambiar el periodo de extracción de métricas de 15 segundos a 60 segundos puede suponer un ahorro de costes del 75 %, sin sacrificar la cardinalidad. Puedes configurar los periodos de muestreo por tarea, por objetivo o en todo el mundo.
Filtrado: puedes usar el filtrado para reducir el número de muestras enviadas al almacén de datos global del servicio. Para obtener más información, consulta Filtrar métricas exportadas. Usa configuraciones de reetiquetado de métricas en tu configuración de extracción de Prometheus para reducir las métricas en el momento de la ingestión, en función de las opciones de coincidencia de las etiquetas.
Mantén los datos locales de alta cardinalidad y bajo valor. Puedes ejecutar Prometheus estándar junto con el servicio gestionado usando las mismas configuraciones y mantener los datos que no vale la pena enviar al almacén de datos mundial del servicio localmente.
Los precios de Managed Service para Prometheus están diseñados para ser predecibles.
No se te penalizará por tener histogramas dispersos. Las muestras solo se cuentan para el primer valor distinto de cero y cuando el valor del segmento n sea mayor que el valor del segmento n‐1. Por ejemplo, un histograma con valores
10 10 13 14 14 14cuenta como tres muestras: en el primer, tercer y cuarto segmento.Según la cantidad de histogramas que uses y la forma en que los uses, la exclusión de segmentos sin cambios en los precios suele generar un 20 % o un 40 % menos de muestras con fines de facturación que la cantidad absoluta que indicarían los segmentos de histograma.
Si cobras por muestra, no se te aplicará ninguna penalización por los contenedores de escalado rápido, sin escalar, interrumpibles o efímeros, como los creados por HPA o Autopilot de GKE.
Si Managed Service for Prometheus se facturara según cada métrica, pagarías una cardinalidad de un mes completo cada vez que se añadiera un nuevo contenedor. Con los precios por muestra, pagas solo cuando el contenedor se está ejecutando.
Consultas, incluidas las consultas de alerta
Todas las consultas realizadas por el usuario, incluidas las que se hacen cuando se ejecutan reglas de grabación de Prometheus, se cobran a través de las llamadas a la API de Cloud Monitoring.
Reducir el uso de Trace
Si quieres controlar el volumen de ingestión de intervalos de Trace, ajusta la frecuencia de muestreo de trazas. De esta forma, puedes buscar el equilibrio entre el número de trazas necesarias para analizar el rendimiento y el coste asumible.
En los sistemas donde hay un gran volumen de tráfico, la mayoría de los clientes muestrean 1 de cada 1000 transacciones (o incluso 1 de cada 10.000) y, aun así, disponen de información suficiente para analizar el rendimiento.
La frecuencia de muestreo se configura con las bibliotecas de cliente de Cloud Trace.
Reducir la factura de las alertas
En esta sección se describen las estrategias que puede usar para reducir los costes de las alertas.
Consolidar políticas de alertas para que funcionen en más recursos
Las alertas se cobran por condición. Por este motivo, cuando sea posible, utilice una política de alertas para monitorizar varios recursos en lugar de crear una política de alertas para cada recurso.
Por ejemplo, supongamos que tienes 100 VMs. Cada VM genera una serie temporal
para el tipo de métrica my_metric. Aquí tienes dos formas de monitorizar la serie temporal:
Crea una política de alertas que tenga una condición. La monitorización de estado
my_metricagrega datos a nivel de VM. Después de la agregación, hay una serie temporal por cada máquina virtual. Por lo tanto, la condición monitoriza 100 series temporales.Crea 100 políticas de alertas y cada una contiene una condición. Cada condición monitoriza la
my_metricserie temporal de una de las VMs y agrega datos a nivel de VM. Por lo tanto, cada condición monitoriza una serie temporal.
La segunda opción, que crea 100 condiciones, es más cara que la primera, que solo crea 1 condición. Ambas opciones monitorizan 100 series temporales.
Agrega solo el nivel en el que necesites recibir alertas
Cada serie temporal monitorizada por una política de alertas tiene un coste. La agregación a niveles de granularidad más altos conlleva costes superiores a la agregación a niveles de granularidad más bajos. Por ejemplo, agregar datos a nivel de proyecto es más barato que hacerlo a nivel de clúster, y agregar datos a nivel de clúster es más barato que hacerlo a nivel de clúster y de espacio de nombres. Google Cloud
Por ejemplo, supongamos que tienes 100 VMs. Cada VM genera una serie temporal
para el tipo de métrica my_metric. Cada una de tus VMs pertenece a uno de los cinco servicios. Decides crear una política de alertas que tenga una condición que monitorice my_metric. Estas son dos opciones de agregación diferentes:
Agregas datos al servicio. Después de la agregación, hay una serie temporal por cada servicio. Por lo tanto, la condición monitoriza 5 series temporales.
Agrega datos a nivel de VM. Después de la agregación, hay una serie temporal por cada máquina virtual. Por lo tanto, la condición monitoriza 100 series temporales.
La segunda opción, que monitoriza 100 series temporales, es más cara que la primera, que solo monitoriza cinco series temporales.
Cuando configures tus políticas de alertas, elige los niveles de agregación que mejor se adapten a tu caso práctico. Por ejemplo, si te interesa recibir alertas sobre la utilización de la CPU, puedes agregar datos a nivel de máquina virtual y de CPU. Si te interesa recibir alertas sobre la latencia por servicio, puedes agregar datos a nivel de servicio.
No crees alertas a partir de datos sin procesar ni agregar
La monitorización usa un sistema de métricas dimensionales, en el que cualquier métrica tiene una cardinalidad total igual al número de recursos monitorizados multiplicado por el número de combinaciones de etiquetas de esa métrica. Por ejemplo, si tienes 100 máquinas virtuales que emiten una métrica y esa métrica tiene 10 etiquetas con 10 valores cada una, la cardinalidad total es 100 * 10 * 10 = 10.000.
Debido a la forma en que se escala la cardinalidad, las alertas sobre datos sin procesar pueden ser extremadamente caras. En el ejemplo anterior, se devuelven 10.000 series temporales por cada periodo de ejecución. Sin embargo, si agregas datos a la máquina virtual, solo se devolverán 100 series temporales por periodo de ejecución, independientemente de la cardinalidad de la etiqueta de los datos subyacentes.
Si creas alertas basadas en datos brutos, también corres el riesgo de que aumente el número de series temporales cuando tus métricas reciban nuevas etiquetas. En el ejemplo anterior, si un usuario añade una etiqueta nueva a tu métrica, la cardinalidad total aumentará a 100 * 11 * 10 = 11.000 series temporales. En este caso, el número de series temporales devueltas aumenta en 1000 en cada periodo de ejecución,aunque tu política de alertas no haya cambiado. Si, por el contrario, agregas datos a la VM, aunque aumente la cardinalidad subyacente, solo se devolverán 100 series temporales.
Filtrar las respuestas innecesarias
Configura las condiciones para evaluar solo los datos que sean necesarios para tus alertas. Si no vas a tomar medidas para corregir algo, exclúyelo de tus políticas de alertas. Por ejemplo, probablemente no necesites enviar alertas sobre la VM de desarrollo de un becario.
Para reducir los incidentes y los costes innecesarios, puede filtrar las series temporales que no sean importantes. Puedes usar Google Cloud etiquetas de metadatos para etiquetar recursos con categorías y, a continuación, filtrar las categorías de metadatos que no necesites.
Usar operadores de flujo superior para reducir el número de series temporales devueltas
Si tu condición usa una consulta de PromQL, puedes usar un operador de los flujos principales para seleccionar un número de las series temporales devueltas con los valores más altos:
- PromQL:
topk
Por ejemplo, una cláusula topk(metric, 5) en una consulta de PromQL limita el número de series temporales devueltas a cinco en cada periodo de ejecución.
Si limitas el número de series temporales, es posible que falten datos y que se produzcan incidentes erróneos, como los siguientes:
- Si más de N series temporales superan el umbral, no se mostrarán los datos que no estén entre las N series temporales principales.
- Si una serie temporal infractora se produce fuera de las N series temporales principales, es posible que los incidentes se cierren automáticamente aunque la serie temporal excluida siga infringiendo el umbral.
- Es posible que tus consultas de condición no te muestren contexto importante, como series temporales de referencia que funcionan correctamente.
Para mitigar estos riesgos, elige valores grandes para N y usa el operador top-streams solo en políticas de alertas que evalúen muchas series temporales, como incidentes de contenedores de Kubernetes individuales.
Aumentar la duración del periodo de ejecución (solo PromQL)
Si tu condición usa una consulta PromQL, puedes modificar la duración del periodo de ejecución configurando el campo evaluationInterval en la condición.
Cuanto más largos sean los intervalos de evaluación, menos series temporales se devolverán al mes. Por ejemplo, una consulta de condición con un intervalo de 15 segundos se ejecuta el doble de veces que una consulta con un intervalo de 30 segundos, y una consulta con un intervalo de 1 minuto se ejecuta la mitad de veces que una consulta con un intervalo de 30 segundos.
Monitorizar
En esta sección se describe cómo monitorizar los costes creando políticas de alertas. Una política de alertas puede monitorizar datos de métricas y enviarte una notificación cuando esos datos superen un umbral.
Monitorizar los bytes de registro ingeridos al mes
Para crear una política de alertas que se active si el número de bytes de registro escritos en tus cubos de registro supera el límite que has definido en Cloud Logging, sigue los pasos que se indican más abajo:
| Campo Nueva condición |
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 registro mensuales ingeridos. |
| Filtro | Ninguno |
| Entre series temporales Agregación de series temporales |
sum |
| Ventana de tiempo | 60 m |
| Función de ventana móvil | max |
| Configurar 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 de umbral | Tú eliges el valor aceptable. |
| Ventana de repetición de la prueba | El valor mínimo aceptable es 30 minutos. |
Monitorizar el total de métricas ingeridas
No se pueden crear alertas basadas en las métricas ingeridas mensualmente. Sin embargo, sí puedes crear alertas para los costes de Cloud Monitoring. Para obtener más información, consulta Configurar una alerta de facturación.
Monitorizar los intervalos de trazas ingeridos al mes
Para crear una política de alertas que se active cuando la métrica de intervalos de Cloud Trace ingeridos al mes supere el límite que has definido, sigue los pasos que se indican más abajo.
| Campo Nueva condición |
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 traza ingeridos al mes. |
| Filtro | |
| Entre series temporales Agregación de series temporales |
sum |
| Ventana de tiempo | 60 m |
| Función de ventana móvil | max |
| Configurar 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ú eliges el valor aceptable. |
| Ventana de repetición de la prueba | El valor mínimo aceptable es 30 minutos. |
Configurar una alerta de facturación
Si quieres recibir una notificación cuando tus cargos previstos o facturables superen un presupuesto concreto, puedes crear una alerta en la página Presupuestos y alertas de la Google Cloud consola:
-
En la Google Cloud consola, ve a la página Facturación:
También puedes acceder a esta página mediante la barra de búsqueda.
Si tienes más de una cuenta de facturación de Cloud, sigue uno de estos pasos:
- Para gestionar la facturación de Cloud del proyecto seleccionado, elige Ir a la cuenta de facturación vinculada.
- Si quieres acceder a otra cuenta de facturación de Cloud, haz clic en Gestionar cuentas de facturación y elige la cuenta cuyo presupuesto quieras configurar.
- En el menú de navegación Facturación, selecciona Presupuestos y alertas.
- Haz clic en Crear presupuesto.
- Completa el cuadro de diálogo del presupuesto. En este cuadro de diálogo, tienes que seleccionar la combinación de Google Cloud proyectos y productos y, luego, crear su presupuesto. De forma predeterminada, se te notificará cuando se alcance el 50 %, el 90 % y el 100 % del presupuesto. Si quieres ver la documentación completa, consulta la información sobre cómo configurar presupuestos y sus alertas.