Optimización de costos para Google Cloud's operations suite

Google Cloud's operations suite consta de una colección de servicios administrados basados en la nube que se diseñaron para proporcionar una observabilidad profunda de los servicios de infraestructura y apps. Uno de los beneficios de los servicios administrados en Google Cloud es que los servicios se basan en el uso, lo que significa que solo pagas por lo que usas. Si bien este modelo de precios puede proporcionar un beneficio de costo cuando se compara con las licencias de software estándar, puede hacer que sea difícil prever el costo. En esta solución, se describen las formas en que puedes comprender el uso de estos servicios y optimizar tus costos.

Precios

Debido a que Google Cloud's operations suite son servicios administrados, te permiten enfocarte en las estadísticas que proporcionan, en lugar de la infraestructura necesaria para usar estos servicios. Cuando usas estos servicios, no tienes que pagar de manera individual por las máquinas virtuales, las licencias de software, los análisis de seguridad, el mantenimiento de hardware o el espacio en un centro de datos. Los servicios ofrecen un costo simple por uso.

Los costos incluyen los cargos por Cloud Logging, Cloud Monitoring y Cloud Trace. El producto de registro de Error Reporting no tiene un costo individual cuando aún está en versión beta. También puedes usar Cloud Debugger y Cloud Profiler sin ningún costo. En el caso de Error Reporting, se pueden generar costos menores si Logging transfiere los errores.

También puedes leer un resumen de toda la información de precios.

Costos de Logging y Error Reporting

Los precios de Logging se basan en el volumen de los registros cobrables transferidos. El precio de este producto proporciona un costo simple por GiB. Esta es una asignación gratuita por mes, y algunos registros, como los registros de auditoría de Cloud, no tienen costo.

Ejemplos del uso de un producto que genera costos a través del volumen de registro adicional incluyen el uso de:

  • Cloud Load Balancing
  • El agente de Logging en Compute Engine
  • El agente de Logging en Amazon Web Services (AWS)
  • La operación de escritura en la API de Cloud Logging

Costos de Monitoring

Los precios de Monitoring se basan en el volumen de las métricas cobrables transferidas y en el número de llamadas a la API cobrables. Por ejemplo, se aplican cargos a las métricas que no son de Google Cloud, como las métricas de agente, las personalizadas, las externas y las de AWS. El método projects.timeSeries.list en la API de Cloud Monitoring se cobra mediante la llamada a la API, mientras que el resto del uso de la API es gratuito. Esta es una asignación de volumen de métricas gratuita por mes, y muchas de las métricas, incluidas todas las de Google Cloud, no son cobrables. Consulta Precios de Monitoring para obtener más información sobre qué métricas son cobrables.

A continuación, se presentan ejemplos del uso de un producto que genera costos a través del volumen de métrica y de las llamadas a la API:

  • Métricas personalizadas de Monitoring
  • El agente de Monitoring en Compute Engine
  • El agente de Monitoring en AWS
  • La operación de lectura en la API de Monitoring

Costos de Trace

Los precios de Trace se basan en la cantidad de intervalos transferidos y, luego, analizados. Algunos servicios de Google Cloud, como el entorno estándar de App Engine, producen de forma automática intervalos no cobrables. Hay una asignación gratuita por mes para Trace.

Ejemplos del uso de un producto que genera costos a través de los intervalos transferidos incluyen agregar instrumentación para:

  • Intervalos para aplicaciones de App Engine fuera de los intervalos predeterminados
  • Cloud Load Balancing
  • Aplicaciones personalizadas

Uso

Comprender el uso puede proporcionarte información sobre qué componentes generan costos. Esto ayuda a identificar áreas que podrían ser adecuadas para la optimización.

Análisis de facturas de Google Cloud

El primer paso para comprender tu uso es revisar la factura de Google Cloud y comprender los costos. Una forma de obtener información es usar los informes de facturación disponibles en Google Cloud Console.

