En esta página, se describe cómo puedes optimizar y supervisar tus costos de Google Cloud Observability. Para obtener información sobre los precios, consulta Precios de Google Cloud Observability.
También te pueden interesar los siguientes documentos:
- Calcula tus facturas.
- Ejemplos de precios
- Optimiza los costos con el Explorador de costos. El Explorador de costos proporciona visualizaciones actuales e históricas de los datos de costos y las métricas de utilización. Por lo tanto, los datos te ayudan a identificar oportunidades de optimización.
Optimizar
En esta sección, se proporciona orientación para reducir u optimizar los costos asociados con Cloud Logging, Cloud Trace y Google Cloud Managed Service para Prometheus.
Reduce tus costos de Cloud Logging
Para reducir los costos de almacenamiento de Cloud Logging, configura filtros de exclusión en tus receptores de registros para evitar que las entradas de registro de bajo valor se transmitan a tus buckets de registros. Puedes configurar un receptor 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 transmiten a tus buckets de registros y no se consideran en tu asignación de almacenamiento. Para obtener más información, consulta Filtros de receptor de registros.
Los costos de almacenamiento de Cloud Logging solo se aplican a los datos de registros que se almacenan en buckets de registros. Puedes configurar tus receptores de registros para que los datos de registro no se almacenen en buckets de registros, sino que se enruten a uno de los siguientes destinos:
Cloud Logging no cobra por enrutar las entradas de registro a los destinos que se indican. Sin embargo, es posible que se te cobre cuando un destino reciba entradas de registro.
Para obtener información sobre el enrutamiento de datos de registro, consulta Enruta registros a destinos compatibles.
Optimiza los costos de Managed Service para Prometheus
Los precios del servicio administrado para Prometheus están diseñados para ser 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 filtros para reducir la cantidad de muestras enviadas al almacén de datos global del servicio. Si deseas obtener más información, consulta Filtra métricas exportadas. Usa los archivos de configuración de etiquetado de métricas en tu configuración de recopilación de Prometheus para descartar las métricas al momento de la transferencia, en función de los comparadores de etiquetas.
Mantén la cardinalidad alta y los datos locales de bajo valor. Puedes ejecutar Prometheus estándar junto con el servicio administrado, usar la misma configuración de paisaje y conservar los datos locales que no vale la pena enviar al almacén de datos global del servicio.
Los precios del servicio administrado para Prometheus están diseñados para ser previsibles.
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 14cuenta 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 el servicio administrado para Prometheus se cobrara por métrica, tendrías que pagar por la cardinalidad de un mes completo, todo a la vez, cada vez que se iniciara un contenedor nuevo. Con los precios por muestra, pagas solo mientras se ejecuta el contenedor.
Búsquedas, incluidas las consultas de alertas
Todas las consultas que emite el usuario, incluidas las que se emiten cuando se ejecutan las reglas de grabación de Prometheus, se cobran a través de las llamadas a la API de Cloud Monitoring.
Reduce el uso de Trace
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.
Cómo reducir tu factura de alertas
En esta sección, se describen las estrategias que puedes usar para reducir los costos de las alertas. Para obtener información sobre el modelo de precios, consulta Precios de Google Cloud Observability y Ejemplos de precios de las alertas.
Consulta tu factura estimada con la calculadora de precios integrada en la IU
Cuando creas o editas una política de alertas, Cloud Alerting muestra el costo estimado de la política. Puedes usar esta calculadora para ver cómo cambia tu costo estimado a medida que modificas los parámetros de tu política de alertas.
Usa el Explorador de métricas para verificar el recuento de puntos devueltos
La cantidad de puntos que devuelve la consulta de la política de alertas depende principalmente de la cardinalidad del resultado de la consulta de la política de alertas. Para ver la cardinalidad estimada de tu política de alertas, haz lo siguiente:
- Para una condición de alerta de umbral de métrica, usa el Explorador de métricas para crear una consulta idéntica. Agrega una transformación secundaria de Serie temporal de recuento por Ninguno.
- Para una condición de alerta de PromQL, copia la consulta en el Explorador de métricas y, luego, haz lo siguiente:
- Divide tu consulta en cláusulas separadas dividiendo cada operador
>,<,>=,<=,==,!=,AND,ORyUNLESS. - Borra cualquier cláusula que no contenga una métrica, como un valor de umbral numérico.
- Encierra cada cláusula en una función
count(). - Suma los resultados.
- Divide tu consulta en cláusulas separadas dividiendo cada operador
En el caso de una condición de alerta de MQL, copia la consulta en el Explorador de métricas. Quita la línea
| condition. Agrega una línea| group_by [], .countal final.El MQL dejó de estar disponible, y es posible que Atención al cliente de Cloud rechace los casos en los que se solicite ayuda para depurar problemas de facturación.
Consolida las políticas de alertas para que operen en más recursos
Las alertas cobran un costo por referencia de métrica, y cada política de umbral de métrica tiene una referencia de métrica por condición. Por este motivo, cuando sea posible, usa una política de alertas para supervisar varios recursos en lugar de crear una política de alertas para cada recurso.
Por ejemplo, supongamos que tienes 100 VMs. Cada VM genera un punto por minuto para el tipo de métrica my_metric. Estas son dos formas diferentes en las que puedes supervisar los puntos que se devuelven:
Creas una política de alertas que tiene una condición y, por lo tanto, una referencia de métrica. La condición supervisa
my_metricy agrega datos al nivel de la VM. Después de la agregación, se devuelve un punto para cada VM. Por lo tanto, la condición genera 100 puntos que se devuelven por evaluación.Creas 100 políticas de alertas, y cada una contiene una condición y, por lo tanto, tiene una referencia de métrica. Cada condición supervisa la serie temporal
my_metricde una de las VMs y agrega datos a nivel de la VM. Por lo tanto, cada condición devuelve un punto por evaluación.
La segunda opción, que crea 100 condiciones (100 referencias de métricas), es más costosa que la primera, que solo crea 1 condición (1 referencia de métrica). Ambas opciones devuelven 100 puntos por evaluación.
Agrega solo el nivel sobre el que necesitas generar alertas
Se devuelve un punto para cada serie temporal que supervisa una política de alertas. La agregación en niveles de granularidad más altos genera costos más altos que la agregación en niveles de granularidad más bajos. Por ejemplo, agregar datos a nivel del proyectoGoogle Cloud es más económico que hacerlo a nivel del clúster, y agregar datos a nivel del clúster es más económico que hacerlo a nivel del clúster y del espacio de nombres.
Por ejemplo, supongamos que tienes 100 VMs. Cada VM genera un punto 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 supervise my_metric. Estas son dos opciones de agregación diferentes:
Agregas datos al servicio. Después de la agregación, cada ejecución de la política de alertas devuelve un punto para cada servicio. Por lo tanto, la condición devuelve 5 puntos por ejecución.
Agregas datos a nivel de la VM. Después de la agregación, cada ejecución de la política de alertas devuelve un punto para cada VM. Por lo tanto, la condición devuelve 100 puntos por ejecución.
La segunda opción, que devuelve 100 puntos por ejecución, es más costosa que la primera, que solo devuelve cinco puntos por ejecución.
Cuando configures tus políticas de alertas, elige los niveles de agregación que mejor se adapten a tu caso de uso. Por ejemplo, si te interesa recibir alertas sobre el uso de la CPU, es posible que desees agregar datos a nivel de la VM y la CPU. Si te interesa recibir alertas sobre la latencia por servicio, es posible que desees agregar datos a nivel del servicio.
No se envían alertas sobre datos sin procesar ni agregar
Monitoring usa un sistema de métricas dimensionales, en el que cualquier métrica tiene una cardinalidad total igual a la cantidad de recursos supervisados multiplicada por la cantidad de combinaciones de etiquetas en esa métrica. Por ejemplo, si tienes 100 VMs que emiten una métrica, y esa métrica tiene 10 etiquetas con 10 valores cada una, tu cardinalidad total es 100 * 10 * 10 = 10,000.
Como resultado de la forma en que se ajusta la cardinalidad, las alertas sobre los datos sin procesar pueden ser extremadamente costosas. En el ejemplo anterior, se devuelven 10,000 puntos para cada período de ejecución. Sin embargo, si agregas datos a la VM, solo se devuelven 100 puntos por período de ejecución, independientemente de la cardinalidad de la etiqueta de los datos subyacentes.
Las alertas sobre datos sin procesar también te exponen al riesgo de que se devuelvan más puntos cuando tus métricas reciban etiquetas nuevas. En el ejemplo anterior, si un usuario agrega una etiqueta nueva a tu métrica, tu cardinalidad total aumentará a 100 * 11 * 10 = 11,000 series temporales. En este caso, la cantidad de puntos devueltos aumenta en 1,000 en cada período de ejecución, aunque tu política de alertas no haya cambiado. En cambio, si agregas los datos a la VM, a pesar del aumento de la cardinalidad subyacente, solo se mostrarán 100 series temporales.
Cómo filtrar respuestas innecesarias
Configura tus condiciones para evaluar solo los datos necesarios para tus necesidades de alertas. Si no tomarías medidas para corregir algo, exclúyelo de tus políticas de alertas. Por ejemplo, probablemente no necesites generar alertas sobre la VM de desarrollo de un pasante.
Para reducir los incidentes y los costos innecesarios, puedes filtrar las series temporales que no sean importantes. Puedes usar etiquetas de metadatos Google Cloud para etiquetar recursos con categorías y, luego, filtrar las categorías de metadatos innecesarias.
Usa operadores de transmisión superior para reducir la cantidad de puntos que se muestran
Si tu condición usa una consulta de PromQL, puedes usar un operador de top-streams para seleccionar una cantidad de los puntos que se muestran con los valores más altos:
- PromQL:
topk
Por ejemplo, una cláusula topk(metric, 5) en una consulta de PromQL limita la cantidad de puntos que se muestran a cinco en cada período de ejecución.
Limitar la cantidad de puntos principales puede provocar que falten datos y que se produzcan incidentes defectuosos, como los siguientes:
- Si más de N puntos incumplen tu umbral, perderás datos fuera de los primeros N puntos.
- Si se produce un punto infractor fuera de los N puntos principales, es posible que tus incidentes se cierren automáticamente a pesar de que los puntos excluidos sigan incumpliendo el umbral.
- Es posible que tus consultas de condiciones no te muestren contexto importante, como los puntos de referencia que funcionan según lo previsto.
Para mitigar estos riesgos, elige valores grandes para N y usa el operador top-streams solo en las políticas de alertas que evalúan muchas series temporales, como los incidentes de contenedores individuales de Kubernetes.
Aumenta la duración del período de ejecución (solo PromQL)
Si tu condición usa una consulta de PromQL, puedes modificar la duración de tu período de ejecución configurando el campo evaluationInterval en la condición.
Los intervalos de evaluación más largos generan menos puntos devueltos por 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.
No uses "Recurso no especificado" (solo para métricas basadas en registros)
Las condiciones de alerta que usan métricas basadas en registros te permiten establecer "Recurso no especificado" como tu tipo de recurso supervisado. Cuando lo haces, la condición de alerta inicia una consulta independiente para cada tipo de recurso supervisado en Cloud Monitoring. Como cada consulta factura un mínimo de un punto devuelto, no especificar el tipo de recurso genera una factura alta por los puntos devueltos.
Para reducir tu factura, elige un tipo de recurso específico en lugar de usar "Recurso no especificado". Esto funciona porque la mayoría de las métricas basadas en registros solo aparecen en un tipo de recurso. Si tu métrica basada en registros aparece en varios tipos de recursos, puedes crear varias políticas de alertas o usar varias condiciones en una sola política de alertas.
Supervisar
En esta sección, se describe cómo supervisar tus costos creando políticas de alertas. Una política de alertas puede supervisar los datos de las métricas y notificarte cuando esos datos superen un umbral.
Supervisa los bytes de registros mensuales transferidos
Para crear una política de alertas que se active cuando la cantidad de bytes de registros escritos en tus buckets de registros supere 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 ingeridos. |
| 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. |
Supervisa las métricas totales 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. Para obtener más información, consulta Configura una alerta de facturación.
Supervisa los intervalos de seguimiento mensuales transferidos
Para crear una política de alertas que se active cuando el número de intervalos de Cloud Trace transferidos en un mes supere el límite definido por el usuario, 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 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. |
Configura una alerta de facturación
Crea una alerta a través de la página Presupuestos y alertas de la consola de Google Cloud para recibir una notificación si tus cargos previstos o facturables superan un presupuesto.
-
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:
- 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 Google Cloud proyectos y productos, 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.