La página Informes ofrece un rango útil de filtros para limitar los resultados por tiempo, proyecto, productos, SKU y etiquetas. Puedes usar el filtro Productos para reducir los datos de facturación a los costos de Monitoring y Logging.

Logging

Logging proporciona listas detalladas de los registros, el volumen de registro actual y el volumen mensual proyectado para cada proyecto. Puedes revisar estos detalles en cada proyecto y, a su vez, revisar los cargos de Logging en tu factura de Google Cloud. Esto hace que sea fácil ver qué registros tienen el volumen más alto y, por lo tanto, contribuyen más al costo.

Puedes encontrar el volumen de registros transferidos en tu proyecto en la sección Transferencia de registros de Logging. El Visor de registros proporciona una lista de los registros, su mes anterior, el mes actual, así como los volúmenes de registro de fin de mes (EOM) excluidos y proyectados. En la siguiente imagen, cada registro se vincula a Monitoring, y se muestra un grafo del volumen del registro a lo largo del tiempo.

Visor de registros con vínculos de registros

Este análisis te permite desarrollar estadísticas sobre el uso de los registros en proyectos específicos y cómo cambió su volumen con el tiempo. Puedes usar este análisis con el fin de identificar qué registros debes considerar para su optimización.

Monitoring

Monitoring, organizado en permisos de métricas, proporciona una lista detallada de proyectos y volúmenes de métricas anteriores, actuales y proyectadas. Debido a que un permiso de métricas puede incluir más de un proyecto, los volúmenes para cada proyecto se describen por separado, como se muestra en la siguiente imagen.

Lugar de trabajo con varios proyectos

Obtén más información para encontrar los detalles de uso de Workspace Monitoring.

Puedes ver el grafo detallado de la métrica del volumen de métricas para cada proyecto en el Explorador de métricas en Monitoring, que proporciona estadísticas sobre el volumen de métricas transferidas en el tiempo.

Este análisis te proporciona los volúmenes de métricas de Monitoring para cada proyecto que identificaste cuando revisaste los cargos de Monitoring en tu factura de Google Cloud. Luego, puedes revisar los volúmenes de métricas específicas y comprender cuáles son los componentes que más contribuyen al volumen y costo.

Trace

Trace proporciona una vista detallada de los intervalos transferidos para el mes actual y el anterior. Puedes revisar estos detalles en Cloud Console para cada proyecto que identifiques mientras revisas los cargos de Trace en la factura de Google Cloud.

Este análisis te proporciona la cantidad de intervalos transferidos para cada proyecto en un lugar de trabajo que identificaste cuando revisaste los cargos de Trace en tu factura de Google Cloud. Luego, puedes revisar la cantidad específica de intervalos transferidos y comprender cuáles son los proyectos y servicios que contribuyen a la mayor cantidad de intervalos y costos.

Exportación de Logging

Logging proporciona un receptor de registros para exportar registros a Cloud Storage, BigQueryPub/Sub.

Por ejemplo, si exportas todos los registros de Logging a BigQuery para su análisis y almacenamiento a largo plazo, generarás costos de BigQuery, que incluyen el almacenamiento por GiB, las inserciones de transmisión y cualquier costo de consulta.

Para comprender los costos que generan tus exportaciones, considera los siguientes pasos:

  1. Encuentra tus receptores de registros: Averigua qué receptor de registros, si hay alguno, tienes habilitado. Por ejemplo, es posible que tu proyecto ya tenga varios receptores de registros que se crearon para diferentes propósitos, como operaciones de seguridad o con el fin de cumplir con los requisitos reglamentarios.
  2. Revisa tus detalles de uso: Revisa el uso del destino de las exportaciones. Por ejemplo, los tamaños de tabla de BigQuery para una exportación de BigQuery o los tamaños de bucket para las exportaciones de Cloud Storage.

Encuentra tus receptores de registros

Los receptores de registros pueden estar a nivel de proyecto (uno o más receptores por proyecto) o a nivel de organización de Google Cloud, denominados exportaciones agregadas. Los receptores pueden incluir los registros de muchos proyectos en la misma organización de Google Cloud.

Puedes ver tus receptores de registros si observas proyectos específicos. Cloud Console proporciona una lista de los receptores y el destino. Con el fin de ver las exportaciones agregadas para tu organización, puedes usar la línea de comandos gcloud logging sinks list --organization ORGANIZATION_ID.

Revisa tus detalles de uso

Monitoring proporciona un amplio conjunto de métricas para tus apps y el uso de los productos de Google Cloud. Para obtener las métricas de uso detalladas de Cloud Storage, BigQuery y Pub/Sub, consulta las métricas de uso en el Explorador de métricas.

Cloud Storage

Si usas el Explorador de métricas en Monitoring, puedes ver el tamaño de almacenamiento de tus depósitos de Cloud Storage. Usa los siguientes valores en el Explorador de métricas con el fin de ver el tamaño de almacenamiento de tus depósitos de Cloud Storage usados para los receptores de registros.

Si quieres usar el Explorador de métricas para ver las métricas de un recurso supervisado, sigue estos pasos:

  1. En Google Cloud Console, ve a la página Supervisión.

    Ir a Monitoring

  2. En el panel de navegación de Monitoring, haz clic en  Explorador de métricas.
  3. Selecciona la pestaña Configuración y, luego, ingresa o selecciona un Tipo de recurso y una Métrica. Usa la siguiente información para completar los campos:
    1. En Recurso, ingresa gcs_bucket.
    2. En Métrica, ingresa storage.googleapis.com/storage/total_bytes.
    3. Agrega los siguientes Filtros (Filter):
      • Haz clic en project_id y, luego, selecciona el ID del proyecto de Google Cloud.
      • Haz clic en dataset_name y, luego, selecciona el nombre del bucket de exportación de Cloud Storage.
  4. Para configurar la forma en que se ven los datos, usa los menús Filtro, Agrupar por y Agregador (opcional). Por ejemplo, puedes agrupar por etiquetas de recursos o métricas. Para obtener más información, consulta Selecciona métricas.
Tamaño de almacenamiento de los depósitos de Cloud Storage

En el gráfico anterior, se muestra el tamaño de los datos en KB exportados a lo largo del tiempo, lo que proporciona estadísticas sobre el uso de la exportación de Logging a Cloud Storage.

BigQuery

Si usas el Explorador de métricas en Monitoring, puedes ver el tamaño de almacenamiento de tu conjunto de datos de BigQuery. Usa los siguientes valores en el Explorador de métricas con el fin de ver el tamaño de almacenamiento de tu conjunto de datos de BigQuery usados para el receptor de registros.

  1. En Google Cloud Console, ve a Monitoring o usa el siguiente botón:
    Ir a Monitoring
  2. Si el Explorador de métricas aparece en el panel de navegación, haz clic en Explorador de métricas. De lo contrario, selecciona Recursos y, luego, Explorador de métricas.
  3. Asegúrate de que esté seleccionada la pestaña Métrica.
  4. Haz clic en el cuadro que tiene la etiqueta Find resource type and metric y, a continuación, selecciona estos elementos en el menú o ingresa el nombre del recurso y de la métrica. Usa la siguiente información para completar los campos de este cuadro de texto:
    1. En Tipo de recurso (Resource Type), ingresa bigquery_dataset.
    2. En Métrica (Metric), ingresa bigquery.googleapis.com/storage/stored_bytes.

  5. Agrega los siguientes Filtros:
    • Haz clic en project_id y, luego, selecciona el ID del proyecto de Google Cloud.
    • Haz clic en dataset_id y, luego, selecciona el nombre del conjunto de datos de exportación de BigQuery.
  6. En Agrupar por (Group By), ingresa dataset_id. Tamaño de almacenamiento del conjunto de datos de BigQuery

    En el gráfico anterior, se muestra el tamaño del conjunto de datos de exportación en GB a lo largo del tiempo, lo que proporciona estadísticas sobre el uso de la exportación de Logging a BigQuery.

Pub/Sub

Si usas el Explorador de métricas en Monitoring, puedes ver la cantidad y el tamaño de los mensajes exportados a Pub/Sub. Usa los siguientes valores en el Explorador de métricas a fin de ver el tamaño de almacenamiento del tema de Pub/Sub que se usó para el receptor de registros.

  1. En Google Cloud Console, ve a Monitoring o usa el siguiente botón:
    Ir a Monitoring
  2. Si el Explorador de métricas aparece en el panel de navegación, haz clic en Explorador de métricas. De lo contrario, selecciona Recursos y, luego, Explorador de métricas.
  3. Asegúrate de que esté seleccionada la pestaña Métrica.
  4. Haz clic en el cuadro que tiene la etiqueta Find resource type and metric y, a continuación, selecciona estos elementos en el menú o ingresa el nombre del recurso y de la métrica. Usa la siguiente información para completar los campos de este cuadro de texto:
    1. Para Tipo de recurso (Resource Type), ingresa pubsub_topic.
    2. En Métrica (Metric), ingresa pubsub.googleapis.com/topic/byte_cost.

  5. Agrega los siguientes Filtros (Filter):
    • Haz clic en project_id y, luego, selecciona el ID del proyecto de Google Cloud.
    • Haz clic en topic_id y, luego, selecciona el nombre del tema de exportación de Pub/Sub.

Tamaño de almacenamiento del tema de Pub/Sub

En el gráfico anterior, se muestra el tamaño de los datos en KB exportados a lo largo del tiempo, lo que proporciona estadísticas sobre el uso de la exportación de Logging a Pub/Sub.

Implementa controles de costos

En las siguientes opciones, se describen formas posibles de reducir los costos. Cada opción se consigue a expensas de limitar las estadísticas en tu infraestructura y apps. Selecciona la opción que te brinde la mejor compensación entre observabilidad y costo.

Controles de costos de Logging

Para optimizar tu uso de Logging, puedes reducir la cantidad de registros que se transfieren a Logging. Existen varias estrategias que puedes usar para ayudar a reducir el volumen de registros mientras continúas manteniendo los registros que necesitan tus desarrolladores y operadores.

Excluye registros

Puedes excluir la mayoría de los registros que tus equipos de operaciones y desarrolladores no necesitan de Logging o Error Reporting.

La exclusión de registros significa que no aparecen en la IU de Logging o de Error Reporting. Puedes usar filtros de registro para seleccionar entradas de registro específicas o registros completos que deben excluirse. También puedes usar reglas de exclusión de muestreo para excluir un porcentaje de entradas de registro. Por ejemplo, es posible que quieras excluir ciertos registros en función del alto volumen o la falta de valor práctico.

A continuación, hay varios ejemplos comunes de exclusión:

  • Excluir registros de Cloud Load Balancing. Los balanceadores de cargas pueden producir un gran volumen de registros para aplicaciones de tráfico alto. Por ejemplo, puedes usar un filtro de registro con el fin de configurar una exclusión para el 90% de los mensajes de Cloud Load Balancing.
  • Excluir registros de flujo de nube privada virtual (Controles del servicio de VPC). Los registros de flujo incluyen registros para cada comunicación entre máquinas virtuales en una red de Controles del servicio de VPC, lo que puede producir un gran volumen de registros. Existen dos enfoques para reducir el volumen de registros, que puedes utilizar juntos o por separado.

    • Excluir por contenido de entrada de registro. Se excluyen la mayoría de los registros de flujo de VPC y se conserva solo los mensajes de registro específicos que podrían ser útiles. Por ejemplo, si tienes VPC privadas que no deberían recibir tráfico entrante de fuentes externas, recomendamos conservar registros de flujo con campos de fuentes de direcciones IP externas.
    • Excluir por porcentaje. Otro enfoque es generar muestras de solo un porcentaje de registros identificados por el filtro. Por ejemplo, es posible que quieras excluir el 95% y solo conservar el 5% de los registros de flujo.
  • Excluir respuestas HTTP de 200 OK de los registros de solicitudes. En el caso de las apps, es posible que los mensajes HTTP de 200 OK no proporcionen mucha información y produzcan un gran volumen de registros para las apps de tráfico alto.

Lee Exclusiones de registros para implementar exclusiones de registros.

Exporta registros

Puedes exportar registros, pero excluirlos de la transferencia a Logging. Esto te permite conservar los registros en Cloud Storage y BigQuery, o usar Pub/Sub para procesar los registros, mientras se excluyen los registros de Logging, lo que podría ayudar a reducir los costos. Esto significa que tus registros no aparecen en Logging, pero se exportan.

Usa este método con el fin de conservar los registros para un análisis a más largo plazo sin incurrir en el costo de transferencia a Logging. Para una comprensión detallada de cómo interactúan las exportaciones y exclusiones, consulta la vida de un diagrama de registro, que ilustra cómo se tratan las entradas de registros exportadas en Logging.

Sigue las instrucciones en los patrones de diseño para exportaciones de Logging con el fin de implementar las exportaciones de Logging.

Reduce el uso del agente de Logging

Puedes reducir los volúmenes de registro si no envías los registros adicionales generados por el agente de Logging a Logging. El agente de Logging transmite registros de apps comunes de terceros, como Apache, Mongodb y MySQL.

Por ejemplo, es posible que reduzcas los volúmenes de registros si eliges no agregar el agente de Logging a las máquinas virtuales en entornos de desarrollo, o bien otros entornos no esenciales a Logging. Tus máquinas virtuales continúan reportando los registros estándar a Logging, pero no reportan los registros de aplicaciones de terceros ni de syslog.

Controles de costos de Monitoring

Para optimizar tu uso de Monitoring, puedes reducir el volumen de métricas cobrables que se transfieren a Monitoring y la cantidad de llamadas leídas a la API de Monitoring. Existen varias estrategias que puedes usar para reducir el volumen de métricas mientras continúas conservando las métricas que necesitan tus operadores y desarrolladores.

Optimiza las métricas y el uso de etiquetas

La forma en que usas las etiquetas en los componentes de Google Cloud puede afectar el volumen de las series temporales que se generan para tus métricas en Monitoring.

Por ejemplo, puedes usar etiquetas en tus VM para informar de forma correcta las métricas a los centros de costos en tu factura de Google Cloud e indicar si los entornos de Google Cloud específicos son de producción o desarrollo, como se muestra en la siguiente imagen.

Etiquetas en los clústeres de Google Kubernetes Engine

Si agregas estas etiquetas significa que se generan series temporales adicionales en Monitoring. Si etiquetas tus máquinas virtuales con los valores cost_center y env, puedes calcular la cantidad total de series temporales mediante la multiplicación de la cardinalidad de ambas etiquetas.

total_num_time_series = cost_center_cardinality * env_cardinality

Si hay 11 valores cost_center y 5 env, esto significa que se generan 55 series temporales. Esta es la razón por la que, según la forma en que agregues las etiquetas, se puede agregar un volumen de métrica significativo y, por lo tanto, aumentar el costo. Consulta la entrada de blog Sugerencias y trucos de Cloud Monitoring: información sobre las métricas y la creación de gráficos para obtener una descripción detallada de la cardinalidad de métricas.

Recomendamos lo siguiente para minimizar las series temporales adicionales:

  • Cuando sea posible, limita el número de etiquetas.
  • Selecciona los valores de etiqueta cuidadosamente para evitar valores de etiqueta con alta cardinalidad. Por ejemplo, el uso de una dirección IP como etiqueta da como resultado una serie temporal para cada dirección IP, lo que podría ser un gran número si tienes muchas VM.

Reduce el uso de agentes de Monitoring

Las métricas enviadas desde el agente de Monitoring son métricas cobrables. El agente de Monitoring transmite métricas de la app y el sistema de apps comunes de terceros, como Apache, MySQL y Nginx, así como las métricas de Google Cloud adicionales a nivel de VM. Si no necesitas las métricas detalladas del sistema o las métricas de las apps de terceros para ciertas VM, puedes reducir el volumen si no las envías. También puedes reducir los volúmenes de métricas si reduces la cantidad de VM que usan el agente de Monitoring.

Por ejemplo, puedes reducir los volúmenes de métricas si eliges no agregar proyectos de Google Cloud en entornos de desarrollo o en otros entornos no esenciales a Monitoring. Además, puedes optar por no incluir el agente de Monitoring en VM en entornos de desarrollo o en otros entornos no esenciales.

Reduce el uso de métricas personalizadas

Las métricas personalizadas son métricas cobrables creadas con la API de Monitoring para supervisar cualquier métrica que instrumente un usuario. Puedes crear estas métricas mediante la API de Monitoring o integraciones.

Una de esas integraciones es OpenCensus. OpenCensus es una distribución de bibliotecas que recopilan métricas y seguimientos distribuidos de tus apps. Las apps que cuentan con OpenCensus pueden informar métricas a varios backends, incluido Monitoring, mediante el uso de métricas personalizadas. Estas métricas aparecen en Monitoring en el tipo de recurso de prefijo custom.googleapis.com/opencensus. Por ejemplo, la latencia de ida y vuelta del cliente que informa OpenCensus aparece en Monitoring en el tipo de recurso custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency.

Cuantas más aplicaciones instales para enviar métricas, más métricas de supervisión personalizadas se generarán. Si deseas reducir los volúmenes de métricas, puedes reducir la cantidad de métricas de supervisión personalizadas que envían tus aplicaciones.

Controles de costos de Trace

Para optimizar el uso de Trace, puedes reducir la cantidad de intervalos transferidos y analizados. Cuando configuras tu aplicación con el fin de informar los intervalos a Trace, usas el muestreo para transferir una parte del tráfico. El muestreo es una parte clave de un sistema de seguimiento porque proporciona estadísticas sobre el desglose de la latencia causada por los componentes de la aplicación, como las llamadas RPC. Esta no es solo una práctica recomendada para el uso de Trace, sino que también puedes reducir tu volumen de intervalo por motivos de reducción de costos.

Usa el muestreo de OpenCensus

Si usas Trace como destino de exportación para tus intervalos de OpenCensus, puedes usar la característica de muestreo en OpenCensus para reducir el volumen de intervalos que se transfieren.

Por ejemplo, si tienes una aplicación web popular con 5,000 consultas/s, puedes obtener suficientes estadísticas del muestreo del 5% del tráfico de tu app en lugar del 20%. Esto reduce la cantidad de intervalos transferidos a Trace a un cuarto.

Puedes especificar el muestreo en la configuración de la instrumentación con las bibliotecas de OpenCensus Python para Trace. Por ejemplo, el exportador de OpenCensus para Python proporciona una ProbabilitySampler que puedes usar con el objetivo de especificar una tasa de muestreo.

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)

Usa las cuotas de intervalo de la API de Cloud Trace

Puedes usar las cuotas para limitar el uso de Trace y el costo. Puedes aplicar cuotas de intervalo mediante la página de cuotas específica de la API en Cloud Console.

Establecer una cuota específica que sea inferior a la cuota de producto predeterminada significa que garantizas que tu proyecto no superará el límite de la cuota específica. Esta es una manera de garantizar que tus costos sean los esperados. Puedes supervisar esta cuota en la página de cuotas específica de la API, como se ilustra en la siguiente imagen.

Supervisión de la página de cuota específica de la API

Si reduces tu cuota de intervalo, también debes considerar supervisar las métricas de la cuota de intervalo y configurar una política de alertas en Monitoring para enviar una alerta cuando el uso se acerque a la cuota. Esta alerta te pedirá que observes el uso y, luego, identifiques la aplicación y el desarrollador que podrían generar el gran volumen de intervalos. Si estableces una cuota de intervalo y se excede, los intervalos se eliminan hasta que ajustes la cuota.

Por ejemplo, si tu cuota de intervalo es de 50 millones de intervalos transferidos, puedes establecer una alerta cada vez que hayas utilizado el 80% de tu cuota de la API, que es de 40 millones de intervalos. Sigue las instrucciones para administrar las políticas de alertas a fin de crear una política de alertas con los siguientes detalles.

  1. En Google Cloud Console, ve a Monitoring o usa el siguiente botón:
    Ir a Monitoring
  2. En el panel de navegación de Monitoring, selecciona Alertas y, luego, Crear política.
  3. Ingresa un nombre para la política de alertas.
  4. Haz clic en Agregar condición:
    1. En la configuración del panel Destino, se especifican el recurso y la métrica que se supervisarán. Haz clic en el cuadro de texto para habilitar un menú y, luego, selecciona el recurso global.
    2. Haz clic en el cuadro de texto para habilitar un menú y, luego, selecciona cloudtrace.googleapis.com/billing/monthly_spans_ingested.
    3. Agrega los siguientes valores de Filtro:
      • Haz clic en project_id y, luego, selecciona el ID del proyecto de Google Cloud.
      • Haz clic en chargeable y, luego, selecciona true.
    4. La configuración del panel Configuración de la política de alertas determina cuándo se activa la alerta. Completa los siguientes campos:
      • En La condición se activa si, selecciona Cualquier serie temporal es una infracción.
      • En Umbral, ingresa 40000000.
      • En For, selecciona most recent value.
    5. Haz clic en Guardar.
  5. Haz clic en Guardar.

    La alerta generada a partir de la política de alertas es similar a la siguiente. En ella, puedes ver los detalles sobre el proyecto, la política de alertas que generó la alerta y el valor actual de la métrica.

Detalles de la alerta

Optimiza emisores de terceros

Es posible que otra app llame a la tuya. Si tu app informa intervalos, la cantidad de intervalos que informa podría depender del tráfico entrante que recibas de la app de terceros. Por ejemplo, si tienes un microservicio de frontend que llama a un microservicio de confirmación de la compra y ambos cuentan con OpenCensus, la tasa de muestreo del tráfico es al menos tan alta como la tasa de muestreo del frontend. Comprender cómo interactúan las apps instrumentadas te permite evaluar el impacto de la cantidad de intervalos transferidos.

Exportación de Logging

Si tus costos relacionados con las exportaciones de Logging son una preocupación, una solución es actualizar tu receptor de registros para usar un filtro de registros a fin de reducir el volumen de registros que se exportan. Puedes excluir de la exportación los registros que no necesites.

Por ejemplo, si tienes un entorno con una aplicación que se ejecuta en Compute Engine y que usa Cloud SQL, Cloud Storage y BigQuery, puedes limitar los registros resultantes con el fin de incluir solo la información para esos productos. El siguiente filtro limita la exportación a registros de los registros de Cloud Audit, Compute Engine, Cloud Storage, Cloud SQL y BigQuery. Puedes usar este filtro para un receptor de registros y solo incluir los registros seleccionados.

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

Conclusión

Google Cloud's operations suite permite ver los datos de uso del producto para que puedas comprender sus detalles. Estos datos de uso te permiten configurar los productos para que puedas optimizar de forma adecuada tu uso y costos.

¿Qué sigue?